OpenSSH Public Key Authentifizierung - Teil 2

Autoren: Michael Gisbers und Christian Hesse

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. Die 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: ~ $ set | 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 – das Kommando `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 July 15 13:24:39 CDT 2013 on ssh from linux
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 July 15 13:32:14 CDT 2013 on ssh from linux
user@server1 ~ $ ssh user@server2
Password:
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.