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:

• Starke Identifizierung. Es schließt einige Sicherheitslöcher (z.B.: IP-, Routing-, und DNS-Spoofing). Neue Identifizierungsmethoden: .rhosts zusammen mit RSA-basierter Rechner-Identifizierung und reiner RSA-Identifzierung.
  
  
• Verbesserte Privatsphäre. Jede Kommunikation ist automatisch verschlüsselt, dies erfolgt transparent, dh. der Benutzer merkt nichts von der Anwendung der Verschlüsselung. RSA wird benutzt um den Schlüsselaustausch durchzuführen und ein symmetrisches Verfahren (normalerweise BLOWFISH, IDEA, DES oder Triple-DES) dient für die Verbindung. Die Verschlüsselung wird vor der Identifizierung gestartet, dadurch wird niemals ein Paßwort oder andere Information im Klartext übertragen. Die Verschlüsselung schützt desweiteren vor gespooften Paketen und dem Hijacking von Verbindungen.
  
  
• Sichere X11 Verbindungen. SSH setzt automatisch die DISPLAY-Variable auf der Servermaschine und reicht jede X11-Verbindung über einen gesicherten Kanal weiter. Eine geänderte Xauthority-Information wird automatisch erzeugt und an den Server weitergeleitet, der lokale Klient untersucht alle eingehenden X11-Verbindungen und ersetzt die veränderte Information mit den echten Daten, dabei werden dem Server niemals diese echten Informationen mitgeteilt.
  
  
• Jeder TCP/IP Port kann durch einen verschlüsselten Kanal in beiden Richtungen getunnelt werden. (z.B.: für elektronisches Banking)
  
  
• Es ist keine erneute Schulung für Anwender notwendig, da alles automatisch erfolgt, und alte .rhosts werden durch starke Überprüfung aufgewertet, wenn der Verwalter die eindeutigen Hostkeys richtig installiert.
  
  
• SSH verläßt sich niemals auf Informationen aus dem Netz. Minimales Vertrauen auf die Informationen über die Gegenstelle im Netz. Reine RSA Überprüfung vertraut auf nichts anderes als auf den Hostkey.
  
  
• Das Klientprogramm erkennt den Server mittels RSA-Identifikation zu Beginn jeder Verbindung, damit werden trojanische Angriffe durch Routing- oder DNS-Spoofing verhindert. Desweiteren werden sogenannte Man-in-the-middle Angriffe abgewehrt. Der Server wiederum RSA-identifiziert den Klient bevor er .rhosts oder /etc/hosts.equiv akzeptiert, was vor DNS-, Routing- und IP-Spoofing schützt.
  
  
• Der Schlüssel, der den Rechner eindeutig identifiziert (Hostkey) kann zentral von der Administration, automatisch bei der ersten Verbindung zu diesem Rechner oder vom jedem Benutzer per Hand verteilt werden. Bei der automatischen Verteilung wird der Benutzer gefragt, ob er diesen Hostkey speichern will, danach wird er bei späteren Verbindungen benutzt. Die Zentral- und die pro Benutzer-Liste werden beide benutzt und ergänzen sich gegenseitig. Ein Hostkey kann zentral oder automatisch bei einer Installation von SSH erzeugt werden. Die Schlüssellänge ist normalerweise 1024 Bit.
  
  
• Jeder Benutzer kann sich einen oder mehrere Benutzeridentifikationsschlüssel erzeugen. Die Benutzer haben jeweils eine Datei, die eine Liste von RSA-public keys enthält. Der Nachweis des Besitzes des dazu korrespondierenden RSA-secret keys gilt als Nachweis der Identität. Benutzeridentifikationsschlüssel haben normalerweise eine Länge von 1024 Bit.
  
  
• Das Serverprogramm besitzt seinen eigenen RSA-Schlüssel, der alle Stunde automatisch erneuert wird. Dieser Schlüssel wird nur im Speicher gehalten und niemals im Dateisystem abgelegt. Die Sitzungsschlüssel werden jeweils mit RSA-Schlüssel des Serverprogramms und dem RSA-Schlüssel des Rechners verschlüsselt. Dies verhindert, daß ein Mitschnitt einer Verbindung dekodiert werden kann und länger als das Erneuerungsintervall lesbar bleibt. Selbst der Server kann nach einer Stunde diese Mitschnitte nicht mehr entschlüsseln. Das Erneuerungsintervall ist frei einstellbar und der Serverschlüssel hat normalerweise eine Länge von 768 Bit.
  
  
• Ein auf dem Laptop oder dem lokalen Rechner laufender Identifikationsagent (authentification agent), kann dazu benutzt werden die Identifikationsschlüssel des Benutzers im Speicher zu halten. SSH leitet automatisch Anfragen an diesen Agenten über beliebige Verbindungen weiter. Es besteht daher nicht die Notwendigkeit auf jeder Maschine im Netzwerk diese Schlüssel zu hinterlegen, abgesehen von der lokalen Maschine des Benutzers. Das Protokoll, welches bei der Identifikation benutzt wird, legt niemals die Schlüssel dar, sondern weist nur nach, daß der Benutzer im Besitz dieser Schlüssel ist. So kann der Agent in einer speziellen Version alle Identifikationsberechnungen auch von einer Smartcard erledigen lassen.
  
  
• SSH läßt sich auch ohne root-Rechte installieren, hat dann allerdings einige Einschränkungen in der Benutzung. So kann man z.B. keine Verbindungen unter Port 1024 tunneln.
  
  
• Der Klient kann über systemweite und benutzereigene Konfigurationsdateien angepasst werden.
  
  
• SSH fällt automatisch auf rsh (nach Ausgabe einer Warnung!) zurück, wenn auf dem Zielrechner kein sshd läuft.
  
  
• Desweiteren können Verbindungen auch komprimiert (gzip) werden, was bei langsamen und schmalen Leitungen eine Beschleunigung bringen kann.
  
  
• SSH ist ein kompletter Ersatz für rlogin, rsh und rcp. Desweitern ersetzt es auch telnet.

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

