© Thomas Kerzner, photocase.com

Kaum ein Werkzeug bestimmt den Alltag des Administrators mehr als die Secure Shell, die SSH. Fernwartung von Linux- oder Unix-Rechnern ist heute ohne sie nicht mehr vorstellbar. Deshalb widmet sich dieser Artikel ganz dem Teil 1.113.7 der LPI-Prüfung.

Telnet und die Remote Shell »rsh« waren bis in die 90er Jahre der Weg, wenn sich ein Benutzer über das Netz an einem Unix-Rechner anmelden wollte. Weil beiden Protokollen jeglicher Schutz vor Angreifern fehlt, gelten sie heute als überholt. Beide übertragen das eingegebene Passwort sowie alle übermittelten Daten im Klartext, also unverschlüsselt.

OpenSSH

Ein geeigneter Nachfolger fand sich mit der SSH, der Secure Shell [1]. Heute kommt üblicherweise die freie Implementierung OpenSSH [2] zum Einsatz. Das LPI-Lernziel 1.113.7 widmet sich diesem Programm, seiner Konfiguration und Anwendung.

SSH verschlüsselt die komplette Datenübertragung und vereitelt damit jeden Versuch, Passwörter oder übermittelte Daten abzuhören. Neben der klassischen Benutzerauthentifizierung per Passwort beherrscht SSH auch modernere Verfahren, vor allem die Authentifizierung mit einem kryptographischen Schlüsselpaar. Auch der Client prüft, ob er sich mit dem gewünschten Server verbunden hat oder ob sich ein Angreifer als so genannter Man in the Middle einschleusen will.

Ursprünglich war SSH für den Remote Login gedacht. Heute kennt es viele Erweiterungen, etwa um Dateien zu kopieren, die Oberfläche von X11-Programmen auf dem Client anzuzeigen oder beliebige TCP-Ports weiterzuleiten [3].

Die erste Session

Moderne Linux-Distributionen installieren den SSH-Client standardmäßig. Den zugehörigen Server »sshd« befördern Suse und Red Hat ebenfalls auf die Platte, unter Ubuntu hilft ein »apt-get install openssh-server«. Tabelle 1 gibt einen Überblick über die wichtigsten Konfigurationsdateien und die Pfade der Schlüsselfiles. LPI-Prüfungskandidaten sollten diese Pfade kennen.

Vom Client ausgehend baut der Benutzer mit »ssh SSH-Server« eine Verbindung zu dem Server auf. Mit dem Befehl » ssh -v SSH-Server« liefert das Programm Debugging-Informationen (Abbildung 1), die über jeden Schritt beim Remote Login informieren.

Abbildung 1: Der User baut eine SSH-Verbindung mit dem lokalen SSH-Server auf. Im Debug-Modus mit der Option »-v« zeigt der Client den komplette Verbindungsaufbau, Pfade, Verschlüsselungsmechanismen und erlaubte Authentifizierungsmethoden ebenso wie eventuell fehlerhafte Dateiberechtigungen.

Das Clientprogramm »ssh« lädt zunächst systemspezifische Standardeinstellungen aus »/etc/ssh/ssh_config« und startet danach den Verbindungsaufbau. Falls der Anwender eigene Schlüsselpaare besitzt, liest sein Client auch die privaten Schlüssel (die Zeilen mit »identity file« in Abbildung 1). Anschließend einigen sich Client und Server auf SSH-Version 1 oder 2 – aufgrund von Schwächen in Version 1 ist dessen Nachfolger unbedingt vorzuziehen.

Der Server authentifiziert sich nun gegenüber dem Client. Die Erfolgsmeldung lautet »host Servername is known and matches the RSA host key«: Jetzt weiß der Client, dass er mit dem gewünschten Server spricht. Danach authentifiziert sich der Client. In Abbildung 1 versucht er das zunächst per RSA- und DSA-Schlüsselpaar (RSA ist nach seinen Erfindern Rivest, Shamir, Adleman benannt, DSA steht für Digital Signature Algorithm). Weil jedoch kein Key passt, fällt der Client auf die Keyboard-Interactive-Technik zurück und der Server verlangt ein Passwort.

