SSH (Secure Shell)

SSH (Secure Shell) ist sowohl ein Programm als auch ein Netzwerkprotokoll, welches eine gesicherte und verschlüsselte Verbindung zwischen zwei Rechnern ermöglicht. SSH findet auf unterschiedliche Weise Anwendung:

• Ähnlich wie bei den Programmen rlogin, telnet und rsh kann man sich mit Hilfe des Programms ssh auf einem entfernten Computer einloggen, eine Konsole öffnen und dort Programme ausführen. Im Unterschied zu den alten Techniken ermöglicht das dabei verwendete SSH-Protokoll eine abhörsichere Verbindung zwischen den Rechnern.
• Das SSH-Protokoll wird ebenfalls bei den Programmen SFTP und SCP für den gesicherten Dateitransfer als Alternative zu den kryptographisch unsicheren ftp und rcp verwendet.
• Über SSHFS lässt sich ein entferntes Dateisystem mounten, wobei der Datentransfer dank des SSH-Protokolls verschlüsselt übertragen wird.
• Zudem wurde der SSH-Netzwerkdienst entwickelt, um Netzwerkprotokolle beliebiger Dienste mithilfe des SSH-Protokolls übertragen zu können. Dafür packt ein Hilfsprogramm auf dem Client die zu übertragenen Netzwerkpakete in das SSH-Protokoll und schickt diese dann mit entsprechenden Instruktionen an den SSH-Dienst des Servers. Dadurch ist es möglicht, die Netzwerkpakete zu verschlüsseln und auf der Gegenseite wieder zu entschlüsseln, bevor sie an den Netzwerkdienst weitergereicht werden, für den die Daten tatsächlich bestimmt sind. Auf diese Weise wird eine verschlüsselte Datenübertragung über unsichere Netzwerke hinweg auch für Netzwerkdienste realisiert, die normalerweise über keine eigene Verschlüsselung verfügen. Als Beispiel kann darüber eine ansonsten unverschlüsselte VNC-Verbindung abgesichert werden. Da hierfür die Daten des genutzen Dienstes in das SSH-Protokoll eingebettet werden, spricht man vom Tunneln.

Der SSH-Tunnel

Wurde die Firewall so konfiguriert, dass sie den Port 22 (SSH) für Verbindungen zum Internet zulässt, so ist es nun möglich, einen SSH-Tunnel zu einem Internetserver einzurichten. Dank des Aufbaus eines SSH-Tunnels ist man dann in der Lage, sämtliche Netzwerkdienste des Zielsystems, als auch die Netzwerkdienste der Rechner hinter dem Zielsystem zu nutzen – also auch jene Dienste, welche durch die Firewall eigentlich gesperrt sind.

Um bei unserem Beispiel aus dem Tunnel-Beitrag zu bleiben, installiert der Mitarbeiter dazu auf seinem privaten Internetserver (im Folgenden Tunnelserver genannt) einen SSH-Dienst, welcher an dem SSH-Standardport 22 lauscht und so auf seine Anfragen wartet. Auf dem Arbeitsplatz-PC installiert er ein beliebiges SSH-Client-Programm.

Die Grundkonfiguration der Tunnelsoftware (SSH-Client-Programm)

• Port X (Listen- oder auch Source-Port genannt): Hier muss ein beliebiger, freier Netzwerkport des eigenen Computers angeben werden, den die Tunnelsoftware als Kommunikationsport nutzen darf.
• Kommunikationspartner: Hier trägt man den Tunnelserver und den Port des SSH-Dienstes (Port 22) ein.
• Remote Host: Will man auf einen Dienst zugreifen, der auf dem Tunnelserver läuft, so lässt man diesen Eintrag hier leer oder trägt dort „localhost“ ein. Die folgenden Beispiele beziehen sich zunächst auf diese Einstellung. Soll ein Dienst angesprochen werden, der auf einem Rechner hinter dem Tunnelserver läuft, dann siehe unter „den SSH-Tunnel als Forward-Gateway verwenden“.
• Port Y (Remote- oder auch Destination-Port): Hier legt man fest, an welchen Dienst des Tunnelservers die Pakete schlussendlich geschickt werden sollen. Durch Port Forwarding des SSH-Dienstes werden dann alle Pakete nach ihrer Rückkonvertierung dorthin weitergeleitet.