• BLOWFISH
  Der von Bruce Schneier entwickelte Blockverschlüsseler ist dafür gebaut worden eine schnelle und freie Alternative zu bestehenden Verschlüsslungsalgorithmen zu sein. Er ist nicht patentiert und lizenzfrei. SSH benutzt die 128-bit Variante von Blowfish, der Algorithmus erlaubt alles zwischen 32 und 448 Bit. Die Leistung auf einer Referenzmaschine ist 88% gegenüber keiner Verschlüsselung.
  Bei der Übersetzung von SSH kann mit --without-blowfish Blowfish abgeschaltet werden, es ist im Normalfall aktiv.
  
  
• ARCFOUR
  Arcfour ist ein Verschlüsseler für Datenströme, der eine variable Schlüssellänge zulässt. SSH benutzt eine Länge von 128 Bit. Arfour ist mit dem RC4-Algorithmus von RSA Data Security kompatibel und recht schnell.
  Da es in der Version 1.x von SSH Probleme mit der Implementierung von Arcfour gibt, ist er normalerweise inaktiv. Arcfour kann bei der Installation mit --with-arcfour aktiviert werden, was allerdings Sicherheitsprobleme aufwirft, wenn ein Angreifer aktive Netzwerklevel-Angriffe durchführen kann. Diese Probleme werden in den Versionen ab 2.x beseitigt sein.
  Die Leistung ist 91% gegenüber keiner Verschlüsselung.
  SSH nimmt normalerweise Blowfish, wenn Arcfour gewünscht wird, aber nicht aktiv ist. Dadurch können alte Konfigurationen weiterlaufen. Es wird eine Warnung ausgegeben, wenn dies passieren sollte.
  
  
• IDEA
  ist ein 128-bit Blockverschlüsseler. Schneller als 3DES, aber langsamer als Arcfour und Blowfish. Der IDEA-Algorithmus ist in vielen Ländern patentiert, und der Patenthalter verbietet die kommerzielle Nutzung. In seinen Augen ist schon die Benutzung zwischen zwei Stellen, die nicht in der selben Firma sind, kommerziell.
  Leistung ist 65% gegenüber keiner Verschlüsselung.
  Bei der Übersetzung von SSH kann mit --without-idea IDEA abgeschaltet werden, es ist im Normalfall aktiv.
  
  
• DES (Data Encryption Standard)
  ist ein 56-bit Blockverschlüsseler. Ungefähr dreimal schneller als 3DES, aber langsamer als Arcfour und Blowfish. Die 56-bit Schlüssellänge ist zu kurz für echte Sicherheit, und man sollte sie nur aktivieren, wenn man unbedingt muß, z.B. durch Firmenpolitik.
  Die Leistung ist 71% gegenüber keiner Verschlüsselung.
  Bei der Übersetzung von SSH kann mit --with-des DES angeschaltet werden, es ist im Normalfall inaktiv.
  
  
• 3DES
  Dreierschlüssel Triple-DES, effektive Schlüssellänge um die 112 Bit im inneren CBC-Modus. Dies ist die Standardverschlüsselung von SSH, wenn z. B. keine andere greift.
  Die RSA-privat keys sind mit 3DES verschlüsselt. In älteren Versionen von SSH wurde dafür IDEA verwendet.
  Leistung ist 45% gegenüber keiner Verschlüsselung.
  Diese Verschlüsselung kann nicht abgeschaltet werden, da es der Standard von SSH ist.
  
  
• TSS
  Timo Rinne's eigener Verschlüsseler. Wird nicht empfohlen, da er nur zum Experimentieren dient und nicht unterstützt wird.
  
  
• NONE
  Keine Verschlüsselung!!! Diese Methode ist nur für den Vergleichtest implementiert worden und im Normalfall inaktiv. Sie ist für hijacking und sniffing anfällig. Server lassen diese Methode nicht zu, außer zu Testzwecken.
  Leistung 100%, was natürlich davon abhängig ist, ob Komprimierung gewählt wurde und von der Prozessorleistung usw. Diese Methode gilt als Referenz für die anderen Methoden.
  Bei der Übersetzung von SSH kann mit --with-none keine Verschlüsselung (NONE) angeschaltet werden, es ist im Normalfall inaktiv.
  
  

Benutzung von SSH

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/