Tipp: OpenSSH mit ssh-agent

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.