Was ist ei­gent­lich SSH? Die Secure Shell einfach erklärt

SSH er­mög­licht es, dass zwei Computer eine sichere und direkte Ver­bin­dung innerhalb eines mög­li­cher­wei­se un­si­che­ren Netzes – wie dem Internet – aufbauen. Das ist notwendig, damit Dritte nicht den Da­ten­strom abgreifen können und so sensible Daten in die falschen Hände geraten. Auch vor Secure Shell gab es Mög­lich­kei­ten, direkte Ver­bin­dun­gen zwischen zwei Rechnern her­zu­stel­len, doch die ent­spre­chen­den An­wen­dun­gen wie Telnet, Remote Shell oder rlogin waren durchweg unsicher. SSH ver­schlüs­selt die Ver­bin­dung zwischen zwei Rechnern und er­mög­licht, dass von einem Computer aus ein zweiter bedient werden kann.

SSH sorgt aber nicht nur für eine ver­schlüs­sel­te Ver­bin­dung, sondern ge­währ­leis­tet darüber hinaus, dass nur Ver­bin­dun­gen zwischen den dafür vor­ge­se­he­nen Computern her­ge­stellt werden (es ist also keine Man-in-the-Middle-Attack möglich) und die ent­spre­chen­den Daten nicht auf dem Weg zum Empfänger ma­ni­pu­liert werden können. Der Zugriff auf den ent­fern­ten Rechner erfolgte ur­sprüng­lich stets über die Kom­man­do­zei­le. Über sie richtet man Befehle an das entfernte Gerät. In­zwi­schen ist es aber auch möglich, mithilfe von Virtual Network Computing (VNC) eine grafische Be­nut­zer­ober­flä­che (die bei Servern gar nicht immer vorhanden ist) auf den eigenen Rechner zu spiegeln und so den anderen Computer zu steuern.

SSH hat viele ver­schie­de­ne Ein­satz­ge­bie­te:

• Ver­wal­tung von Servern, auf die man nicht lokal zugreifen kann

• Sichere Über­mitt­lung von Dateien

• Sicheres Erstellen von Back-ups

• Ver­bin­dung zwischen zwei Rechnern mit Ende-zu-Ende-Ver­schlüs­se­lung

• Fern­war­tung von anderen Computern

Die Ent­wick­lung von SSH hat auch andere Pro­to­kol­le be­ein­flusst. So hat man bei­spiels­wei­se das unsichere FTP-Protokoll, mit dem es möglich ist, Dateien auf einen Server zu laden und von dort dann wieder her­un­ter­zu­la­den, zum SSH File Transfer Protocol (SFTP) wei­ter­ent­wi­ckelt.

Ein Vorteil von SSH ist, dass das Protokoll auf allen gängigen Be­triebs­sys­te­men läuft. Da es sich ur­sprüng­lich um eine Unix-Anwendung handelt, ist es zudem von Haus aus auf allen Linux-Dis­tri­bu­tio­nen und auf macOS im­ple­men­tiert. Aber auch unter Windows lässt sich SSH verwenden, sofern Sie ein ent­spre­chen­des Programm in­stal­lie­ren.

Secure Shell ist 1995 ur­sprüng­lich als Open-Source-Projekt ent­stan­den. Im gleichen Jahr gründete der Ent­wick­ler Tatu Ylönen jedoch bereits eine Firma, die das Protokoll wei­ter­ent­wi­ckeln sollte. So hat sich das an­fäng­lich offene Projekt immer mehr zu einer pro­prie­tä­ren Software wei­ter­ent­wi­ckelt. Die Netz­ge­mein­de hat das aber nicht einfach hin­ge­nom­men und ent­wi­ckel­te auf Basis des SSH-1-Pro­to­kolls eine offene Ab­spal­tung: OpenSSH. Da aber auch die Firma SSH Com­mu­ni­ca­ti­on Security weiter an Secure Shell arbeitet, exis­tie­ren in­zwi­schen zwei kon­kur­rie­ren­de Pro­to­kol­le ne­ben­ein­an­der. Zum einen hat man das pro­prie­tä­re SSH-2-Protokoll (eine Wei­ter­ent­wick­lung, da in SSH-1 Si­cher­heits­lü­cken bekannt wurden) und zum anderen OpenSSH.

