SSH

von Tatu Ylönen, Übersetzung und Anmerkungen von -mat- brandy

Viel ist schon über SSH geschrieben worden, so konnte man schon in der iX 4/96 [2] darüber lesen. Trotzdem will ich etwas über dieses Programmpaket und seine Möglichkeiten schreiben, da es einem als Systemverwalter eine große Arbeitserleichterung bringt und bei richtigem Einsatz von den Benutzern einfacher zu bedienen ist als die meisten anderen Programme. Vielfach haben die Benutzer es gar nicht bemerkt, daß sie jetzt slogin statt rlogin benutzen.

Als erstes will ich die Möglichkeiten von SSH aufzeigen, danach gehen wir der Frage Warum sollte man SSH einsetzen? nach. Es schließt sich eine Übersicht der verwendeten symmetrischen Verfahren an, um schließlich zur Benutzung von SSH zu kommen.


Möglichkeiten von SSH

SSH ist ein Programm um sich in einen anderen Rechnern über das Netzwerk einzuloggen, um Programme auf dem fernen Rechner auszuführen, und um Dateien von einer auf die andere Maschine zu bewegen. Es bietet starke Identifizierung und gesicherte Übertragung über unsichere Kanäle. Es ist als Ersatz für rlogin, rsh, rcp, telnet und rdist gedacht.

SSH bietet folgende Möglichkeiten:


Warum sollte man SSH einsetzen?

Zur Zeit wird fast alle Kommunikation in Computernetzen ohne Verschlüsselung betrieben. Die Konsequenz daraus ist, daß jeder, der Zugang in diesem Netzwerk hat die Kommunikation belauschen kann. Dies wird von Hackern [3], neugierigen Systemverwaltern, Angestellten, Kriminellen, Industriespionen und Regierungen getan. Einige Netzwerke strahlen genug elektromagnetische Wellen aus, um auch aus Entfernung ein Mitlesen zu ermöglichen.

Wenn Sie sich einloggen, geht als allererstes Ihr Paßwort im Klartext übers Netzwerk. Und damit kann jeder Lauscher Ihren Zugang benutzen um seine Absichten durchzusetzen. In vielen Fällen auf der ganzen Welt konnten Crackern [3] Programme auf Rechnern installieren und ausführen, um damit Paßwörter auszuspähen. Natürlich ohne Wissen und Zustimmung des Eigentümers dieser Maschinen. Programme für solche Lauschangriffe gibt es in vielen Varianten im Internet. So sind Juggernaut [4] und Sniffit [5] dafür berühmt und berüchtigt. Allerdings sind Lauschprogramme von versierten Programmieren innerhalb von wenigen Stunden selbst erstellt.

Darüberhinaus besteht die Möglichkeit Verbindungen im Netzwerk zu entführen. D.h. ein Eindringling kann sich in eine bestehende Verbindung einhängen und beide Richtungen der Verbindung verändern. Da die Überprüfung der Identität des Besitzers bereits abgeschlossen war, kann der Eindringling dies einfach tun. Stellen Sie sich vor, Sie sehen gerade wie jemand Ihre Festplatten löscht und Sie können außer Zuschauen nichts dagegen tun. Selbst wenn Sie sich vorher mit einem Einmalpaßwort angemeldet haben, nutzt es Ihnen diesem Fall wenig. Die Konsequenz daraus ist, daß alle Verfahren, die alleinig auf der Identifizierung des Benutzers am Anfang beruhen, fehlschlagen. Und mittels routing spoofing ist es möglich fast jede Verbindung zu einer Stelle zu bringen, wo sie angreifbar wird.

Verschlüsselung und kryptographische Identifizierung und Integritätssicherung sind in sicheren Netzwerken und Computern von Nöten. SSH benutzt starke kryptographische Algorithmen um diese Ziele zu erreichen.

Dabei wurde nicht die Einfachheit in der Benutzung übersehen, denn diese ist mehr als wichtig für die Benutzung der Software durch den Alltagsbenutzer. SSH versucht einfacher in der Bedienung zu sein, als die unsicheren Programme, die es ersetzt.

SSH hat inzwischen sehr große Akzeptanz gefunden und wird weltweit eingesetzt. Das Programm ist für fast alle UNIX-Plattformen und sogar für Win95, WinNT und Mac vorhanden. Frei sind hier bei bis jetzt nur die UNIX-Plattformen.


Übersicht über die verwendeten symmetrischen Verschlüsselungsverfahren


Benutzung von SSH

