Secure Shell (SSH) für Benutzer

Ernst Bötsch

1998-09-09

$Id: ssh.sed.html,v 1.4 1998/09/09 07:21:53 Boetsch Exp $ /afs/lrz-muenchen.de/info/www/user-sources/services/security/RCS/ssh.sed.html,v $ Verschlüsselung

Einführung

Die Kommandos des SW-Paketes `Secure Shell' (SSH) ermöglichen einen (nahezu) transparenten Ersatz der Kommunikations-Kommandos telnet und rsh / rlogin / rcp (Berkeley Remote-Dienste bzw. r-Kommandos). Dabei werden die gravierenden Sicherheits-Probleme dieser Kommandos beseitigt: Alle Daten werden verschlüsselt (besonders wichtig bei Paßwörtern!), und es findet eine strenge Authentifizierung beider beteiligten Parteien statt (d.h. die Identität der beiden Parteien wird auf sichere Art überprüft).

Dieses Dokument wendet sich v.a. an die UNIX-Benutzer(innen) der SSH-Kommandos, eine Erweiterung um die Microsoft-Welt ist geplant; ein ergänzendes Dokument für System-Administrator(inn)en ist ebenfalls in Vorbereitung.

Für erste Schritte mit der SSH reicht der Abschnitt `Kurzanleitung zur sofortigen Nutzung von SSH' aus.

Am LRZ ist SSH zur Zeit auf den Sun's, der T90 und der VPP installiert. Die restlichen Plattformen sollen demnächst folgen.

Motivation

Probleme bei den Berkeley Remote-Diensten

Bei der Benutzung von Remote-Rechnern (d.h. entfernten Rechnern) haben sich in der Vergangenheit folgende Kommandos weitgehend durchgesetzt:

telnet, rlogin:
Interaktive Dialog-Sitzungen auf einem Remote-Rechner
rsh:
Ausführung von Kommandos auf einem Remote-Rechner (interaktiv oder im Batch-Betrieb)
rcp:
Kopieren von Dateien zwischen Rechnern

Diese Kommandos weisen jedoch gravierende Sicherheits-Mängel auf, die in Anbetracht des boomenden Internet keinesfalls mehr ignoriert werden dürfen:

Beim Verbindungs-Aufbau erforderliche Paßwörter werden im Klartext übertragen!
Damit sind diese Paßwörter natürlich eine leichte Beute für jeden Hacker, der den Netz-Verkehr abhört. Aber es kommt noch schlimmer: Gleichzeitig wird nämlich auch die dazugehörige Kennung übertragen (natürlich ebenfalls im Klartext).
Eine einfache Schutzmöglichkeit wäre die Verwendung von `Einmal-Paßwörtern'. Dies ist aber so aufwendig und/oder unbequem, daß derartige Systeme nur selten installiert werden.
Damit nicht genug: Während einer bestehenden Verbindung werden alle Daten ebenfalls im Klartext übertragen!
Dies ist noch gefährlicher als der vorhergende Punkt, da während einer Sitzung oft Paßwörter und/oder (streng) vertrauliche Daten übertragen werden. Außerdem hilft gegen das Abhören einer bestehenden Verbindung auch kein Einmal-Paßwort.
Beim Verbindungs-Aufbau findet keine Authentifizierung (d.h. Überprüfung der Identität) der beteiligten Rechner statt.
Beide Seiten können sich also nicht sicher sein, daß der Kommunikations-Partner nicht ein Angreifer ist, der eine falsche Identität vorgibt.
Mit geeigneter SW können Angreifer sich in bestehende Verbindungen `einklinken' und dann den Daten-Strom verändern!
Hacker nutzen dies i.a. dazu, um sich Zugang zur Kennung auf dem Remote-Rechner zu verschaffen!

Eigenschaften der SSH

Zur Lösung der Sicherheits-Probleme bei telnet und den r-Kommandos entwickelte Tatu Ylonen das SW-Paket `Secure Shell' (SSH), das diese Kommandos auf einfache Art ersetzen kann. Bei der Entwicklung von SSH wurde besonderer Wert auf folgende Punkte gelegt:

Die Bedienung ist sehr einfach, damit Benutzer(innen) nicht von der Verwendung von SSH abgeschreckt werden.
Darüberhinaus besitzt SSH einige Funktionen, die die Nutzung im Vergleich zu den r-Kommandos sogar erleichtert (z.B. automatische X-Window-Authorisierung und automatisches Setzen der $DISPLAY-Environment-Variablen).
Bei den wichtigsten UNIX-Varianten stehen die Optionen der r-Kommandos auch bei den SSH-Kommandos zur Verfügung.
Die r-Kommandos können in diesen Fällen sogar einfach durch die entsprechenden SSH-Kommandos ausgetauscht werden.
SSH mißtraut prinzipiell dem potentiell unsicheren Netz, dem Domain-Name-Service (DNS) etc.
SSH ermöglicht eine strenge Authentifizierung beider Kommunikations-Partner; i.a. wird dies vom System-Administrator auch so konfiguriert.
SSH garantiert Vertraulichkeit durch eine strenge Verschlüsselung aller Daten (speziell der Paßwörter).
Nicht nur Dialog-Sitzungen sondern auch beliebige TCP/IP-Ports (besonders X-Window) können durch einen sicheren SSH-Kanal geleitet werden.
Falls auf dem Remote-Rechner kein SSH-Server läuft, wird automatisch auf die r-Kommandos zurückgeriffen.
Man muß sich also nicht merken, auf welchen Remote-Rechnern ein SSH-Server läuft, und dann in Abhängigkeit davon entweder SSH- oder r-Kommandos verwenden; man kann sich somit auf die SSH-Kommandos beschränken.
Optional wird der Datenverkehr zusätzlich komprimiert, was besonders bei schlechten Kommunikations-Verbindungen nützlich ist.
Bei einer Anbindung über Modem bringt dies jedoch nichts, da Modems i.a. selbst komprimieren.
In einer Umgebung wie dem LRZ ist die volle Unterstützung von Kerberos-IV, AFS und DCE besonders wichtig.
Im Einzelfall kann der interessierte (normale) Benutzer sogar selbst einen SSH-Server starten; man ist dadurch nicht auf die Kooperation von Administratoren angewiesen.
In diesem Fall stehen einem jedoch nicht alle, aber die wichtigsten Funktionen von SSH zur Verfügung.
SSH kann sowohl bei der Übersetzung als auch zur Laufzeit in weitem Rahmen konfiguriert und damit an die lokalen Anforderungen angepaßt werden.

Kurzanleitung zur sofortigen Nutzung von SSH

Will man sich nicht näher in SSH einarbeiten, um alle Funktionen des SW-Pakets voll ausnützen zu können, reicht als 1-malige Vorbereitung die Anlage des Directories $HOME/.ssh aus:

mkdir $HOME/.ssh chmod go= $HOME/.ssh

In diesem Directory werden alle Benutzer-spezifischen Dateien von SSH aufbewahrt; das Directory sollte deshalb nur für den Besitzer der Kennung zugänglich sein (d.h. Mode `go=' bzw. `0700'). Bei Verwendeung von AFS darf man die entsprechenden AFS-Rechte keinesfalls vergessen (system:anyuser und system:authuser dürfen z.B. höchstens das Lookup-Recht `l' haben).

Danach können sofort SSH-Kommandos verwendet werden:

Einloggen auf einem Remote-Rechner für eine interaktive Dialog-Sitzung (Ersatz für telnet, rlogin und ein rsh ohne Kommando-Argument):

ssh [SSH_OPTIONS] HOST

Als Äquivalent zum r-Kommando rlogin ist der ssh-Alias slogin vorhanden, der ebenfalls zum Einloggen verwendet werden kann:

slogin [SSH_OPTIONS] HOST
Ausführung von Kommandos auf einem Remote-Rechner (interaktiv oder im Batch-Betrieb; Ersatz für rsh):

ssh [SSH_OPTIONS] HOST COMMAND [COMMAND_ARGUMENTS]
Kopieren von Dateien zwischen Rechnern (Ersatz für rcp):

scp [SCP_OPTIONS] [[LOGIN@]HOST:]FILE [...] [[LOGIN@]HOST:]FILE
xterm mit einer Shell auf einem Remote-Rechner:

xterm [XTERM_OPTIONS] -e ssh [SSH_OPTIONS] HOST &
Andere X-Window-Anwendungen:
- Falls kein Paßwort eingegeben werden muß:
  
  ssh -n [SSH_OPTIONS] HOST X_WINDOW_APPLICATION [ARGUMENTS] &
- Falls ein Paßwort erforderlich ist:
  
  ssh -f [SSH_OPTIONS] HOST X_WINDOW_APPLICATION [ARGUMENTS] &
  
  (Der Unterschied zum vorhergehenden Fall besteht in der Verwendung der ssh-Option `-f' anstelle von `-n'.)