Der Verbindungsaufbau

Sämtliche Pakete, welche nun an Port X des lokalen Computers eingehen, werden von der Tunnelsoftware automatisch verschlüsselt und in das SSH-Protokoll gepackt. So aufbereitet werden die Daten an den Tunnelserver auf Port 22 (zum SSH-Dienst) geschickt:

Eingehende Netzwerkpakete am PC-Port X-->Tunnelsoftware=verschlüsseln der Pakete + einbetten in das SSH-Protokoll-->weiterleiten an „Tunnelserver:Port 22“

Der SSH-Dienst des Tunnelservers extrahiert die Daten aus dem SSH-Protokoll und entschlüsselt sie. Auf diese Weise werden die Pakete in das Ursprungsformat zurückkonvertiert, ohne das der SSH-Dienst das Ursprungsformat kennen muss. Danach leitet der SSH-Dienst die Pakete an den Port Y des eigenen Servers weiter.

Tunnelserver:Port22=Eingang des SSH-Dienstes-->SSH-Dienst=extrahieren der Pakete + Entschlüsselung -->weiterleiten an „localhost:Port Y“ (Port Y=Port eines auf dem Internetserver laufenden Dienstes)

Beispiele

den ftp-Dienst des Tunnelservers nutzen

1. In der Tunnelsoftware trägt man für Port Y einfach 21 ein (21=Port des ftp-Dienstes, welcher auf dem Tunnelserver natürlich laufen muss, um ihn nutzen zu können).
2. Jetzt startet man mit Hilfe der Tunnelsoftware eine Sitzung, welche den Tunnel aufbaut und dabei dem SSH-Dienst des Tunnelservers mitteilt, dass die eingehenden Pakete dieser Sitzung per Port Forwarding an Port 21 seines eigenen Systems weiterzureichen sind.
3. Nun konfiguriert man ein beliebiges ftp-Client-Programm dahingehend, dass es sämtliche Anfragen an Port X des lokalen Computers schickt (dem Kommunikationsport der Tunnelsitzung). Mit anderen Worten: Zielsystem=“localhost:X“.
4. Nun startet man das ftp-Client-Programm, welches den lokalen Port X kontaktiert. Dank der Tunnelsoftware erhält der ftp-Client so eine Verbindung zum ftp-Dienst des Tunnelservers. Man kann damit genauso arbeiten, als wenn das ftp-Client-Programm eine direkte Verbindung zum ftp-Dienst des Servers aufgebaut hat. Im Hintergrund aber werden die Daten verschlüsselt übertragen und durch die Firewall getunnelt.

Kommunikation auf dem Client:

ftp Client, Ziel=“localhost:X“ (X=Eingangsport der Tunnelsoftware auf dem PC)-->Tunnelsoftware=Umwandeln zum SSH-Protokoll -->weiterleiten an „Tunnelserver:Port 22“

Kommunikation auf dem Server:

Tunnelserver:Port22=Eingang des SSH-Dienstes-->SSH-Dienst=Zurückkonvertieren in das Ursprungsformat-->weiterleiten an „localhost:21“ (21=Port des auf dem Tunnelserver laufenden ftp-Dienstes)

eMails per POP3 vom Tunnelserver abholen

1. Port Y=110 (da der POP3-Dienst auf dem Tunnelserver an Port 110 auf seine Anfragen wartet)
2. Tunnel-Sitzung starten
3. Beliebiges eMail-Programm so konfigurieren, dass es die POP3-eMails über „localhost:X“ abholt (X=Tunnel-Kommunikationsport des lokalen PCs). Kennung und Passwort für den eMail-Account angeben, eMails einlesen, fertig. Der Vorteil dieser Methode: Kennung und Passwort werden bereits verschlüsselt übertragen