Übersicht der Programme
sshd Serverprogramm, welches auf dem Serverrechner läuft. Es wartet auf Verbindungen von den Klientrechnern und wenn eine Verbindung von einem Klient gestartet wird übernimmt es die Identifizierung und lässt den Klienten danach auf den Serverrechner.
ssh Dies ist das Klientprogramm. Es kann dazu benutzt werden um sich auf dem Server einzuloggen, oder um Programme auf dem Server auszuführen. slogin ist ein anderer Name für ssh.
scp Damit kann man gesichert Dateien von einem Rechner auf den anderen kopieren.
ssh-keygen Wird benutzt um RSA-Schlüssel zu erzeugen. Sowohl Benutzer- als auch Rechner-RSA-Identifikationsschlüssel werden damit erzeugt.
ssh-agent Identifikationsagent, wird zum Halten der RSA-Schlüssel im Speicher benutzt.
ssh-add Fügt weitere RSA-Schlüssel in den Agenten ein.
make-ssh-known-hosts Erzeugt die Datei /etc/ssh_known_hosts

SSH ist das Programm, das der Benutzer normalerweise benutzt. Es wird mit ssh zielrechner oder ssh zielrechner kommando aufgerufen. Die erste Variante öffnet eine Shell auf dem Zielrechner, die zweite Variante führt das Kommando auf dem Zielrechner aus.

Wenn ssh gestartet wird, baut es eine Verbindung zum Serverprogramm (sshd) auf dem Zielrechner auf und überprüft, ob dies wirklich der Rechner ist, mit dem es Kontakt aufnehmen soll. Es tauscht die Sitzungsschlüssel aus, in einer Art uns Weise, die es außenstehenden Lauschern unmöglich macht, diese Schlüssel zu erhalten. Danach versucht es eine Identifikation mit .rhosts und /etc/hosts.equiv, RSA-Identifizierung oder normaler Paßwort-Identifizierung. Der Server teilt dem Klient dann gewöhnlich ein Pseudoterminal zu und startet eine interaktive Shell, oder führt das Kommando aus.

Die TERM Umgebungsvariable wird vom Klient auf den Server übertragen, genauso wie die Terminalmodi. Wenn die DISPLAY-Variable auf der Klientseite gesetzt ist, erzeugt der Server einen Dummy-X-Server und setzt die DISPLAY-Variable entsprechend. Jede Verbindung zu diesem Dummy-X-Server wird durch einen sicheren Kanal getunnelt und auf der Klientseite an den echten X-Server weitergeleitet. Eine beliebige Anzahl von X-Programmen kann auf dem Server während der Sitzung gestartet werden, wobei der Benutzer nichts beachten muß. Wenn der Benutzer die DISPLAY-Variable von Hand setzt, wird die sichere Übertragung allerdings umgangen. Diese Tunnelung kann auch mit dem Parameter -x verhindert werden.

Ein beliebiger IP-Port kann über einen gesicherten Kanal getunnelt werden. Das Programm erzeugt auf der einen Seite den gewünschten Port und immer wenn eine Verbindung zu diesem Port gemacht wird, geht alle Kommunikation durch den verschlüsselten Kanal. Eine Verbindung wird dabei von dem gewünschten Port zum dem Paar zielrechner:zielport hergestellt. Diese Tunnelung muß explizit aufgerufen werden. Normale Benutzer können keine Ports < 1024 tunneln. Es ist möglich in den Konfigurationsdateien eines Benutzers eine automatische Tunnelung anzupassen, damit können z.B. electronic-banking Verbindungen gesichert werden.

Wenn auf der Klientseite ein ssh-agent läuft, werden automatisch Verbindungen zu diesem an die Serverseite weitergeleitet.


X11-Verbindungen und wie man sie tunnelt

Das tunneln von X11-Verbindungen hat zwei Gründe: es macht es den Benutzern einfach, da sie keine DISPLAY-Variable mehr setzten müssen und es bietet verschlüsselte X11-Verbindungen. Man kann sich keinen einfacheren Weg vorstellen X11-Verbindungen zu verschlüsseln. Das Modifizieren des X-Serverprogramms und der entsprechenden Klienten braucht immer angepaßte Installationen auf jeder einzelnen Maschine, jedes Programm eines anderen Herstellers müsste angepaßt werden. Und die Verschlüsselung auf IP-Ebene lässt noch einige Zeit auf sich warten. Also bleibt am Ende ein gefaketer X-Server auf der gleichen Maschine, auf der auch die Klientenprogramme laufen und eine Weiterleitung der Verbindungen an der echten X-Server über einen verschlüsselten Kanal.

