OpenSSH Public Key Authentifizierung
Bereits in dem letzten Artikel dieser Reihe haben wir die Datei authorized_keys kennengelernt und erfahren, wie man mit ihr einen Login ohne Kennworteingabe durchführt.
SSH-Agent
Solange wir, wie es empfohlen ist, auf den privaten Schlüssel ein Kennwort legen, muss weiterhin bei jedem Login ein Kennwort eingegeben werden. Dies ist allerdings nicht das Kennwort des Benutzers auf der angesprochenen Maschine, sondern das Kennwort des lokal abgelegten privaten Schlüssels.
Die Entwickler des SSH-Protokolls haben für diesen Zweck einen Mechanismus eingebaut, über den ein Agent die Verwaltung der Schlüssel übernimmt und bei Zugriff auf einen Server dem ssh-Kommando nutzbare Schlüssel anbietet.
Sinnvollerweise lautet der Name des Agenten ssh-agent. Unter Microsoft Windows gibt es für Konsolen-Programme wie Putty und Kitty das Programm PAgent.
Bleiben wir in der Linux-Welt: Leider kann das Programm ssh-agent nicht direkt in der Konsole aufgerufen und danach genutzt werden. Um vernünftig zu funktionieren, muss es einige Umgebungsvariablen setzen, und das funktioniert nur, wenn der ssh-agent wie folgt aufgerufen wird:
user@linux:~$ eval $(ssh-agent) Agent pid 19714
Der ssh-agent verrät uns, dass er im Hintergrund läuft und
über die angegebene Prozess-ID erreichbar ist. Allerdings hat er auch einige Variablen gesetzt, über die nun der ssh-Befehl weiß, wie er mit ihm kommunizieren kann:
user@linux:~$ env | grep SSH SSH_AGENT_PID=19714 SSH_ASKPASS=/usr/lib/ssh/x11-ssh-askpass SSH_AUTH_SOCK=/tmp/ssh-Fql8tV1N8CrH/agent.19713
Versuchen wir uns nun mit einem Server zu verbinden, wird der
Versuch weiterhin fehlschlagen, da wir zwar den Agent gestartet haben, aber keine privaten Schlüssel geladen sind:
user@linux:~$ ssh-add -L The agent has no identities.
Starten wir den Befehl ssh-add ohne Angabe von Parametern,
versucht der Befehl die Dateien ~/.ssh/id_rsa, ~/.ssh/id_dsa und ~/.ssh/id_ecdsa nacheinander zu laden. Alternativ kann dem Befehl auch eine Datei mit einem privaten Schlüssel angegeben werden.
user@linux ~ $ ssh-add Enter passphrase for /home/user/.ssh/id_rsa: Identity added: /home/user/.ssh/id_rsa (/home/user/.ssh/id_rsa) Identity added: /home/user/.ssh/id_dsa (/home/user/.ssh/id_dsa) Identity added: /home/user/.ssh/id_ecdsa (/home/user/.ssh/id_ecdsa)
Im vorliegenden Fall hat der Benutzer alle drei Dateien. Das Kennwort wird allerdings nur einmal abgefragt, da der Benutzer für alle Dateien das gleiche Kennwort angegeben hat. Andernfalls gibt es eine Abfrage für die jeweiligen Kennwörter.
Nun sind diese privaten Schlüssel geladen und können direkt genutzt werden — ssh-add -L listet sie auf. Die Ausgabe ist zur besseren Übersicht gekürzt:
user@linux:~$ ssh-add -L ssh-rsa AAAAB3NzaC1yc2EAAAABIw[...]6pnbvUw5UMZcE= /home/user/.ssh/id_rsa ssh-dss AAAAB3NzaC1kc3MAAACBAL[...]rKQnM4ldOkThA= /home/user/.ssh/id_dsa ecdsa-sha2-nistp256 AAAAE2VjZH[...]06ULv15k9jQyQ= /home/user/.ssh/id_ecdsa
Die beiden Schritte — das Starten des ssh-agent und das Hinzufügen der Schlüssel — muss immer wieder durchgeführt werden. Daher haben die meisten Oberflächen schon die Möglichkeit, dies entweder durch Optionen in den Konfigurationsdateien zu aktivieren, oder der Benutzer kann dies selbst durch Hinzufügen in der Datei .xinitrc im Home-Verzeichnis erledigen.
Agent-Forwarding
Nachdem wir den ssh-agent gestartet und die privaten Schlüssel hinzugefügt haben, klappt auch der Login auf einen entfernten Rechner ohne die Angabe weiterer Kennwörter.
Versucht man allerdings sich von diesem Rechner auf einen weiteren Rechner zu verbinden, kommt, obwohl auch dort der öffentliche Schlüssel hinterlegt ist, die Anfrage für das Kennwort.
user@linux:~$ ssh user@server1 Last login: Mon Jul 15 13:24:39 CEST 2013 from linux on ssh user@server1:~$ ssh user@server2 Password:
Der Grund für dieses Verhalten ist, dass der ssh-agent nur auf dem lokalen Rechner läuft und damit nicht direkt vom server1 angesprochen werden kann. Allerdings kann man dem server1 erlauben, die Verbindung zu dem ssh-agent über die bestehende Verbindung aufzubauen und einem aufgerufenen ssh-Befehl den ssh-agent verfügbar zu machen.
Dazu muss in der Konfigurationsdatei /etc/ssh/sshd_config des SSH-Servers auf server1 vom Benutzer root der Eintrag AllowAgentForwarding yes gesetzt werden.
Nach der Änderung und dem Neustart des SSH-Dienstes kann der Benutzer sich über den server1 auf den server2 anmelden:
user@linux:~$ ssh user@server1 Last login: Mon Jul 15 13:32:14 CEST 2013 from linux on ssh user@server1 ~ $ ssh user@server2 user@server2 ~ $
Im nächsten Artikel dieser Reihe schauen wir uns die weiteren Möglichkeiten der Datei authorized_keys an und erfahren, wie wir automatisiert Prozesse starten und Umgebungsvariablen setzen. Desweiteren gibt es einige wichtige Konfigurationsparameter für den OpenSSH-Dienst und -Client.
Dieser Text ist im Rahmen des Tipp des Monats von Michael Gisbers und Christian Hesse auf der Website des LPI Central Europe unterstützt von der Open Source Press veröffentlicht worden.