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.

© Thomas Kerzner, photocase.com

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.

Sie können diesen Artikel als PDF für 99 Cent kaufen. Klicken Sie dazu einfach auf eine der beiden Bezahloptionen Paypal oder ClickandBuy.

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.