X11-tunneling funktioniert wie folgt: Der Klient extrahiert die Xauthority Informationen für den Server. Er generiert dann eine zufällige Identifikation und sendet diese an den Server. Der Server erstellt eine X11-Displaynummer und speichert die (gefakete) Xauthority für dieses Display. Wann auch immer eine X11-Verbindung gestartet wird, leitet der X-Server dies Verbindung über den verschlüsselten Kanal an den Klienten weiter. Der Klient liest das erste Paket des X11-Protokolls und ersetzt die gefakete Xauthority durch die echte (natürlich nur, wenn die gefakete mit seiner Version übereinstimmt) und leitet das geänderte Paket an den echten X-Server weiter.

Wenn das Display über keine Xauthority verfügt, erzeugt der Server einen UNIX domain socket in /tmp/.X11-unix, und benutzt diesen Socket als Display. Dabei wird keine Identifikationsinformation weitergeleitet. Alle X11-Verbindung werden wiederum durch einen verschlüsselten Kanal getunnelt. Aus der Sicht des X-Servers kommen alle Verbindungen vom Klientrechner, und der Server muß Verbindungen vom lokalen Rechner zulassen. Die Benutzung von Identifikationsdaten ist immer ratsam, da ihr Fehlen unsicher ist. Bei xdm werden diese Daten automatisch immer erzeugt.

Man sollte vorsichtig sein beim Starten von xin und xstart oder ähnlichen Skripten, die die DISPLAY-Variable explizit selbst setzen, um auf dem Zielrechner X-basierte Programme zu starten, da dann die Verbindungen nicht verschlüsselt werden. Um eine Shell auf dem Zielrechner zu starten, sollte man folgendes aufrufen: xterm -e ssh zielrechner &. Der bessere Weg eine X-Anwendung auf dem Zielrechner zu starten ist: ssh -n zielrechner emacs & . Wenn Paßwörter oder Paßsätze auf dem Zielrechner eingegeben werden müssen, ist ssh -f zielrechner emacs hilfreich.


RSA-Identifikation

RSA-Identifizierung basiert auf Public key Kryptographie. Es gibt zwei Schlüssel gibt, einen zur Verschlüsselung und einen zur Entschlüsselung. Es ist nicht möglich in menschlichen Zeitdimensionen den Entschlüsselungsschlüssel aus dem Verschlüsselungsschlüssel zu berechnen. Der Verschlüsselungsschlüssel heißt public key, weil er jedem mitgegeben werden kann und nicht geheim ist. Der Entschlüsselungsschlüssel hingegen ist geheim, und wird deshalb privat key genannt.

RSA-Identifikation basiert auf dieser Unmöglichkeit den privat key aus dem public key zu berechnen. Der public key ist auf dem Serverrechner in Verzeichnis des Benutzers in der Datei $HOME/.ssh/authorized_keys gespeichert. Der privat key ist einzig und allein auf der Klientmaschine des Benutzers gespeichert. Wenn der Benutzer nun einen Sitzung mit dem Server aufnehmen will, teilt der Klient dem Server mit, welchen public key der Benutzer zur Identifikation benutzen will. Der Server überprüft, ob er diesen public key zulässt. Tut er es, generiert er eine 256 Bit Zufallszahl, verschlüsselt diese mit dem public key und schickt dieses Ergebnis an den Klienten. Der Klient entschlüsselt die Zahl mit seinem privat key, berechnet eine 128 Bit MD5-Prüfsumme aus der Zahl und schickt diese Prüfsumme an den Server. Es wird nur die Prüfsumme an den Server geschickt, um eine chosen-plaintext-Attacke gegen RSA zu unterbinden. Der Server berechnet aus den Originaldaten eine Prüfsumme und vergleicht diese mit den erhaltenen Daten. Theoretisch gesehen hat der Klient nach gewiesen, daß er wahrscheinlich den richtigen Schlüssel kennt, in der Praxis gibt es dafür keine Zweifel.

Der RSA privat key kann mit einem Paßsatz geschützt werden. Der Paßsatz kann eine beliebige Eingabefolge sein, aus ihr wird mit MD5 ein Hashwert erzeugt, der den Schlüssel für 3DES-Verfahren liefert, mit dem die Datei verschlüsselt wird. Mit einem Paßsatz benötigt die Identifikation die Datei mit dem privat key und die korrekte Eingabe des Paßsatzes. Ohne einen Paßsatz beruht die Identifikation allein auf dem Besitz der Datei mit dem privat key.