Kommunikation auf dem Client:

eMail Client, Ziel=“localhost:X“ (X=Eingangsport der Tunnelsoftware auf dem PC)-->Tunnelsoftware=Umwandeln zum SSH-Protokoll -->weiterleiten an „Tunnelserver:Port 22“

Kommunikation auf dem Server:

Tunnelserver:Port22=Eingang des SSH-Dienstes-->SSH-Dienst=Zurückkonvertieren in das Ursprungsformat-->weiterleiten an „localhost:110“ (110=Port des auf dem Tunnelserver laufenden POP3-Dienstes)

Mehrere Tunnelsitzungen parallel starten

Wenn mehrere Tunnel-Sitzungen parallel gestartet werden sollen (z.B. eine Sitzung für ftp und eine Sitzung für POP3), so muss man pro Sitzung natürlich einen andern (lokalen) Port X festlegen.

Remote Host: Den SSH-Tunnel als Forward-Gateway verwenden

Bei der Konfiguration des SSH-Clients stößt man neben der Angabe für den Remote Port (Port Y) auch auf die Angabe eines möglichen Remote Hosts. Wird das Feld hier nicht leer gelassen bzw. nicht localhost dort eingetragen, so reicht der SSH-Dienst beim Port Forwarding die Netzwerkpakete an den dort angegebenen Rechner in seinem privaten Netz weiter:

Kommunikation auf dem Client:

Eingehende Netzwerkpakete an den eigenen PC auf Port X („localhost:X“)->Tunnelsoftware=Umwandeln zum SSH-Protokoll-->weiterleiten an „Tunnelserver:Port 22“

Kommunikation auf dem Server:

Tunnelserver:Port22=Eingang des SSH-Dienstes-->SSH-Dienst=Zurückkonvertieren in das Ursprungsformat-->weiterleiten an „AdresseDesRemoteHostsAusDemNetzDesTunnelservers: PortY“ (Y=Port des auf dem Remote Host laufenden Dienstes)

Hinweis: Befindet sich der Internetserver mit seinem SSH-Dienst in der DMZ, so muß auch der Rechner zu dem die Pakete weitergereicht werden sollen, in der DMZ stehen (es sei denn, die innere DMZ-Firewall lässt die Anfragen durch, was nicht zu empfehlen ist). Mit anderen Worten muss der Remote Host vom Tunnelserver aus ansprechbar sein, damit dieser Mechanismus funktioniert.

Der Zugriffsschutz

Sobald die SSH-Sitzung (der Tunnel) aufgebaut wird, muss man sich an dem Tunnelserver authentifizieren. Das geht wahlweise über Kennung und Passwort, oder über die Angabe einer Kennung und einer RSA-Schlüsseldatei.

Aber auch der Tunnelserver muss sich gegenüber dem Client identifizieren. Damit der Client sicher sein kann, dass der vermeintliche Tunnelserver auch der tatsächlich angeforderte Server ist, weist sich der Server mit einem RSA-Zertifikat aus.

Nach erfolgreicher Authentifizierung für die Sitzung ein temporärer Schlüssel erzeugt, mit dem die gesamte nachfolgende Kommunikation verschlüsselt wird, wobei je nach Protokollversion und Konfiguration ein anderer Verschlüsselungsalgorithmus zum Einsatz kommt.

Schwachstellen

Ethickerds machen darauf aufmerksam, dass die von SSH-1 verwendete Integritätsprüfung Schwachstellen aufweist, die es einem Angreifer ermöglichen, eine SSH-1-Sitzung auszuspähen, weshalb neuere Protokollversionen verwendet werden sollten. Dabei ist allerdings zu beachten, dass die aktuelle Generation SSH G3 auch den proprietären Snakeoil-Algorithmus „CryptiCore“ benutzt, welcher unter Cryptoexperten als „Security through obscurity“-Algorithmus verpönt ist. Es wird daher empfohlen, die Protokollversion SSH-2 zu verwenden.