OpenSSH und das kom­mer­zi­el­le SSH sind sowohl von Funk­ti­ons­wei­se als auch Umfang annähernd gleich­wer­tig. Der Un­ter­schied betrifft vor allem die Kosten, aber ebenso den Support. Ent­schei­det man sich für das Produkt der SSH Com­mu­ni­ca­ti­on Security, erhält man zu­sätz­lich einen 24/7-Support. Gerade bei großen Un­ter­neh­men mit wech­seln­den IT-Ver­ant­wort­li­chen kann dies sinnvoll sein. OpenSSH bietet hingegen durch die Open-Source-Gemeinde den Vorteil, dass das Projekt stetig und von vielen Teil­neh­mern wei­ter­ent­wi­ckelt wird.

Secure Shell setzt mehrere Ver­schlüs­se­lungs- und Au­then­ti­fi­zie­rungs­tech­ni­ken ein. So wird zum einen si­cher­ge­stellt, dass Da­ten­strö­me weder gelesen noch ma­ni­pu­liert werden können. Zum anderen können dadurch nur au­to­ri­sier­te Teil­neh­mer mit­ein­an­der Kontakt aufnehmen.

In einem ersten Schritt au­then­ti­fi­zie­ren sich SSH-Server und Client un­ter­ein­an­der. Der Server sendet ein Zer­ti­fi­kat an den Client, um zu ve­ri­fi­zie­ren, dass es sich wirklich um den richtigen Server handelt. Nur bei der ersten Kon­takt­auf­nah­me besteht die Gefahr, dass sich ein Dritter zwischen die beiden Teil­neh­mer schaltet und so die Ver­bin­dung abfängt. Da das Zer­ti­fi­kat selbst auch ver­schlüs­selt ist, kann es nicht imitiert werden. Weiß der Client einmal, wie das richtige Zer­ti­fi­kat lautet, kann kein anderer mehr vor­täu­schen, über den ent­spre­chen­den Server Kontakt auf­zu­neh­men.

Nach der Server-Au­then­ti­fi­zie­rung muss sich aber auch der Client gegenüber dem Server als zu­gangs­be­rech­tigt ausweisen Dafür kann man ein Passwort einsetzen. Dieses – be­zie­hungs­wei­se der ver­schlüs­sel­te Hashwert davon – ist auf dem Server hin­ter­legt. Daraus re­sul­tiert aber auch, dass Nutzer bei jeder Anmeldung auf einem anderen Server während der gleichen Sitzung das Passwort ein­ge­ge­ben müssen. Deshalb gibt es als al­ter­na­ti­ve Mög­lich­keit der cli­ent­sei­ti­gen Au­then­ti­fi­zie­rung die Ver­wen­dung des Schlüs­sel­paa­res Public Key und Private Key.

Den Private Key erstellt man in­di­vi­du­ell für seinen eigenen Computer und sichert diesen mit einer Pass­phra­se ab, die länger sein sollte als ein typisches Passwort. Der Private Key ist aus­schließ­lich auf dem eigenen Rechner ge­spei­chert und bleibt stets geheim. Möchte man eine SSH-Ver­bin­dung aufbauen, gibt man zunächst die Pass­phra­se ein und öffnet so den Zugang zum Private Key.

Auf dem Server wiederum (wie auch auf dem Client selbst) liegen ebenfalls noch Public Keys. Der Server erstellt mit seinem Public Key ein kryp­to­gra­fi­sches Problem und sendet dies an den Client. Dieser wiederum ent­schlüs­selt das Problem mit dem eigenen Private Key, sendet die Lösung zurück und teilt so dem Server mit, dass er eine recht­mä­ßi­ge Ver­bin­dung aufbauen darf.

Während einer Sitzung muss man die Pass­phra­se nur einmal eingeben, um Ver­bin­dung zu beliebig vielen Servern auf­zu­neh­men. Zum Schluss der Sitzung melden sich die Nutzer an ihren lokalen Rechnern ab und stellen so sicher, dass kein Dritter, der phy­si­schen Zugang zur lokalen Maschine erhält, eine Ver­bin­dung zum Server aufnehmen kann.