Wie diese Beispiele zeigen, regelt SSH automatisch die Verwendung von X-Window. Man muß also auf dem Remote-Rechner weder eine X-Window-Authorisierung (xauth-Kommando) noch die Environment-Variable $DISPLAY setzen.

Dabei umfaßt SSH_OPTIONS bzw. SCP_OPTIONS i.a. auch die Optionen, die man von den r-Kommandos her gewohnt ist (z.B. `-l LOGIN' bei ssh, wenn man auf dem Remote-Rechner unter einer anderen Kennung LOGIN arbeitet).

Bereits durch diese einfache Nutzung der SSH werden alle Daten einer Verbindung komplett verschlüsselt. Damit sind schon in dieser einfachen Nutzungsart der SSH die Sicherheits-Probleme der r-Kommandos behoben, d.h. Paßwörter und Daten werden nicht mehr im Klartext übertragen und es findet eine strenge Authentifizierung statt.

Man sollte und kann immer die SSH-Kommandos verwenden, da SSH automatisch auf die r-Kommandos zurückgreift, falls auf dem Remote-Rechner kein SSH-Server läuft.

Alles weitere (siehe dazu den Rest dieses Dokuments oder entsprechende man-Pages) ist nur dann erforderlich, wenn man die komplette Funktionalität der SSH ausschöpfen will. Diese zusätzlichen Funktionen kann man jedoch mit den Stichwörtern `Spezialfälle' und `Bequemlichkeit' beschreiben; man kann i.a. dadurch keine wesentliche zusätzliche Sicherheit gewinnen.

SSH-Interna

Für das Verständnis diverser SSH-Funktionen ist ein kurzer Einblick in einige Aspekte des inneren Aufbaus von SSH hilfreich.

Interner Ablauf beim Verbindungsaufbau

Vor der Bearbeitung von Verbindungs-Wünschen durch SSH-Clients sind u.a. folgende Schritte erforderlich:

Auf dem Server-Rechner wird vom Administrator einmalig bzw. in größeren Zeitabständen (mindestens mehrere Monate) ein Host-Key-Paar (RSA) generiert. Für diesen Verwendungszweck sind die Keys i.a. 1024 Bit lang.
Der laufende Server-Prozeß erzeugt periodisch (i.a. jede Stunde) zusätzlich ein Server-Key-Paar (RSA), das nur im Memory gehalten und nach Ablauf der Zeitspanne gelöscht wird. Diese Keys sind i.a. 768 Bit lang.

Bei jeder neuen Verbindung laufen am Anfang folgende Teilschritte ab:

Der SSH-Client ssh (scp setzt intern ebenfalls auf ssh auf) wendet sich an den SSH-Server auf einem Remote-Rechner.
Der SSH-Server schickt sowohl seinen Host- als auch seinen Server-Public-Key (siehe oben) an den Client.
Der SSH-Client kann nun überprüfen, ob er den Server kennt, indem er in Tabellen von bekannten Public-Keys nach dem gerade erhaltenen Host-Public-Key sucht.
Ist dieser Key noch nicht bekannt, teilt der Client dies dem Benutzer mit und fragt nach, ob die Verbindung trotz der Unsicherheit (die Identität des Servers kann ja nicht überprüft werden) aufgebaut werden soll.
Bei einer positiven Antwort trägt der Client den Server-Public-Key außerdem in eine individuelle Liste des Benutzers ein; bei der nächsten Verbindung ist dann der Remote-Rechner schon bekannt und der Client muß nicht mehr nachfragen.
Bei einer negativen Antwort des Benutzers hört der Client an dieser Stelle wie gewünscht auf.
Der Client schickt dem Server eine 256 Bit lange Zufallszahl, die sowohl mit dem Host- als auch mit dem Server-Public-Key des Remote-Rechners verschlüsselt wurde.
Ab sofort werden alle Daten der Verbindung verschlüsselt.
Dabei dient die im vorherigen Schritt erzeugte Zufallszahl (bzw. je nach Algorithmus auch nur Teile von ihr) als Sitzungs-Key. Dieser Sitzungs-Key ist bei jeder Verbindung anders, da er jedesmal individuell und zufällig erzeugt wird.
Der Schutz der Verbindung ergibt sich durch folgende Punkte:
- Selbst wenn der Remote-Rechner eine falsche Identität vorgespiegelt hat, kann dem Benutzer nichts passieren: Da die Zufallszahl mit dem Host-Public-Key des richtigen Rechners verschlüsselt wurde, kann auch nur der richtige Rechner diese Zahl wieder entschlüsseln. Ein falscher Rechner kann dies nicht und würde deshalb für den Rest der Verbindung nur Daten-Müll erhalten, der für den Angreifer vollkommen wertlos ist.
- Die zusätzliche Verschlüsselung der Zufallszahl mit dem Server-Public-Key hat folgende Funktion: Selbst wenn ein Hacker in den Remote-Rechner eindringt, hat er nur Zugriff auf Verbindungen, die mit dem aktuell gültigen Server-Public-Key gestartet wurden; deswegen wird der Server-Public-Key periodisch gewechselt (i.a. jede Stunde; siehe oben).
Client und Server führen einen Dialog, durch den der Server die Identität und Berechtigung des Clients überprüfen kann.
Ist der Client unbekannt oder nicht berechtigt, wird die Verbindung an dieser Stelle abgebrochen.
In einem weiteren Dialog wird die neue Sitzung vorbereitet. Dabei wird u.a. der Terminal-Typ (Environment-Variable $TERM) und die Art der Sitzung (interaktive Dialog-Sitzung oder Ausführung eines Kommandos) festgelegt.
Zum Schluß startet der Server eine Login-Shell bzw. führt das gewünschte Kommando aus.

Authentifizierungs-Varianten des Client

Bei der Authentifizierung des Clients werden der Reihe nach verschiedene Verfahren ausprobiert. Dabei wird der Client als berechtigt betrachtet, sobald das erste Verfahren folgender Liste erfolgreich war:

Dem Client wird einfach geglaubt, wenn er behauptet, von einem bestimmten Rechner zu kommen. Außerdem muß ein entsprechender Eintrag in einer der folgenden Dateien vorhanden sein:
- /etc/hosts.equiv oder /etc/shosts.equiv:
  /etc/hosts.equiv regelt u.a. System-weite Zugangsberechtigungen für die r-Kommandos; die andere Datei hat die gleiche Syntax, wird jedoch nur vom SSH-Server ausgewertet.
  Beide Dateien werden in der aufgeführten Reihenfolge durchsucht.
- $HOME/.shosts oder $HOME/.rhosts:
  $HOME/.rhosts legt die Benutzer-spezifischen Zugangsberechtigungen für die r-Kommandos fest; die andere Datei hat die gleiche Syntax, wird jedoch nur vom SSH-Server ausgewertet.
  Diese Dateien werden in der angegebenen Reihenfolge durchsucht.
  Bei der spezifischen LRZ-Installation wird zusätzlich noch eine weitere Datei durchsucht.
Dieses Verfahren entspricht der Zugangs-Prüfung bei den r-Kommandos und ist deshalb genauso unsicher. Aus diesem Grunde sollte es vom Administrator des Remote-Rechners durch eine entsprechende Konfiguration des SSH-Servers unbedingt deaktiviert werden. In der Default-Konfiguration ist dies schon der Fall.
Zur Prüfung der Berechtigung werden die Dateien im vorhergehenden Verfahren verwendet. Zusätzlich muß jedoch noch der Client-Rechner durch eine strenge RSA-Authentifikation seine Identität beweisen.
Der Benutzer kann seine Identität durch eine individuelle RSA-Authentifikation nachweisen. Dazu ist jedoch auf dem Remote-Rechner ein entpsrechender Eintrag in $HOME/.ssh/authorized_keys erforderlich.
Der Benutzer kann ein gültiges Paßwort angeben.

Ist keines dieser Verfahren erfolgreich, wird der Verbindungs-Wunsch des Client abgewiesen.

Anmerkung: /etc/hosts.equiv und /etc/shosts.equiv funktionieren aus Sicherheits-Gründen nicht für die Kennung root. Für root muß deshalb eine individuelle Berechtigung konfiguriert werden, falls man nicht jedesmal ein Paßwort eingeben will.

Verwendete kryptographische Algorithmen

Bei SSH kommen kryptographische Verfahren an mehreren Stellen zum Einsatz.

Ein asymmetrisches Verfahren wird für die Authentifizierung der Kommunikations-Partner und für die sichere Übertragung eines zufällig erzeugten und nur einemal verwendeten Sitzungs-Key eingesetzt:

RSA (Akronym der Erfinder Rivest, Shamir und Adleman).
Dabei werden Key-Längen zwischen 768 und 1024 Bit empfohlen; längere Keys bringen in der nächsten Zeit keine zusätzliche Sicherheit, kosten aber deutlich Rechenzeit.

Zur Verschlüsselung der Daten während der Verbindung wird wegen des höheren Durchsatzes ein symmetrisches Verfahren verwendet. Je nach Installation der SW hat der Benutzer i.a. die Auswahl zwischen verschiedenen Algorithmen (die Durchsatz-Angaben in folgender Liste beziehen sich auf einen Pentium-Prozessor):

None: 100% Durchsatz.
Diese Variante ist nur für Debug-Zwecke geeignet, da keine Verschlüsselung durchgeführt wird.
DES (Data Encryption Standard): 56 Bit Key-Länge; 71% Durchsatz.
Für sehr hohe Sicherheits-Anforderungen ist dieses Verfahren wegen seiner geringen Key-Länge inzwischen zu schwach.
3DES (Tripple DES): 112 Bit Key-Länge; 45% Durchsatz.
Dieser Algorithmus kann empfohlen werden und ist als größter gemeinsamer Nenner bei allen SSH-Installationen immer vorhanden. Außerdem wird 3DES als Default verwendet und optionale individuelle RSA-Keys sind durch 3DES geschützt.
IDEA (International Data Encryption Algorithm): 128 Bit Key-Länge; 64% Durchsatz.
Auch dieses Verfahren kann empfohlen werden.
Blowfisch: 32 - 448 Bit Key-Länge möglich, SSH verwendet 128 Bit; 88% Durchsatz.
Dem Autor des Dokuments sind keine Aussagen über die Güte dieses Algorithmus bekannt.
Arcfour: Beliebige Key-Länge möglich, SSH verwendet 128 Bit; 91% Durchsatz.
Dem Autor des Dokuments sind keine Aussagen über die Güte dieses Algorithmus bekannt.

Kommandos des SSH-Paketes

Das SW-Paket SSH besteht aus mehreren Kommandos und Konfigurations-Dateien, die im folgenden näher beschrieben werden.

Übersicht über die Kommandos

Vor der detaillierten Beschreibung der einzelnen Kommandos von SSH sollen diese zur besseren Übersicht kurz vorgestellt werden:

ssh:
Einloggen bzw. Ausführen von Kommandos (Ersatz für telnet, rlogin und rsh)
slogin:
Alias für ein ssh ohne Kommando-Argument
scp:
Kopieren von Dateien (modifiziertes rcp, das ssh für den Daten-Transfer verwendet)
ssh-keygen:
Erzeugen eines Key-Paares (dient zur strengen Authentifizierung)
ssh-agent:
Optionaler Authentifizierungs-Agent zur leichteren Handhabung von individuellen Secret-Keys
ssh-add:
Steuerung des ssh-agent
make-ssh-known-hosts:
Tool zum einfachen Sammeln von Public-Keys (primär für Systemverwalter(innen))
sshd:
Server-Dämon auf dem Remote-Rechner

Primäre Kommandos

Für den Benutzer sind vor allem die Kommandos ssh und scp von Bedeutung. Diese Kommandos ersetzen die unsicheren r-Kommandos bzw. telnet und reichen für eine normale Nutzung von SSH aus.

Vor der ersten Nutzung von SSH muß man jedoch das Directory $HOME/.ssh erzeugen:

mkdir $HOME/.ssh chmod go= $HOME/.ssh

Verwendung von `ssh`

Das Kommando ssh ersetzt telnet, rlogin und rsh und besitzt zwei Aufruf-Varianten:

Der Aufruf

ssh [SSH_OPTIONS] HOST

entspricht der Funktion von rlogin (bzw. von rsh ohne Kommando-Argument) oder telnet, d.h. man kann sich damit auf einem Remote-Rechner für eine interaktive Dialog-Sitzung einloggen.
Als Äquivalent zum r-Kommando rlogin ist der ssh-Alias slogin vorhanden, der ebenfalls zum Einloggen verwendet werden kann:

slogin [SSH_OPTIONS] HOST
Mit dem Aufruf

ssh [SSH_OPTIONS] HOST COMMAND [COMMAND_ARGUMENTS]

kann man Kommandos auf einem Remote-Rechner ausführen (interaktiv oder im Batch-Betrieb) und damit rsh ersetzen.

Das nähere Verhalten von ssh wird bestimmt durch

Aufruf-Optionen,
eine individuelle Konfigurations-Datei und
eine System-weite Konfigurations-Datei

(in dieser Reihenfolge).

Folgende Optionen werden bei ssh häufiger benötigt:

-l LOGIN_NAME (`Login'):
Man arbeitet auf dem Remote-Rechner unter der anderen Kennung LOGIN_NAME.
Diese Option ist immer dann erforderlich, wenn die Kennungen auf den beteiligten Rechnern unterschiedliche Namen haben. Ohne diese Option nimmt ssh an, daß auf beiden Rechnern der Name gleich ist.
-n bzw. -f:
Die Eingabe von ssh (d.h. `stdin') wird nach /dev/null umgelenkt. Dies ist i.a. dann erforderlich, wenn ssh im Hintergrund laufen soll.
Bei `-n' wird die Eingabe sofort umgelenkt; bei `-f' erfolgt die Umlenkung erst nach dem Verbindungsaufbau und einer dabei evtl. erforderlichen Paßwort-Eingabe (bei `-n' kann kein Paßwort eingegeben werden).
-C (`Compress'):
Die Daten sollen während der Übertragung komprimiert werden.
-v (`Verbose Mode'):
Durch Diagnose-Meldungen wird jeweils mitgeteilt, was ssh im Augenblick gerade tut. Dies ist sehr hilfreich für den Debug von Problemen beim Verbindungsaufbau, bei der Authentifikation und bei der Konfiguration.
-c ALGORITHM (`Code'):
Mit dieser Option kann man den symmetrischen Algorithmus für die Verschlüsselung der Daten spezifizieren. Dabei kann ALGORITHM folgende Werte haben: idea, des, 3des, blowfish, arcfour und none.
Das Argument `none' (d.h. `keine Verschlüsselung') sollte man nur beim Debug von ssh-Problemen verwenden.
Außerdem sollte man daran denken, daß je nach Konfiguration von SSH-Client bzw. -Server nicht immer alle dieser Algorithmen zur Verfügung stehen. Als größter gemeinsamer Nenner ist jedoch immer `3des' möglich.

Verwendung von `scp`

Das Kommando scp ersetzt rcp und besitzt auch dessen Aufruf-Syntax:

scp [SCP_OPTIONS] [[LOGIN@]HOST:]FILENAME [...] [[LOGIN@]HOST:]FILENAME

Dabei bezeichnet LOGIN eine andere Kennung auf dem Remote-Rechner HOST.

Im Gegensatz zu rcp fragt jedoch scp bei Bedarf nach einem Paßwort (rcp würde an dieser Stelle einfach mit einem Fehler abbrechen).

Außerdem dürfen die bei einem scp angegebenen Dateien alle auf Remote-Rechnern liegen; die Datenübertragung erfolgt dann direkt zwischen den Remote-Rechnern und nicht auf einem Umweg über den lokalen Rechner. Dies kann jedoch in Firewall-Umgebungen manchmal zu Problemen führen.

Folgende Optionen werden bei scp häufiger benötigt:

-r (`Recursively'):
Directories sollen komplett mit dem gesamten Inhalt rekursiv kopiert werden.
-p (`Preserve'):
Beim Kopieren sollen die Datei-Rechte und die Zeitstempel der Dateien beibehalten werden.
-C (`Compress'):
Die Daten sollen während der Übertragung komprimiert werden.
-v (`Verbose Mode'):
Durch Diagnose-Meldungen wird jeweils mitgeteilt, was scp im Augenblick gerade tut. Dies ist sehr hilfreich für den Debug von Problemen beim Verbindungsaufbau, bei der Authentifikation und bei der Konfiguration.
-c ALGORITHM (`Code'):
Mit dieser Option kann man den symmetrischen Algorithmus für die Verschlüsselung der Daten spezifizieren. Dabei kann ALGORITHM folgende Werte haben: idea, des, 3des, blowfish, arcfour und none.
Das Argument `none' (d.h. `keine Verschlüsselung') sollte man nur beim Debug von scp-Problemen verwenden.
Außerdem sollte man daran denken, daß je nach Konfiguration von SSH-Client bzw. -Server nicht immer alle dieser Algorithmen zur Verfügung stehen. Als größter gemeinsamer Nenner ist jedoch immer `3des' möglich.

Schutz von X-Window-Verbindungen

Mit SSH kann man beliebige TCP/IP-Verbindungen durch einen sicheren Kanal leiten. Im Falle von X-Window wird dies jedoch besonders einfach gemacht:

Der gesamte X-Window-Verkehr wird durch Umleitung über einen Proxy-X-Window-Server automatisch verschlüsselt.
Die $DISPLAY-Environment-Variable wird auf dem Remote-Rechner automatisch gesetzt.
Eine xauth-Authentifizierung der X-Window-Clients wird automatisch gehandhabt.
Beim Verbindungsaufbau generiert SSH jedesmal ein X-Window-Magic-Cookie neu und zufällig; dieses Remote-Cookie wird erst auf dem lokalen Rechner automatisch in das originale Cookie des X-Window-Servers umgewandelt.
Dadurch verläßt das originale Cookie nie den lokalen Rechner und kann deshalb auch nicht auf einem Remote-Rechner von einem Hacker gestohlen werden.

Wie man sieht, kann man X-Window mit SSH sehr viel sicherer und zusätzlich auch noch einfacher handhaben als ohne SSH (man muß $DISPLAY nicht setzen und sich nicht um die xauth-Authentifizierung kümmern).

Will man nun ein xterm mit einer Shell haben, die auf einem Remote-Rechner läuft, ist folgender Aufruf zu empfehlen:

xterm [XTERM_OPTIONS] -e ssh [SSH_OPTIONS] HOST &

Wegen der höheren Netz- und CPU-Belastung sollte man nicht die Variante

ssh [SSH_OPTIONS] HOST xterm [XTERM_OPTIONS] -ls &

wählen. In diesem Fall wird nämlich der gesamte X-Window-Verkehr des xterm durch den SSH-Kanal geleitet und nicht nur die Daten der Shell-Sitzung wie im ersten Fall (und diese Daten haben ein deutlich geringeres Volumen als die Daten des X-Window-Verkehrs).

Für den Start von anderen X-Window-Anwendungen (d.h. nicht xterm) auf einem Remote-Rechner sind folgende Varianten zu empfehlen:

Falls kein Paßwort eingegeben werden muß:
ssh -n [SSH_OPTIONS] HOST X_WINDOW_APPLICATION [ARGUMENTS] &
Falls ein Paßwort erforderlich ist:
ssh -f [SSH_OPTIONS] HOST X_WINDOW_APPLICATION [ARGUMENTS] &

Maintenierung von RSA-Key-Paaren

Die Authentifizierung des Client kann u.a. durch eine Benutzer-spezifische RSA-Authentifikation erfolgen. Dazu benötigt der Benutzer jedoch ein individuelles RSA-Key-Paar, das im Directory $HOME/.ssh abgelegt und mit dem Kommando ssh-keygen verwaltet wird:

ssh-keygen [-f KEY_FILE] [-C COMMENT] [-b KEY_LENGTH]:
Mit dieser Aufruf-Variante erzeugt man ein neues neues Key-Paar, wobei folgende Informationen interaktiv abgefragt werden:
- Datei-Name für die Speicherung des Key-Paares, wobei $HOME/.ssh/identity die Voreinstellung ist.
  In der abgefragten Datei FILE wird nur der Secret-Key des Paares in einem binären Intern-Format abgelegt; der dazugehörige Public-Key wird als ASCII-Text in FILE.pub gespeichert.
  Diese Abfrage entfällt, falls schon ein Name über die Option `-f KEY_FILE' angegeben wurde.
  Existiert die Datei schon, wird nachgefragt, ob sie überschrieben werden darf.
- Paßwort, mit dem der Secret-Key verschlüsselt wird.
  Der Secret-Key wird i.a. zur Sicherheit in der Datei verschlüsselt abgelegt, damit ein in das System eingedrungener Hacker nichts mit der Datei anfangen kann. Dafür muß man jedoch die leichte Unbequemlichkeit in Kauf nehmen, bei jeder Verwendung des individuellen Secret-Keys das Paßwort erneut einzugeben bzw. den Authentifizierungs-Agenten zu verwenden.
  Gibt man bei ssh-keygen ein leeres Paßwort an, wird der Secret-Key nicht verschlüsselt! Man sollte sich jedoch genau überlegen, ob die lokale Umgebung dafür ausreichend sicher ist.
  Fällt einem Hacker der Secret-Key in die Hände (entweder weil er nicht verschlüsselt ist oder weil das Paßwort erraten werden konnte), kann sich der Hacker für den Benutzer ausgeben!
Anmerkungen:
- Damit das neue Key-Paar wirksam wird, muß man noch jeweils auf allen Remote-Rechnern 1-mal den neuen Public-Key in $HOME/.ssh/authorized_keys eintragen.
  Der Secret-Key sollte jedoch niemals den lokalen Rechner verlassen!
- Die Erzeugung des Key-Paares erfolgt automatisch und kann nicht reproduziert werden.
  Man muß deshalb ein neues Key-Paar generieren, falls man die Secret-Key-Datei verliert oder das dazugehörige Paßwort vergißt. Zum Glück kann außer Unbequemlichkeit (nämlich der dann erforderliche Austausch des Public-Keys auf allen Remote-Rechnern) nicht viel passieren, wenn man die Secret-Key-Datei durch ein gutes Paßwort geschützt hat; ohne dieses Paßwort kann nämlich niemand etwas mit der Secret-Key-Datei anfangen (auch der berechtigte Benutzer oder ein Hacker nicht).
- Aus Sicherheitsgründen sollte man das Paßwort für den Secret-Key niemals als Option von ssh-keygen angeben!
  Andere Benutzer können sich nämlich mit dem ps-Kommando die aktuell ablaufenden Programme einschließlich der verwendeten Optionen anzeigen lassen!
- Mit der Option `-b KEY_LENGTH' kann man die Länge der Key's festlegen. Dafür wird im Augenblick ein Wert zwischen 768 und 1024 Bit als ausreichend betrachtet (`1024' ist die Voreinstellung).
- Mit der Option `-C COMMENT' kann man zur besseren Übersicht einen Kommentar bzw. einen Namen für das Key-Paar vergeben. Dieser Kommentar wird jedoch von SSH vollkommen ignoriert.
ssh-keygen -p [-f KEY_FILE] (`Password'):
Ändern des Paßworts für die Aktivierung des Secret-Key
ssh-keygen -c [-f KEY_FILE] [-C COMMENT] (`Comment'):
Ändern des Kommentars
ssh-keygen -u [-f KEY_FILE] (`Update'):
Zur Verschlüsselung des Secret-Keys wird der aktuell gültige Default-Algorithmus verwendet (im Augenblick `3DES').

Nutzung des Authentifizierungs-Agenten

Stützt man sich bei der Authentifizierung des Client auf eine Benutzer-spezifische RSA-Authentifikation, sollte man aus Sicherheitsgründen den/die Secret-Key(s) aussschließlich verschlüsselt in Dateien ablegen. Dies hat jedoch die Unbequemlichkeit zur Folge, daß man zur Aktivierung eines Secret-Key jedesmal das dazugehörige Paßwort eingeben muß.

Um das Handling von Secret-Keys zu vereinfachen, wurde der Authentifizierungs-Agent entwickelt, der Secret-Keys im Memory aufbewahrt. Die Kommunikation mit dem Agenten erfolgt über eine spezielle Datei, die nur für den Benutzer les- und schreibbar ist. Diese Methode kann damit jedoch vom Superuser und jedem Prozeß desselben Benutzer umgangen werden. Bei höheren Sicherheitsanforderungen bzw. bei geringem Vertrauen zur lokalen Umgebung sollte deshalb der Agent nicht verwendet werden.

Man kann den Authentifizierungs-Agenten auf verschiedene Arten starten:

ssh-agent COMMAND [COMMAND_ARGUMENTS]:
Das Kommando COMMAND und alle seine Kinder können den Agenten nutzen.
ssh-agent beendet sich selbständig nach dem Ende von COMMAND. Dieses Verhalten ermöglicht ein einfaches Zusammenspiel mit X-Window (siehe die Beispiele).
eval `ssh-agent [-s | -c]`:
Der Agent wird als unabhängiger Dämon gestartet; der Agent erzeugt dann entsprechende Shell-Kommandos als Ausgabe, durch die die Shell (und deren Kinder) den Agenten nutzen können.
Bei dieser Variante muß der Agent am Ende der Sitzung explizit beendet werden (siehe nächste Aufruf-Variante).
Ohne diese Optionen versucht ssh-agent, selbständig herauszufinden, unter welcher Shell er aufgerufen wurde (davon hängt nämlich die Syntax der Ausgabe von ssh-agent ab). Mit der Option `-s' kann jedoch bei der Ausgabe die Syntax von sh / ksh / bash / ... erzwungen werden, bei `-c' die Syntax von csh / tcsh / ...
eval `ssh-agent -k [-s | -c]`:
Ein unabhängiger Agent-Dämon wird beendet.

Beim Start gelangt der Authentifizierungs-Agent aber noch nicht in den Besitz von Secret-Keys; diese müssen erst danach geladen werden. Für das Management von Secret-Keys im Agenten steht das Kommando ssh-add zur Verfügung:

ssh-add [KEY_FILE [...]]:
Laden von einem oder mehreren Secret-Keys; für jeden Secret-Key muß natürlich bei Bedarf das dazugehörige Paßwort angegeben werden.
ssh-add -d [KEY_FILE [...]]:
Entfernen von einem oder mehreren Secret-Keys
ssh-add -D:
Entfernen aller geladenen Secret-Keys
ssh-add -l:
Auflisten aller geladenen Secret-Keys

Beispiele für die Nutzung des Authentifizierungs-Agenten:

ssh-agent $SHELL:
Nachträglicher Start einer Sitzung unter Nutzung des Agenten
ssh-agent startx &:
Start des X-Window-Systems unter Nutzung des Agenten

Nutzung des Agenten bei X-Window mit xdm durch das Shell-Script $HOME/.xsession:

#!/bin/sh

if      [ -d $HOME/.ssh ]
then    EXEC='exec ssh-agent'
else    EXEC=exec
fi

if      [ -x $HOME/.xinitrc ]
then    $EXEC $HOME/.xinitrc
else    $EXEC xterm -geometry 80x24+0-60 -ls
fi

Syntax und Semantik der Konfigurations-Dateien

Bevor auf einzelne Konfigurations-Dateien näher eingegangen wird, werden sie in einer Übersicht kurz vorgestellt.

Dateien für die SSH-Clients

Die SSH-Clients ssh und scp werten einige Konfigurations-Dateien aus, die nur für den Owner schreibbar sein dürfen. Für diese Dateien wird jeweils ein Vorschlag für die Datei-Rechte gemacht (Oktal-Notation):

$HOME/.ssh:
Directory für die individuellen SSH-Dateien; Rechte: 0700 bzw. 0755
Konfigurations-Dateien:
- /etc/ssh_config:
  System-weite Konfigurationen; Rechte: 0644; hinsichtlich Syntax und Inhalt siehe die man-Page von sshd.
- $HOME/.ssh/config:
  Benutzer-spezifische Konfigurationen; Rechte: 0600; hinsichtlich Syntax und Inhalt siehe die man-Page von ssh.
$HOME/.ssh/identity:
Benutzer-spezifischer Secret-Key; Rechte: 0600; die Datei ist nur auf dem lokalen Ausgangs-Rechner erforderlich und darf nur für den Owner lesbar sein! Sie wird mit ssh-keygen erzeugt.
$HOME/.ssh/identity.pub:
Benutzer-spezifischer Public-Key; Rechte: 0644; der Key in dieser Datei sollte auf allen Remote-Rechnern in $HOME/.ssh/authorized_keys eingetragen werden. Die Datei wird mit ssh-keygen erzeugt.
$HOME/.ssh/random_seed:
Hilfs-Datei; Rechte: 0600; die Datei darf nur für den Owner lesbar sein! Sie wird automatisch erzeugt.

Bei der spezifischen LRZ-Installation gelten teilweise andere Pfade.

Dateien für den SSH-Server

Folgende Dateien werden vom SSH-Server sshd ausgewertet und dürfen nur für den Owner schreibbar sein (Notation wie im vorherigen Abschnitt):

/etc:
Directory mit allen Dateien für den SSH-Server; Rechte: 0755
/etc/ssh_host_key.pub:
Host-Public-Key; Rechte: 0644
/etc/nologin:
Alle Nicht-root-Verbindungen werden abgelehnt, falls diese Datei vorhanden ist; Rechte: 0644
Listen von berechtigten Rechnern und/oder Kennungen:
- /etc/hosts.equiv, /etc/shosts.equiv:
  System-weite Listen; Rechte: 0644
- $HOME/.shosts, $HOME/.rhosts:
  Benutzer-spezifische Listen; Rechte: 0600 bzw. 0644
Listen bekannter Host-Public-Keys von Remote-Rechnern:
- /etc/ssh_known_hosts:
  System-weite Liste; Rechte: 0644
- $HOME/.ssh/known_hosts:
  Benutzer-spezifische Liste; Rechte: 0600 bzw. 0644
$HOME/.ssh/authorized_keys:
Benutzer-spezifische Liste bekannter individueller Benutzer-Public-Keys; Rechte: 0600 bzw. 0644
Definition von Environment-Variablen für jede neue Verbindung:
- /etc/environment:
  System-weite Definitionen; Rechte: 0644
- $HOME/.ssh/environment:
  Benutzer-spezifische Definitionen; Rechte: 0600 bzw. 0644
Kommando, das am Anfang jeder neuen Verbindung ausgeführt wird:
- /etc/sshrc:
  System-weites Kommando; Rechte: 0755
- $HOME/.ssh/rc:
  Benutzer-spezifisches Kommando; Rechte: 0700 bzw. 0755

Bei der spezifischen LRZ-Installation gelten teilweise andere Pfade.

Syntax von `$HOME/.shosts` und `$HOME/.rhosts`

Die Benutzer-spezifische Datei $HOME/.rhosts legt bei den r-Kommandos auf einem Remote-Rechner fest, von welchem Rechner/Login aus man sich auf den Remote-Rechner ohne Paßwort einloggen kann. Diese Datei wird auch von SSH berücksichtigt.
$HOME/.shosts hat die gleiche Funktion und Syntax, wird jedoch nur von SSH ausgewertet.

Beide Dateien bestehen aus Zeilen folgender Form

HOST LOGIN

mit folgender Bedeutung: Wenn man auf dem lokalen Rechner HOST unter der Kennung LOGIN arbeitet, kann man sich auf dem Remote-Rechner unter der entsprechenden Kennung ohne Paßwort einloggen.

Leider sind bei diesen Dateien keine Leer-, Kommentar- und Fortsetzungs-Zeilen erlaubt.

Außerdem muß man bei HOST genau denjenigen Namen angeben, unter dem der lokale Rechner beim Remote-Rechner bekannt ist. Dabei kann HOST manchmal auch eine IP-Adresse sein.

Wie findet man aber nun den richtigen Wert für HOST heraus? Am einfachsten ist folgendes Vorgehen: Man loggt sich einmal mit SSH auf dem Remote-Rechner ein und gibt dann das Kommando who. In den meisten Fällen steht in der Ausgabe, von welchem Rechner aus man sich eingeloggt hat; bei einigen UNIX-Varianten muß man dafür zusätzlich bei who noch eine Option angeben, die Plattform-spezifisch ist. Eine ähnliche Information erhält man oft mit dem Kommando finger.
Angenommen der lokale Rechner heißt `foo', befindet sich in der Internet-Domain `bar.com' und hat die IP-Adresse `130.233.195.3'. Dann gibt es bei der Ausgabe von who folgende Fälle:

foo:
Der lokale Rechner ist unter seinem Kurznamen auf dem Remote-Rechner bekannt.
==> Man muß `foo' für HOST angeben.
foo.bar.com bzw. foo.bar.c:
Der lokale Rechner ist unter seinem vollen Domain-Namen auf dem Remote-Rechner bekannt; im 2. Fall gibt who nur nicht den ganzen Namen aus.
==> Man muß `foo.bar.com' angeben.
130.233.195.3:
Der lokale Rechner ist unter keinem Namen auf dem Remote-Rechner bekannt und taucht deshalb nur mit seiner IP-Adresse auf.
==> Man muß `130.233.195.3' angeben.
baz:
Der lokale Rechner ist unter einem anderen Kurznamen auf dem Remote-Rechner bekannt.
==> Man muß `baz' angeben.
baz.bar.com bzw. baz.bar.c:
Der lokale Rechner ist unter einem anderen Namen bekannt, der um die Domain ergänzt wird; im 2. Fall gibt who nur nicht den ganzen Namen aus. ==> Man muß `baz.bar.com' angeben.

Eine weitere Schwierigkeit ergibt sich dadurch, daß auf dem Remote-Rechner die Namens-Auflösung meistens mit Hilfe des Domain-Name-Service (DNS) erfolgt. Immer wenn der DNS nicht funktioniert, taucht auf dem Remote-Rechner der lokale Rechner nicht mehr mit seinem Namen sondern plötzlich mit seiner IP-Adresse auf.

Am einfachsten ist es i.a., wenn man in $HOME/.rhosts bzw. $HOME/.shosts für den Rechner foo (siehe oben) gleich mehrere Zeilen einträgt:

foo LOGIN
foo.bar.com LOGIN
130.233.195.3 LOGIN

Zur Sicherheit sollte man auf allen Remote-Rechnern die Dateien $HOME/.rhosts bzw. $HOME/.shosts regelmäßig (d.h. alle 2 - 6 Monate; am besten jeweils bei der regelmäßigen Änderung des Paßworts) überprüfen, ob sie noch aktuell sind. Dabei sollten besonders die inzwischen überflüssigen Einträge gelöscht werden.

Syntax von `$HOME/.ssh/known_hosts`

Diese Datei enthält eine Liste der bekannten Host-Public-Keys von Remote-Rechnern und wird i.a. automatisch von ssh ergänzt.

In dieser Datei werden leere Zeilen und Zeilen, die mit `#' beginnen, als Kommentar betrachtet und deshalb ignoriert.

Die einzelnen Einträge bestehen aus ASCII-Feldern, die durch eine Blank-Folge getrennt sind. Da eines dieser Felder aus einem Public-Key besteht, werden die Zeilen sehr lang; Fortsetzungs-Zeilen sind leider nicht möglich. Manche Editoren verkraften nicht derartig lange Zeilen; man muß dann für diesen Ausnahmefall auf einen anderen Editor ausweichen (z.B. emacs).

Das erste Feld besteht aus einer Namensliste (Namen durch Komma getrennt), die festlegt, für welchen Rechner der Eintrag gilt. Dabei ist es üblich, den Kurz-Namen des Rechners, seinen vollen Domain-Namen und seine IP-Adresse anzugeben:

foo,foo.bar.com,130.233.195.3

Achtung: Zwischen den einzelnen Namen darf kein Blank vorkommen.

Hinsichtlich der genauen Syntax siehe die man-Page von sshd.

Syntax von `$HOME/.ssh/authorized_keys`

Diese Datei enthält eine Liste der bekannten Benutzer-Public-Keys. Dabei werden leere Zeilen und Zeilen, die mit `#' beginnen, als Kommentar betrachtet und deshalb ignoriert.

Eine einfache Form dieser Datei erhält man, indem man einfach einen Benutzer-Public-Key hinten anhängt:

cat identity.pub >> authorized_keys

Zusätzlich ist aber bei jedem Eintrag noch ein optionales Options-Feld möglich, dessen genaue Syntax in der man-Page von sshd beschrieben wird.

Häufiger auftretende Probleme

Im folgenden werden Probleme (und deren Lösung) beschrieben, die bei der Benutzung von SSH häufiger auftreten. Wird ein konkretes Problem hier nicht behandelt, hilft möglicherweise die SSH-FAQ (Frequently Asked Questions) weiter.

Meldung ``Host key not found` ...'

ssh / slogin / scp melden sich mit folgender Frage:

Host key not found from the list of known hosts.
Are you sure you want to continue connecting (yes/no)?

Diese Frage wird dann gestellt, wenn der Remote-Rechner keinen Eintrag in der System-weiten oder Benutzer-spezifischen Tabelle der bekannten Host-Public-Keys besitzt. Mögliche Ursachen:

Man besucht den Rechner zum ersten mal und weder die/der Systemverwalter(in) noch die/der Benutzer(in) haben den Host-Public-Key eingetragen.
Man hat den Host-Public-Key aus Versehen oder mit Absicht aus den Tabellen entfernt.
Die Auflösung des Rechner-Namens hat sich geändert bzw. funktioniert im Augenblick nicht und der Remote-Rechner erscheint deshalb lokal plötzlich unter einem anderen Namen.

Im Normalfall kann man einfach mit `yes' antworten. ssh macht dann weiter und trägt außerdem den Host-Key in die Benutzer-spezifische Liste $HOME/.ssh/known_hosts ein; beim nächsten Mal ist dann dadurch der Remote-Rechner bekannt und die Frage unterbleibt.

`ssh` verlangt immer ein Paßwort

Manchmal verlangt ssh bzw. scp ein Paßwort, obwohl der lokale Rechner am Remote-Rechner in $HOME/.shosts bzw. $HOME/.rhosts eingetragen ist. Dies kann mehrere Ursachen haben:

Die Dateien $HOME/.shosts und/oder $HOME/.rhosts bzw. die Directories, in denen sich diese Dateien befinden, haben zu großzügige UNIX-Rechte. In diesem Fall werden diese Dateien aus Sicherheitsgürnden von ssh ignoriert.
Zur Behebung müssen die Rechte restriktiver gesetzt werden:

chmod go-w $HOME $HOME/.rhosts $HOME/.shosts
Der entsprechende Eintrag in $HOME/.shosts bzw. $HOME/.rhosts ist falsch und wird deshalb nicht als zutreffend erkannt. Der gleiche Effekt tritt auf, wenn sich auf dem Remote-Rechner die Auflösung des Rechner-Namens geändert hat bzw. im Augenblick nicht funktioniert und dadurch der lokale Rechner auf dem Remote-Rechner plötzlich unter einem anderen Namen erscheint.
Zur Behebung siehe den Abschnitt über die Syntax dieser Dateien.
Der SSH-Server des Remote-Rechners ist so konfiguriert, daß er diese Dateien ignoriert.
Zur Behebung muß man sich an die/den Remote-Systemverwalter(in) wenden.
Man (bzw. scp intern) verwendet am lokalen Rechner ein ssh-Programm, das keine Set-UID-root-Berechtigung hat. Dadurch kann sich der lokale Rechner nicht ausreichend ausweisen und die Dateien sind auf dem Remote-Rechner wertlos.
Zur Behebung muß man ein ssh-Programm mit Set-UID-root-Berechtigung verwenden. Am LRZ z.B. gibt es ein ssh-Programm in /client/bin und in /usr/local/bin; aber nur /usr/local/bin/ssh ist Set-UID-root. In diesem Fall reicht eine entsprechende Umstellung des Such-Pfades $PATH aus.
Findet man lokal keine Set-UID-root-ssh, muß man sich an die/den lokale(n) Systemverwalter(in) wenden.
Auf dem Remote-Rechner liegt $HOME unter AFS mit sehr restriktiven AFS-Rechten und auf dem lokalen Rechner gibt es kein AFS oder man hat kein AFS-Token oder das lokale ssh-Programm unterstützt kein AFS. In diesem Fall kann der Remote-SSH-Server die Dateien nicht lesen (der SSH-Server hat nicht die entsprechenden AFS-Rechte).
Zur Behebung hat man nur die Möglichkeit, die Dateien weltweit lesbar zu machen. Es empfiehlt sich dabei folgendes Vorgehen, durch das man nur die erforderliche Datei lesbar macht, die restlichen Dateien von $HOME aber geschützt bleiben:
```
cd     $HOME
mkdir  pub
fs     setacl . system:anyuser l
fs     setacl pub system:anyuser read
mv     .rhosts pub
ln     -s pub/.rhosts
```
Mit $HOME/.shosts muß man analog verfahren.
Achtung: Bei AFS erben neu angelegte Sub-Directories die Rechte vom Eltern-Directory. Wenn man also z.B. in $HOME ein Directory neu erzeugt, sollte man sich überlegen, ob dieses Directory auch das Recht `system:anyuser l' erhalten soll und bei Bedarf die Access-Control-List (ACL) mit dem Kommando `fs setacl ...' anpassen.
Will man nicht, daß andere Benutzer diese Dateien lesen und $HOME aulisten können, muß man weiterhin die Unbequemlichkeit einer Paßwort-Eingabe in Kauf nehmen.

Bei der Suche nach der konkreten Ursache ist die ssh-Option `-v' sehr hilfreich; ssh sagt dann genau, was und warum es etwas tut.

Meldung ``HOST IDENTIFICATION HAS CHANGED` ...'

Beim Verbindungsaufbau geben ssh / slogin / scp folgende Warnung aus:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@       WARNING: HOST IDENTIFICATION HAS CHANGED!         @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the host key has just been changed.
Please contact your system administrator.
Add correct host key in KNWON_HOSTS to get rid of this message.
Agent forwarding is disabled to avoid attacks by corrupted servers.
X11 forwarding is disabled to avoid attacks by corrupted servers.
Are you sure you want to continue connecting (yes/no)?

Dafür kann es mehrere Gründe geben:

Man wird gerade von einem Hacker angegriffen.
Auf dem Remote-Rechner wurde der Host-Key geändert (ein neuer Key generiert oder auf einen alten Key zurückgesetzt).
Auf dem lokalen Rechner wurde der Eintrag für den Remote-Rechner in den Tabellen der bekannten Host-Public-Keys geändert.

Erfahrungsgemäß handelt es sich in den meisten Fällen glücklicherweise nicht um den Angriff eines Hackers. Da man aber nicht feststellen kann, um welchen der Fälle es sich handelt, wendet man sich am besten an die/den Systemverwalter(in) (wie es in der Warnung geraten wird).
Beim LRZ werden z.B. Änderungen von Host-Keys über Kurzmitteilungen angekündigt.

Abweichungen der spezifischen LRZ-Installation vom Default

Bei der spezifischen LRZ-Installation der SSH wurde aus organisatorischen Gründen von den Voreinstellungen abgewichen:

Durch einen Patch kann der SSH-Client zusätzlich evtl. vorhandene Zugriffsausweise von AFS und Kerberos V4 zum Server übertragen.
Die Konfigurations- und Hilfs-Dateien für den SSH-Server befinden sich normalerweise in /etc.
Beim LRZ werden diese Dateien im Directory /usr/local/etc/ssh (SSH_DIR) abgelegt. Dadurch können auch die Rechte für dieses dedizierte Directory auf 0711 reduziert werden.

Folgende für den Benutzer relevanten Pfade weichen vom Default ab:

Default	LRZ-Installation
`/etc/shosts.equiv`	`SSH_DIR/shosts.equiv`
`/etc/ssh_config`	`SSH_DIR/config`
`/etc/ssh_host_key.pub`	`SSH_DIR/host_key.pub`
`/etc/ssh_known_hosts`	`SSH_DIR/known_hosts`
`/etc/sshrc`	`SSH_DIR/sshrc`

Folgende Dateien werden in der angegebenen Reihenfolge als Benutzer-spezifische Listen von berechtigten Rechnern ausgewertet:
- $HOME/.ssh/shosts (LRZ-Erweiterung)
- $HOME/.shosts
- $HOME/.rhosts

Weitere Informationen zu SSH

Weitere Informationen zu SSH kann man bei folgenden Stellen finden:

Home-Page
Quellen (Mirror des DFN-CERT)
Unterstützung für AFS und Kerberos V4 (Patch zu SSH)
Kurzeinführung in Englisch: Getting started
SSH-FAQ (Frequently Asked Questions)
News-Group comp.security.ssh

Heller

Informationen für ...

Secure Shell (SSH) für Benutzer

Secure Shell (SSH) für Benutzer

Ernst Bötsch

1998-09-09

Einführung

Motivation

Probleme bei den Berkeley Remote-Diensten

Eigenschaften der SSH

SSH-Interna

Kommandos des SSH-Paketes

Übersicht über die Kommandos

Primäre Kommandos

Verwendung von ssh

Verwendung von scp

Schutz von X-Window-Verbindungen

Syntax und Semantik der Konfigurations-Dateien

Häufiger auftretende Probleme

ssh verlangt immer ein Paßwort

Meldung `HOST IDENTIFICATION HAS CHANGED ...'

Weitere Informationen zu SSH

Verwendung von `ssh`

Verwendung von `scp`

`ssh` verlangt immer ein Paßwort

Meldung ``HOST IDENTIFICATION HAS CHANGED` ...'