Secure Shell

SSH - Authentifizierung

Die Scure Shell kennt mehrere Verfahren der Authentifizierung. Linux verwendet in der Regel die Implementierung von OpenSSH, die sich inzwischen auch auf vielen UNIX-Varianten als Standard durchgesetzt hat. Daher bezieht sich diese Darstellung auch auf OpenSSH, und zwar mit der sichereren Protokoll-Version 2.
Die zentrale Konfigurationsdatei des OpenSSH-Servers ist /etc/ssh/sshd_config. Hier sollte zu Beginn die Zeile

Protocol 2

stehen. Die ältere Version 1 ist mit bekannte Sicherheitsmängeln behaftet und wird damit ganz abgeschaltet.
Des weiteren ist ein Arbeiten mit X11 über SSH nur mit dem Eintrag

X11Forwarding yes

möglich. Dies ist zwar Default-Einstelllung, sollte bei der Fehlersuche aber überprüft werden.
Abgesehen von diesen Hinweisen soll hier aber nur auf Einstellungen, die die Authentifizierung betreffen, eingegangen werden.

Host-Authentifizierung

Die erste Authentifizierung kommt für manche Anwender überraschend. SSH kümmert sich nicht nur um die Identität des Anwenders, sondern auch der Maschine, mit der eine Verbindung aufgebaut werden soll. Schließlich kann Host-Namen und sogar IP-Adresse nicht wirklich vertraut werden, zu leicht sind Fälschungen (DNS- und IP-Spoofing).
Also wird anhand des im Verzeichnis $HOME/.ssh/ abgelegten öffentlichen Host-Schlüssels die Identität des Zielhosts überprüft. Wenn bei der ersten Verbindugsaufnahme dieser Schlüssel dort noch nicht hinterlegt wird, bekommt der Anwender eine Warnung und wird gefragt, ob er den Host-Schlüssel übernehmen will.

The authenticity of host '[hermes]:2202 ([192.168.111.254]:2202)' can't be established.
RSA key fingerprint is c0:71:63:be:61:ca:ab:4d:5d:fd:62:bc:89:cb:06:64.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[hermes]:2202,[192.168.111.254]:2202' (RSA) to the list of known hosts.

Von da an kann die Identität des Hosts bei jeder Verbindung überprüft werden; der User wird damit erst wieder konfrontiert, wenn sich der Schlüssel des Hosts geändert hat - z.B. nach der Neuinstallation des Betriebssystems oder eben bei einer gefälschten IP-Adresse.

Passwort-Authetifizierung

Der einfachste Fall: Durch die verschlüsselte SSH-Verbindung wird das Passwort des Users als Ganzes an den SSH-Server übergeben, der die Übereinstimmung mit dem Passwort des Ziel-Accounts überprüft (dieser muss nicht den gleichen User-Namen haben wie auf dem Client-System). Diesem simplen Verfahren wird auch etwas misstraut, so dass es i.d.R. in der sshd_config mit folgender Zeile abgeschaltet ist:

PasswordAuthentication No

Diese Einstellung ist auf "Yes" zu ändern, wenn dem SSH-Client kein anderes Authentifizierungsverfahren zur Verfügung steht.

Keyboard Interactive

Die modernere Authentifizierung mit Passwörtern heißt "Keyboard Interactive". Dabei werden die Tastatureingaben des Anwenders in einem direkten Kanal zur Authentifizierung an das PAM-System des Zielhosts weitergegeben. PAM steht für Pluggable Authentication Moduls und ist heute der de-facto-Standard auf Linux und einigen UNIX-Varianten (z.B. Solaris und AIX). Beim Verfahren "Keyboard Interactive" kommt auch die Aufforderung zur Eingabe des Passworts von PAM und nicht vom SSH-Client. Auch das soll vor Fälschungen schützen. Verantwortlich dafür ist in der sshd_config die Zeile:

UsePAM yes

In diesem Fall werden auch Einstellungen der PAM-Konfiguration in /etc/pam.d/sshd wirksam, auf die aber hier nicht eingegangen werden soll.

User Key

Einmal eingerichtet, kombiniert diese Authentifizierungsmethode Bequemlichkeit und Sicherheit. Der Anwender hinterlegt in der Datei $HOME/.ssh/authorized_keys des Zielaccounts seinen öffentlichen Schlüssel. Sein SSH-Client muss wiederum den geheimen privaten Schlüssel kennen. Dieser liegt, je nach Format, per Default in den Dateien $HOME/.ssh/id_rsa und $HOME/.ssh/id_dsa; es kann aber auch eine andere Datei auf der SSH-Kommandozeile angegeben werden.
Für die Erzeugung von SSH-Schlüsseln ist das Programm ssh-keygen zuständig. Ein Aufruf ohne Parameter erzeugt Standard-Schlüsselpaare und legt sie im Verzeichnis .ssh ab. Das Programm kann einiges mehr, man lese dazu die Manual-Seiten (man ssh-keygen).
In der Konfigurationsdatei sshd_config geben folgende Zeilen Auskunft über die Schlüssel-Authentifizierung:

#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile .ssh/authorized_keys

Sie sind auskommentiert, da dies sowieso die Default-Werte darstellt. Aus der letzten Zeile ersieht man, wo im Verzeichnis $HOME des Ziel-Accounts die öffentlichen Schlüssel der User, die sich über SSH mit User Key einloggen wollen, hinterlegt sein müssen. Schließlich können entsprechend kompilierte Versionen von SSH private Schlüssel sogar direkt von einer Smartcard lesen.
Ein Xterm auf "remotehost" startet man über SSH folgendermaßen:

ssh -i key_file -X remoteuser@remotehost xterm

-i gibt die Datei mit dem privaten User Key an.
-X steht für "X11 Forwarding", also das vorher beschriebene Tunneln der X11-Kommunikation.

Zertifikate

Zusätzlich können SSH-Schlüssel mit Zertifikaten von einer hoffentlich vertrauswürdigen Zertifikatsstelle bestätigt werden. Diese steht mit Ihrem Zertifikat, das anhand Ihres öffentlichen Schlüssels verifiziert werden kann, für die Identität des Anwenders, der sich mit User Key authentifizieren will, gerade. Mit einer entsprechenden Infrastruktur kann man so zusätzliche Sicherheit erreichen.
OpenSSH unterstützt dieses Verfahren allerdings nicht Out-of-the-box, sondern nur mit Zusatzmodulen.

Kerberos

Dagegen unterstützt OpenSSH die Authentifizierung über eine Kerberos-Infrastruktur. Der entsprechende Aufruf lautet:

ssh -K -X remoteuser@remotehost xterm