Nach der ge­gen­sei­ti­gen Au­then­ti­fi­zie­rung bauen die beiden Kom­mu­ni­ka­ti­ons­teil­neh­mer eine ver­schlüs­sel­te Ver­bin­dung auf. Dafür wird für die Sitzung ein Schlüssel erzeugt, der nach Be­en­di­gung der Sitzung wieder abläuft. Dieser ist nicht zu ver­wech­seln mit den Public-/Private-Key-Paaren, die nur zum Schlüs­sel­aus­tausch dienen. Der Schlüssel, der für die sym­me­tri­sche Ver­schlüs­se­lung ein­ge­setzt wird, ist nur für diese eine Sitzung gültig. Sowohl Client als auch Server verfügen über den gleichen Key und so können jegliche Nach­rich­ten, die aus­ge­tauscht werden, ver- und ent­schlüs­selt werden. Client und Server erstellen den Schlüssel gleich­zei­tig, aber un­ab­hän­gig von­ein­an­der. Beim so­ge­nann­ten Key-Exchange-Algorithm verwenden beide Parteien bestimmte öf­fent­li­che und geheime In­for­ma­tio­nen und erstellen so den Schlüssel.

Eine weitere Form der Ver­schlüs­se­lung findet in SSH durch Hashing statt. Ein Hash ist eine Form von Signatur der über­mit­tel­ten Daten. Mit einem Al­go­rith­mus wird aus den Daten ein Hash erzeugt, der einmalig ist. Sollten Daten ma­ni­pu­liert werden, ändert sich au­to­ma­tisch auch der Hashwert. Daran kann der Empfänger erkennen, ob Daten auf dem Weg durch Dritte geändert wurden. Die Hashwerte sind so gestaltet, dass sie auch nicht einfach simuliert werden können. Idea­ler­wei­se ist es niemals möglich, zwei un­ter­schied­li­che Über­tra­gun­gen mit dem gleichen Hash zu erzeugen. Das nennt man Kol­li­si­ons­si­cher­heit.

TCP-Ports sind Endpunkte, die Server und Clients öffnen, um die Kom­mu­ni­ka­ti­on zu er­mög­li­chen. Wie bei einem Hafen (auf Englisch „Port“) empfangen und senden die Kom­mu­ni­ka­ti­ons­part­ner hierüber die Da­ten­pa­ke­te. TCP verfügt über einen Adress­raum von 16 Bit und so stehen 65535 Ports zur Verfügung. Die Internet Assigned Numbers Authority (IANA) hat al­ler­dings einige Ports (genau 1024) für bestimmte An­wen­dun­gen fest vergeben: so auch den SSH-Port. Stan­dard­mä­ßig laufen alle SSH-Ver­bin­dun­gen über den Port 22.

Mit SSH ist zudem Port-For­war­ding möglich: Hierbei wird der SSH-Port eines Clients oder Servers von einem anderen Teil­neh­mer innerhalb eines lokalen Netzes benutzt, um eine ge­si­cher­te Ver­bin­dung über das Internet zu erstellen. Dafür kreieren die Teil­neh­mer einen Tunnel: Die Daten werden über den Port 22 empfangen und dann an den Client im lokalen Netzwerk wei­ter­ge­lei­tet.

Der SSH-Client ist in der Regel der eigene PC, mit dem man eine Ver­bin­dung zum Server aufbauen möchte. Um dies zu schaffen, kann oder muss (abhängig vom Be­triebs­sys­tem) man ge­son­der­te Software in­stal­lie­ren, die eine SSH-Ver­bin­dung aufbaut. Auch diese Programme nennt man in der Regel SSH-Client. Von der SSH Com­mu­ni­ca­ti­on Security selbst stammt das kos­ten­pflich­ti­ge Tectia SSH, das zu­sätz­lich eine Server-Software enthält. Darüber hinaus exis­tie­ren aber auch zahl­rei­che kos­ten­lo­se Al­ter­na­ti­ven, wie zum Beispiel die Open-Source-Software PuTTy für Windows und Linux oder lsh, das auf allen Be­triebs­sys­te­men funk­tio­niert, die auf Unix basieren.

Der SSH-Server ist das Ge­gen­stück zum Client. Auch hier wird der Begriff zugleich für die Software verwendet. Ein großer Teil der Software für Clients funk­tio­niert ebenfalls auf Servern. Darüber hinaus gibt es auch Software, die aus­schließ­lich für SSH-Server gestaltet ist. Es ist üblich, SSH auf Servern bereits beim Hoch­fah­ren zu starten. Das ga­ran­tiert, dass man jederzeit per SSH von außerhalb auf den Server zugreifen kann.

Es ist übrigens nicht notwendig, dass der SSH-Server tat­säch­lich ein Server im engeren Sinne ist, der in einem ent­fern­ten Re­chen­zen­trum steht. Nutzer können auch zu Hause einen SSH-Server auf dem eigenen PC in­stal­lie­ren, um so bei­spiels­wei­se von den Vorteilen des Port-For­war­ding zu pro­fi­tie­ren.