Vertraue Allah, aber binde dein Kamel an. -- Anonym
16 Secure Shell
Dieses Kapitel behandelt eine wichtige Frage der Administration: Wie kann man die verschiedenen Server im eigenen Netzwerk administrieren, ohne zum Turnschuh-Admin zu mutieren? Eine Lösung ist, mit der Secure Shell (SSH) zu arbeiten – dem Remote-Administrationswerkzeug für Unix-Server schlechthin. Das durch das freie OpenSSH (www.openssh.org) implementierte SSH-Protokoll bietet ähnlich wie der Telnet-Dienst Login-Dienste <Auch wenn SSH ein Standard und damit nicht auf Unix-Systeme beschränkt ist, wird es meist nur von Unix-Servern genutzt.> über das Netzwerk an – mit dem Unterschied, dass bei SSH jegliche Kommunikation inklusive der übertragenen Passwörter verschlüsselt stattfindet.
Remote- Administration
Einmal verbunden, können alle Arbeiten so vorgenommen werden, als wäre man lokal am System angemeldet. Damit nicht genug, SSH kann unter anderem auch folgende Dienste ersetzen:
- Telnet
- Dass man sich über SSH remote einloggen und dann auf einer Shell arbeiten kann, ist das wohl bekannteste Feature von SSH. Im Gegensatz zu Telnet ist es bei SSH nicht möglich, Passwörter einfach abzuhören oder gar Kommandos in eine aufgebaute Verbindung einzufügen.
- r-Dienste
- Wer heutzutage anfängt, sich mit Unix zu beschäftigen, lernt Gott sei Dank kaum noch die berüchtigten r-Dienste wie rsh, rcp, rlogin etc. kennen; bei uns haben Sie sie auch nur am Rande kennengelernt. Diese Programme hatten so viele Sicherheitslücken, dass diese hier aufzuzählen fast den Rahmen des Kapitels sprengen würde. Jedenfalls kann man auch über SSH Dateien mit scp remote kopieren, und das Einloggen funktioniert ja bekanntermaßen auch.
- ftp
- FTP und SSH? Manche mögen das für einen Widerspruch halten, aber mit dem entsprechenden Client (sftp) kann man SSH-Server, die dieses Feature aktiviert haben, als sichere Fileserver nutzen, ohne dabei auf die Features des FTP-Protokolls verzichten zu müssen.
- Remote-Desktop
- Durch das optionale Feature der X11-Weiterleitung können auch Fenster des SSH-Servers auf dem lokalen Client angezeigt werden.
16.1 Das Protokoll 
Bevor wir aber mit der Praxis starten, wollen wir einen kurzen Blick auf das von SSH verwendete Protokoll werfen. Eigentlich gibt es »das Protokoll« bei SSH nicht, man unterscheidet zwei zueinander inkompatible Varianten: SSH-Protokoll 1 und SSH-Protokoll 2.
16.1.1 SSH-Protokoll 1 
Das Protokoll Version 1 benutzt das bekannte RSA-Protokoll zum Schlüsselaustausch und setzt dann für die eigentliche Kommunikation die symmetrischen Verfahren 3DES, Blowfish oder auch IDEA an. Ursprünglich war auch noch RC4 vorgesehen, das aber aufgrund von Problemen bezüglich der Implementierung nicht genutzt wird. Auch wird IDEA zumindest von OpenSSH nicht verwendet, da dieser Algorithmus in einigen Ländern Patenten unterliegt und seine Verwendung in freier Software somit problematisch ist.
Bekannte Probleme
Das Problem bei Protokoll 1 ist viel eher der einfache CRC-Algorithmus zur Prüfsummenberechnung.
Es ist nämlich bekannt, dass dieser diverse Angriffe wie zum Beispiel das Einfügen von Daten in die verschlüsselte Kommunikation erlaubt. Auch wenn über die Jahre mehrere Fixes und Workarounds dieses Problem eingegrenzt haben, so ist im Allgemeinen doch die neuere Variante 2 dem Protokoll Version 1 vorzuziehen.
16.1.2 SSH-Protokoll 2
Die Version 2 des SSH-Protokolls wurde entwickelt, um erstens das Problem mit dem anfälligen CRC-Algorithmus zu lösen und zweitens das damals noch aktuelle Patentproblem bezüglich RSA zu umgehen. Diese Patente sind aber mittlerweile ausgelaufen, und so kann RSA auch von jedermann ohne Einschränkung genutzt werden. Trotz alledem nutzt das Protokoll Version 2 die patentrechtlich absolut freien Algorithmen DSA und DH. Außerdem wurde das CRC-Problem durch die Verwendung eines HMAC-Algorithmus gelöst. Davon abgesehen kann man mit der Protokollversion 2 auch noch eine Vielzahl weiterer symmetrischer Algorithmen nutzen.