Will sich der User in einen Account einloggen, der anders heißt als seine lokale Benutzerkennung, dann teilt er das per »ssh -l Benutzername SSH-Server« oder kurz »ssh Benutzername@SSH-Server« mit. Abbildung 1 zeigt, wie sich ein User über SSH als »root« via Passwort am lokalen Linux-System anmeldet.

Bei der Passwort-Authentifizierung sendet der Client das Passwort an den Server und dieser prüft, ob das Wort korrekt ist. Beim Einsatz eines RSA- oder DSA-Schlüsselpaares ist der Ablauf anders. Das Paar besteht aus einem öffentlichen und einem privaten Key. Der private Key muss geheim bleiben, selbst der SSH-Server erfährt ihn nicht. Der Server kennt nur den zugehörigen öffentlichen Schlüssel. Der Client beweist durch eine so genannte digitale Signatur, dass er das zu einem öffentlichen Key passende Gegenstück besitzt. Der Server lässt bei der Public-Key-Authentifizierung also den Benutzer nur ins System, wenn er dessen öffentlichen Key kennt (anhand der Datei »~/.ssh/authorized_keys«) und weiß, dass der User den privaten hat.

SSH-Schlüssel erzeugen

Mit dem Programm »ssh-keygen« erzeugt der Benutzer ein Schlüsselpaar im Verzeichnis »~/.ssh« (Abbildung 2). Der private RSA-Schlüssel landet in der Datei »id_rsa«, der öffentliche Schlüssel in »id_rsa.pub«. Letzteren muss der Anwender auf dem SSH-Server an die Datei »~/.ssh/authorized_keys« anfügen, den ersten braucht er auf dem Clientrechner, um sich auszuweisen.

Abbildung 2: Der Befehl »ssh-keygen« erzeugt Paare aus SSH-Schlüsseln für den Benutzer. Der für das Entschlüsseln erforderliche Private Key ist vertraulich, während der Public Key öffentlich ist und zur Verschlüsselung dient. Mit dem FIngerabdruck verifiziert der Benutzer später die Authentizität des Schlüssels.

Das Keygen-Programm fragt den Benutzer nach einer Passphrase für den privaten Schlüssel und zeigt den Key-Fingerprint an. Die Passphrase schützt den privaten Key, falls ein Angreifer es schafft, dieses File zu klauen: Ohne Passphrase kann er mit dem privaten Key nichts anfangen. Aber auch Schlüsselpaare ohne Passwortschutz sind sinnvoll, etwa wenn ein Skript ohne Benutzerinteraktion ablaufen und SSH verwenden muss.

In der Standardeinstellung erzeugt »ssh-keygen« RSA-Schlüssel. Wer DSA will, gibt das mit dem Parameter »-t dsa« in Auftrag. Die Option »-b« setzt die Größe des Schlüssels, in der Regel 1024, 2048 oder 4096 Bit. Wichtig sind die Zugriffsrechte, nur der Eigentümer darf den privaten Key lesen oder schreiben.

Auch Rechner haben Schlüssel (Abbildung 3). Bei der ersten Anmeldung an einem Server muss der User mit einem ausdrücklichen »yes« bestätigen, dass der Hostkey stimmt. Dazu gibt der SSH-Client einen Fingerprint des öffentlichen SSH-Serverschlüssels aus:

mheller@shuttle:~> ssh root@localhost
The authenticity of host 'localhost U(127.0.0.1)' can't be established.
RSA key fingerprint is 3b:60:59:24:f8:51:U62:39:41:af:fd:c0:5d:93:b7:d4.
Are you sure you want to continue Uconnecting (yes/no)?

Der Benutzer vergleicht idealerweise diesen Fingerprint mit den Angaben, die er vom Admin des Servers erfährt. Selbst wenn er dem Key beim ersten Mal blind vertraut, fällt immerhin auf, wenn sich der Key später ändert, da der Client den Key in »~/.ssh/known_hosts« dauerhaft speichert. Das wäre ein Hinweis auf einen Man-in-the-Middle-Angriff – vielleicht hat aber auch nur der Admin den Server neu installiert und ihm einen neuen Key verpasst.

