»Vertraue Allah, aber binde dein Kamel an.«
– anonym

21 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 [Fn. 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 Übertragung der 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 bereits 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 auch nur am Rande von ihnen erfahren. Diese Programme hatten so viele Sicherheitslücken, dass diese hier aufzuzählen wohl 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 es 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.

21.1 Das Protokoll

Bevor wir aber in die Praxis einsteigen, 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: das SSH-Protokoll 1 und das SSH-Protokoll 2.

21.1.1 SSH-Protokoll 1

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 ein. 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 große Problem bei Protokoll 1 ist allerdings der einfache CRC-Algorithmus zur Prüfsummenberechnung. Von diesem ist nämlich bekannt, dass er 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, ist im Allgemeinen doch die neuere Variante 2 dem Protokoll 1 vorzuziehen.

21.1.2 SSH-Protokoll 2

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 Version 2 auch noch eine Vielzahl weiterer symmetrischer Algorithmen nutzen.

---

Ihre Meinung

Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de.