RSA-Identifikation ist die stärkste Identifikationsmethode, die von SSH unterstützt wird. Es beruht nicht allein auf der Sicherheit der Kabel, der Verbindungsrechner, den Nameservern, oder der Klientmaschine. Das einzige was zählt, ist der Zugriff auf den privat key.

All dies beruht natürlich auf der Sicherheit des RSA-Algorithmus. RSA ist schon seit 1978 bekannt und verbreitet und bis jetzt wurde noch keine effektive Methode gefunden um ihn zu brechen, bei richtiger Anwendung des Algorithmus. Mit Sorgfalt wurden die bekannten Schwachstellen vermieden. Die Brechung von RSA wird der Schwierigkeit der Faktorisierung gleichgestellt. Faktorisierung ist ein bekanntes schwieriges mathematisches Problem, zu dem es viele Untersuchungen gibt. Bis jetzt wurden keine effektiven Methoden Zahlen mit mehr als 512 Bit zu brechen, entwickelt. Da die Rechenleistung und die Methoden immer besser werden ist aber 512 Bit als nicht sicher anzusehen. Da die Faktorisierung allerdings exponential ist, kann man 768, 1024 und 2048 Bit in der näheren Zukunft als sicher ansehen.


RHOSTS Identifikation

Konventionelle, auf .rhosts und hosts.equiv basierende Identifikationsmechanismen sind fundemental unsicher in Hinsicht auf IP-, DNS- und Routing-Spoofing-Attacken. Zusätzlich beruhen diese Methoden auf der Integrität der Klientmaschine. Diese Schwächen waren tolerierbar, und sind schon lange bekannt und mißbraucht.

SSH verbessert diese Art von Identifikation, da sie für Benutzer im Gebrauch sehr einfach sind und einen sehr einfachen Wechsel von rsh und rlogin erlauben. SSH erlaubt diese Arten von Identifikation, erweitert sie aber um die RSA-Identifikation des Klientenrechners.

Der Server hat eine Liste von Rechner public keys in der Datei /etc/ssh_known_hosts und zusätzlich hat jeder Benutzer in eine Liste von Rechner public keys in der Datei $HOME/.ssh/known_hosts. Beim Verbindungsaufbau findet SSH über den Nameservice den kanonischen Namen des Klientrechners heraus und sucht den dazu gehörigen public key in der Liste der bekannten Rechner. Danach fordert es den Klientenrechner auf nachzuweisen, daß er im Besitz des dazugehörigen privat key ist. Das verhindert IP- und Routing-Spoofing-Attacken, so lange der privat key des Klientrechners nicht gestohlen wurde. Diese Methode ist aber, immer noch in einem gewissem Maße anfällig für DNS-Spoofing und beruht auf der Integrität der Klientmaschine. Das hält Aussenstehende von Angriffe ab, allerdings keine wirklichen Könner. Wenn es um bestmögliche Sicherheit geht, sollte nur RSA-Identifikation benutzt werden.

Es besteht die Möglichkeit die konventionelle .rhosts und hosts.equiv-Identifikation ohne Rechneridentifikation in SSH zu aktivieren. Dazu muß bei der Installation dies mit der Option --with-rhosts angegeben werden, im Normalfall ist es nicht aktiviert.

Diese Schwachstellen sind in rsh und rlogin, wie auch in allen anderen r-Kommandos vorhanden. Um die Sicherheit einer Maschine zu gewährleisten, sollten diese Programme abgeschaltet werden. Dazu entfernt man die entsprechenden Zeilen in der /etc/inetd.conf.


Infos

  1. SSH README Übersetzung des SSH README, von -mat- brandy.
  2. iX 4/96 Seite 172ff. Vertrauen ist gut von Ralf Ackermann und Holger Trapp.
  3. Jargon Files http://www.klammeraffe.org/jargon/
  4. Juggernaut ftp://ftp.klammeraffe.org/pub/secur/juggernaut-1.1.tgz
  5. Sniffit ftp://ftp.klammeraffe.org/pub/secur/sniffit.0.3.5.tar.gz
  6. SSH README.CIPHERS Übersetzung des SSH README.CIPHERS, von -mat- brandy.
  7. Webserver zu SSH http://www.cs.hut.fi/ssh/
  8. FTP zu SSH ftp://ftp.cs.hut.fi/pub/ssh/