32.4Authentifizierung mit Schlüsseln
Am sichersten ist die Verwendung des SSH-Servers, wenn Sie sich nicht mit einem Passwort authentifizieren, sondern mit einem Schlüssel. Dazu erzeugen Sie auf dem lokalen Rechner mit ssh-keygen ein Schlüsselpaar. Diesen Schlüssel sollten Sie durch eine Passphrase selbst verschlüsseln. Als Passphrase wird ein aus mehreren Wörtern bestehendes Passwort bezeichnet. Anschließend fügen Sie – noch per Passwort-Authentifizierung – den öffentlichen Schlüssel mit dem Kommando ssh-copy-id in die Datei .ssh/authorized_keys auf dem Server ein:
Wenn Sie die Passphrase-Frage einfach mit (¢) oder mit der Eingabe empty beantworten, verzichtet ssh-keygen auf die Verschlüsselung. Das ist bequem, weil es eine SSH-Nutzung ohne Passwort-Rückfrage ermöglicht. Sie gehen damit aber ein Sicherheitsrisiko ein: Jeder, dem Ihr Schlüssel auf dem Client-Rechner in die Hände gerät, kann sich ohne Weiteres auf allen Rechnern anmelden, auf denen Sie den öffentlichen Teil des Schlüssels installiert haben!
Das Kommando ssh-copy-id scheitert, wenn der Server nur eine Authentifizierung per Schlüssel zulässt. Zur Lösung dieses Henne-Ei-Problems müssen Sie die Schlüsselübertragung von einem anderen Client aus durchführen, der sich beim Server authentifizieren kann. Sie müssen in diesem Fall Ihre öffentliche Schlüsseldatei .ssh/id_rsa.pub über einen dritten Rechner zum Server übertragen und dort manuell am Ende der Datei .ssh/authorized_keys einfügen.
Wenn Sie nun eine Verbindung zum Zielrechner erstellen, tauscht ssh die Schlüsselinformationen aus. Ein Login ist nicht mehr erforderlich, Sie müssen aber die Passphrase der privaten Schlüsseldatei eingeben.
Sofern Ihre Schlüssel durch ein Passwort bzw. eine Passphrase abgesichert sind, haben Sie durch die Verwendung von Schlüsseln nur an Sicherheit, aber nicht an Komfort gewonnen. Eine sichere und doch einigermaßen bequeme Lösung bietet ssh-agent. Dieses Programm verwaltet alle privaten Schlüssel des Anwenders. Das Programm wird folgendermaßen gestartet:
Dadurch werden einige Umgebungsvariablen der aktuellen Konsole geändert. ssh-agent läuft als Hintergrundprozess weiter. Durch ssh-add können Sie nun Ihre privaten Schlüssel hinzufügen:
Von nun an verwendet ssh die von ssh-agent verwalteten Schlüsseldateien. Das heißt, Sie werden nie mehr nach dem Passwort für die Schlüsseldatei gefragt. Anstatt das Passwort bei jedem ssh-Kommando einzugeben, ist dies nur noch einmal erforderlich. Der große Nachteil von ssh-agent besteht darin, dass die Wirkung der Umgebungsvariablen auf eine einzige Konsole beschränkt ist.
Unter Gnome kümmert sich standardmäßig der gnome-keyring-daemon um Passwörter und SSH-Schlüssel. Der erstmalige Zugriff auf die Daten erfordert zumeist einen richtigen Login (vermeiden Sie Auto-Logins durch den Display Manager!) oder die Angabe des Master-Passworts. Zur Administration der gespeicherten Schlüssel und Passwörter verwenden Sie das Programm seahorse.
Nicht immer funktioniert der passwortfreie Login beim SSH-Server auf Anhieb. Schuld sind diverse Sicherheitseinstellungen. Falls sshd_config die Einstellung StrictModes yes enthält, wird die Datei authorized_keys nur berücksichtigt, wenn deren Zugriffsrechte sehr restriktiv eingestellt sind. Wurde die Schlüsseldatei von ssh-copy-id erstellt, ist das zumeist nicht der Fall. Abhilfe schaffen die beiden folgenden Kommandos:
Bei Fedora-, CentOS- und RHEL-Servern tritt häufig ein weiteres Problem auf: Der von ssh-copy-id erzeugten Schlüsseldatei fehlen die erforderlichen SELinux-Kontextinformationen. Abhilfe:
Fehlersuche
Wenn der SSH-Login nicht wie erwartet funktioniert, führen Sie das ssh-Kommando mit der zusätzlichen Option -v aus. ssh liefert dann eine Menge Debugging-Meldungen. Die Option kann bis zu dreimal angegeben werden, also -v -v -v. ssh protokolliert dann entsprechend detaillierter.
Sobald der Aufbau einer SSH-Verbindung mit dem Schlüssel funktioniert und keine Login-Aufforderung mehr erscheint, können Sie sich überlegen, den Passwort-Login ganz zu deaktivieren. Dazu verändern Sie auf dem Server die Konfigurationsdatei sshd_config. Entscheidend sind zwei Zeilen:
Damit ist von nun an eine SSH-Authentifizierung nur noch mit Schlüsseln möglich. Passen Sie aber auf, dass Sie sich nicht selbst aus Ihrem System aussperren! Wenn Sie den Schlüssel auf Ihrem Client-Rechner verlieren, beispielsweise weil Ihnen Ihr Notebook gestohlen wird und Sie kein Backup haben, können Sie sich auf dem Server nicht mehr einloggen! Es ist wie so oft: Jede zusätzliche Sicherheit bezahlen Sie durch geringere Flexibilität ...
Bis jetzt bin ich davon ausgegangen, dass Sie nur einen einzigen, selbst erzeugten Schlüssel verwenden. Aber vielleicht haben Sie mehrere Schlüssel, die Sie in der Vergangenheit auf unterschiedlichen Rechnern eingesetzt haben; oder Sie wollen unterschiedliche Schlüssel für unterschiedliche externe Server verwenden; oder es übergibt Ihnen jemand eine Schlüsseldatei, damit Sie einen weiteren Rechner administrieren können.
Die einfachste Lösung besteht darin, auf dem Client-Rechner im Verzeichnis .ssh die Datei config einzurichten. Vergessen Sie chmod 600 nicht! Diese Datei enthält mit dem Schlüsselwort IdentityFile Referenzen auf alle Schlüsseldateien, beispielsweise so:
In dieser Konfiguration testet das ssh-Kommando einfach alle Schlüssel, bis einer passt. Sie können der config-Datei noch mehr »Intelligenz« verleihen, wenn Sie die Einträge nach Hosts gruppieren. Damit können Sie für jeden Host zusätzlich angeben, welcher Port, welcher Benutzer etc. verwendet werden soll. Die folgenden Zeilen veranschaulichen die Syntax; mehr Details finden Sie in man ssh_config.