Abbildung 3: Auch der Server hat einen privaten und einen öffentlichen Schlüssel. Diese liegen im Verzeichnis der Konfigurationsdateien »/etc/ssh«, in dem auch die Konfigurationen des Servers in »/etc/ssh/sshd_config« und des Clients (»/etc/ssh/ssh_config«) zu finden sind.

Weil viel zu wenige SSH-Benutzer den Fingerprint tatsächlich prüfen, empfiehlt es sich sehr, dass Admins eine zentrale Liste an öffentlichen Keys ihrer SSH-Server pflegen. Dazu dient »/etc/ssh/ssh_known_hosts« (Tabelle 1).

Konfiguration

In »/etc/ssh/ssh_config« gibt der Admin für alle lokalen User eine SSH-Client-Konfiguration vor. Diese dürfen ihre eigenen Vorlieben in »~/.ssh/config« eintragen; die Einstellungen hier überstimmen die Vorgaben. Die Manpages zu »ssh_config« und zu »ssh« erklären die Optionen und Parameter des SSH-Clients.

Beachtung verdienen »Compression« zur Komprimierung der Daten, »ForwardX11« zur Weiterleitung der grafischen Ausgabe von X-Window-Anwendungen und die Option »Port«, die angibt, auf welchem Port der SSH-Server lauscht. Der Benutzer kann alle Parameter auch in der Kommandozeile eingeben: »ssh -X -C -P 54321 User@Host« startet eine komprimierte SSH-Verbindung zu Port 54321 mit X11-Forwarding.

Die Konfigurationsdatei des Servers liegt in »/etc/ssh/sshd_config« (Abbildung 3). Hier kann der Administrator die Weiterleitung von grafischen Anwendungen zulassen, indem er »X11Forwarding« auf »yes« setzt, oder die Datenkompression Server-seitig aktivieren. Mit der Einstellung »PermitRootLogin« unterbindet er Root-Logins. Wer auf dem Zielserver dennoch Root-Aufgaben erledigen muss, loggt sich als normaler User ein und nutzt »sudo« oder »su«.

In der Konfiguration des Servers stehen dem SSH-Client verschiedene Authentifizierungsverfahren für die Anmeldung zur Verfügung (Abbildung 1): »publickey« setzt auf RSA- oder DSA-Benutzerschlüssel. Bei »password« prüft »sshd« das User-Passwort, während »keyboard-interactive« auch kompliziertere Passwortmechanismen unterstützt [4]. Wenn möglich empfiehlt es sich, nur »PubkeyAuthentication = yes« zu gestatten und die anderen auf »= no« zu setzen.

Tunnel, Transfers und mehr

Wie vielseitig SSH ist, zeigt sich zum Beispiel bei den Tunneln. Ohne viel Aufwand erlauben sie Wartungszugänge zu Ports ferner Maschinen. Nach dem Aufruf »ssh -L Local_Port:Remote_Server:Remote_Port Username@SSH-Server« leitet SSH alle Anfragen, die an den lokalen Port gehen, durch die sichere Verbindung zum SSH-Server und von dort weiter zum Remote-Server [3].

Der Remote-Copy-Befehl »scp« ist dem RSH-Tool »rcp« nachempfunden, nutzt aber SSH. Das jüngere Programm »sftp« ist der sichere Bruder des bekannten »ftp«, wobei der Serverdienst ein ganz normaler SSH-Server ist. KDE stellt seinen Anwendungen die beiden IO-Slaves »fish« und »sftp« zur Verfügung und bindet damit ferne Verzeichnisse ein.

Die LPI-Prüfung konzentriert sich auf die Basisaufgaben mit SSH: Sie verlangt, dass die Kandidaten die Konfigurationsdateien und deren wichtigste Parameter kennen, die Namen der Binaries sowie einige Aufrufparameter. (mfe)