6 Einloggen auf anderen Maschinen

Dieser Abschnitt beschreibt, wie man auf die einfachste Weise ssh benutzt. ssh übernimmt im Wesentlichen die Aufgaben von telnet, benutzt bei den Bewegungen aber einen Verschlüsselungsalgorithmus (siehe die Unix Man-Page man ssh ). Telnet funktioniert zwar noch, wird aus Gründen der Netzsicherheit nicht mehr empfohlen.

6.1 Telnet, ftp, rlogin

Die Netzwerkprotokolle bzw. Anwendungen telnet, ftp und rlogin stehen auf vielen Maschinen des WSI nicht mehr zur Verfügung. Sie haben alle die Eigenschaft, Passwörter unverschlüsselt über das Netz vom lokalen zum entfernten Host und zurück zu verschicken. Die Leitungen zwischen den Rechnern sind in keinem Fall direkt, sondern laufen in der Regel hardwaremäßig über mehrere Knotenpunkte (andere Rechner). An jedem dieser Knoten kann das Passwort abgehört werden. Lesen Sie bitte das Kapitel über Sicherheit zu diesem Thema. In der Regel werden Benutzerinnen und Benutzer für den Schaden haftbar gemacht, der durch Missbrauch ihres Accounts entsteht.

Telnet und rlogin werden durch ssh ersetzt, ftp durch scp. Diese beiden Anwendungen verwenden wirksame Verschlüsselungsalgorithmen und gelten z.Zt. als sicher.

Telnet hat außerdem den Nachteil, dass bestimmte Informationen nicht automatisch zwischen den beiden beteiligten Hosts ausgetauscht werden. Dies führt u.a. dazu, dass man nicht einfach Software nutzen kann, die auf dem entfernten Host läuft und dem Benutzer eine Graphische Oberfläche zur Verfügung stellen möchte. Das Problem lässt sich zwar mit Hilfe der Umgebungsvariablen DISPLAY lösen, aber die Lösung wird hier natürlich nicht beschrieben...

6.2 Secure Shell Client (ssh)

Die einfachste Möglichkeit, ssh zu benutzen, ist es, sich auf die Default-Einstellungen zu verlassen und einfach loszulegen. Der Hauptunterschied von ssh zu telnet ist, dass unter ssh der entfernte Host Host dem lokalen Host "bekannt " sein muss, und dass eine Kombination von Verschlüsselungs- und Entschlüsselungs-Codes aufgestellt worden sein muss. Dies kann z.B. automatisch geschehen und zwar je dann, wenn ein bestimmter entfernter Host zum ersten Mal kontaktiert wird. Die einfachste Vorgehensweise lautet:

1. Man tippt am Prompt

           
           ssh [-l login name] hostname
        

   z.B.

           ssh -l zxmbla99 linux13.zdv.uni-tuebingen.de
        

2. Man bestätigt mit yes <enter>, wenn man gefragt wird, ob man fortfahren möchte, obwohl der Rechner, den man gerade kontaktieren will, dem ssh noch nicht bekannt ist.

3. Man gibt sein gewöhnliches Password auf dem entfernten Host ein und fühlt sich ansonsten wie zuhause.

Dieser Prozess generiert ein .ssh/ Unterverzeichnis auf dem lokalen und dem entfernten Home-Verzeichnis, in dem zwei Dateien stehen, die einen nicht weiter kümmern müssen (sie enthalten die erwähnten Schlüsselcodes).

Ab der zweiten Sitzung, die auf einen jeweiligen remote Host zugreift, entfallen Schritte 2 und 3.

Andere Möglichkeiten zum Umgang mit ssh sind in aller Breite in den Unix Man-Pages beschrieben.

6.3 Probleme etc.

Die ssh-Verbindung zu den Linux-Maschinen aus dem ZDV bringt ein mildes Problem mit dem Bildschirmeditor unter Pine mit sich: der Text auf dem Schirm ist unter Pine invers (weiss auf schwarz) und man kann markierten und unmarkierten Text nicht mehr voneinander unterscheiden. Um dieses Problem zu beheben kann man am Unix-Prompt des entfernten Hosts die Zeile

       set term=vt100
   

6.4 Login von Rechnern außerhalb des WSI

Von Rechnern außerhalb des WSI-Netzes sind nur einige bestimmte Rechner innerhalb des WSI-Netzes, die sogenannten SSH-Gateways, per ssh erreichbar. Die SSH-Gateways sind ausschließlich dazu gedacht, sich zu einem anderen Rechner innerhalb des WSI-Netzes per ssh weiterzuverbinden. Dementsprechend steht auf den SSH-Gateways auch nur eine stark eingeschränkte Auswahl von Programmen zur Verfügung: ssh, scp und cvs.

Insgesamt verfügt das WSI über sechs SSH-Gateway-Rechner mit den Namen ssh1.informatik.uni-tuebingen.de bis ssh6.informatik.uni-tuebingen.de.

Die typische Befehlsfolge für den Login von außen auf den WSI-Rechner midgard.informatik.uni-tuebingen.de läuft in dieser Reihenfolge ab:

1. ssh ssh3.informatik.uni-tuebingen.de um sich zum Gateway zu verbinden.
2. ssh midgard.informatik.uni-tuebingen.de um sich zum eigentlichen Ziel zu verbinden.

Der Abschnitt 6.5 beschreibt, wie die Verbindung über den Gateway-Rechner auch automatisch durch den SSH-Client durchgeführt werden kann.

6.4.1 Das tmp-Verzeichnis auf den SSH-Gateways

Die Gateway-Rechner verfügen über mehrere Gigabyte freien Platz in der tmp-Partition. Benutzer, deren Rechner am WSI sich nicht direkt per shh zu einem Rechner außerhalb des WSI verbinden darf, können in diesem Verzeichnis Dateien für den weiteren Transfer per scp zwischenspeichern. Dabei ist zu beachten, dass der Name des Verzeichnisses /tmp Programm ist: Dateien, die länger als einen Tag unberührt bleiben werden automatisch gelöscht. Die Dateien /tmp-Verzeichnis werden zu dem mit der umask 077 versehen, so dass nur der Benutzer, der die Datei dort hinkopiert hat diese Datei lesen und schreiben kann.

Eine Übertragung vom heimischen Rechner home zum WSI-Rechner midgard per scp unter Zuhilfenahme des /tmp-Verzeichnisses könnte so ablaufen:

Im ersten Schritt wird das Verzeichnis mein-tolles-paper samt Inhalt per scp auf den Gateway-Rechner ssh4.informatik.uni-tuebingen.de in das dortige /tmp-Verzeichnis kopiert:

[0 eric@home ~] scp -r mein-tolles-paper knauel@ssh4.informatik.uni-tuebingen.de:/tmp

Im zweiten Schritt werden die Daten vom SSH-Gateway auf den Arbeitsplatzrechner kopiert:

[0 eric@home ~] ssh ssh4.informatik.uni-tuebingen.de -l knauel
Last login: Fri Apr 15 09:25:53 2005 from midgard.informa

       Willkommen am Wilhelm-Schickard-Institut für Informatik
       =======================================================

Dieser Rechner ist ein SSH-Gateway des WSI. Das bedeutet:

1.) Dieser Rechner ist von außen per SSH zu erreichen und alle Rechner
    innerhalb des WSI sind von diesem Rechner aus per SSH zu
    erreichen.

2.) Benutzer sollen diesen Rechner *ausschließlich* dazu verwenden,
    SSH-Verbindungen zu anderen Rechnen innerhalb des WSI
    aufzubauen. Das Starten anderer Anwendungen ist nicht gestattet.

3.) Benutzer können Dateien lokal (/tmp) auf diesen Rechner kopieren,
    diese Dateien werden in der darauffolgenden Nacht automatisch
    gelöscht.

Mehr Information zu den SSH-Gateways befindet sich auf der Seite

 http://www-doc.informatik.uni-tuebingen.de/user/html/user_6.html

%scp -r /tmp/mein-tolles-paper midgard:/usr/local/cool-stuff/

Um ohne den Umweg über das /tmp-Verzeichnis Daten von und zu einem beliebigen Host am WSI zu übertragen, lesen Sie bitte Abschnitt 6.5.

6.5 Login über die SSH-Gateways mit OpenSSH automatisieren

Die in diesem Abschnitt beschriebene Konfiguration für OpenSSH erleichtert es ganz erheblich sich von einem Rechner außerhalb des WSI zu einem Rechner innerhalb des WSI zu verbinden. Die hier beschriebene Konfiguration ist auf dem heimischen Rechner bzw. den Rechner außerhalb des WSI-Netzes durchzuführen.

Die aktuellen Versionen von OpenSSH (siehe hier) verfügen über ein Feature, dass die Verbindung über SSH-Gateway-Rechner erleichtert und automatisiert. Mit der Konfigurations-Option ProxyCommand wird ein Programm festgelegt, welches ausgeführt wird, um sich zum Server zu verbinden. Ein solches Programm ist connect (siehe hier). Connect stellt SSH-Verbindungen über verschiedene Arten von Proxies her.

Die Option ProxyCommand wird ab OpenSSH Version 3.6 unterstützt. Bei älteren Versionen, wie der verbreiteten Version 3.4, führt die Benutzung der Option nicht zu einem Fehler, sondern wird stillschweigend ignoriert. Dies führt bei der hier vorgestellten Konfiguration zu einer Schleife beim Verbindungsaufbau, die irgendwann durch die irreführende Fehlermeldung ssh_exchange_identification: Connection closed by remote host abbricht. Bitte prüfen Sie zuerst mit dem Aufruf ssh -V, ob OpenSSH 3.6 oder neuer installiert ist.

Neben den Hostnamen für die einzelnen SSH-Gateways gibt es noch den Hostnamen sshgw.informatik.uni-tuebingen.de, welcher abwechselnd einem der sechs Gateway-Rechner entspricht. Um die Last gleichmäßig zu verteilen, ist es sinnvoll diesen Hostnamen im Zusammenhang der Konfiguration mit dem ProxyCommand zu verwenden. Da die Rechner denselben SSH-Hostkey verwenden, sollte für den Host sshgw die zusätzliche Überprüfung der IP-Adresse bei der Prüfung des Hostkeys abgestellt werden.

Für die SSH-Gatways des WSI empfiehlt sich die folgende Verwendung von connect in der ~/.ssh/config des heimischen Rechners:

Host sshgw.informatik.uni-tuebingen.de
  CheckHostIP no
 
Host *.informatik.uni-tuebingen.de
  ProxyCommand ssh -o ProxyCommand=none sshgw.informatik.uni-tuebingen.de connect %h %p

Wird eine Verbindung zu einem Rechner innerhalb des WSI-Netzes aufgebaut, wird dafür zuerst ein neuer Aufruf von SSH zum SSH-Gateway getätigt. Auf dem Gateway wird connect ausgeführt, welches dann eine direkte Verbindung zum Server herstellt. Nach dem Aufruf von z. B. ssh midgard.informatik.uni-tuebingen.de landet man daher direkt auf dem Rechner midgard, ohne je direkt mit dem Gateway-Rechner arbeiten zu müssen.

Unterscheidet sich der Accountname auf dem lokalem Rechner vom WSI-Accountnamen, ist es notwendig den WSI-Accountnamen beim Aufruf von ProxyCommand mit der Option -l mein-wsilogin anzugeben:

Host sshgw.informatik.uni-tuebingen.de
  CheckHostIP no
 
Host *.informatik.uni-tuebingen.de
  ProxyCommand ssh -l mein-wsilogin -o ProxyCommand=none sshgw.informatik.uni-tuebingen.de connect %h %p

Eine Verbindung vom heimischen Rechner home zum WSI-Rechner midgard könnte dann so aussehen:

[0 eric@home ~] ssh midgard.informatik.uni-tuebingen.de -l mein-wsilogin
Password:
Password:
Last login: Fri Apr 15 08:12:29 2005 from 134.2.13.195
[...]
[0 mein-wsilogin@midgard ~]

Beim Login wird hier zweimal nach dem Passwort gefragt: Einmal fragt der SSH-Gateway-Rechner nach dem Passwort und einmal der Zielhost midgard. Der Abschnitt 6.6 beschreibt, wie die doppelte Eingabe des Passworts vermieden werden kann.

Die Option -l mein-wsilogin im obigen Beispiel sorgt dafür, dass für der Accountname mein-wsilogin für den Login auf dem Rechner midgard verwendet wird (für den Login auf den SSH-Gateways wurde dies ja bereits in Konfigurationsdatei festgelegt). Die Angabe dieser Option ist nur notwendig, wenn sich der Username auf dem lokalem Rechner (home im Beispiel) vom WSI-Accountnamen unterscheidet. Um die Angabe des WSI-Accountnames bei jedem Aufruf von ssh zu vermeiden, ist es empfehlenswert die Zeile

User mein-wsilogin

ProxyCommand und scp

[0 eric@home ~] scp -r mein-tolles-paper knauel@midgard.informatik.uni-tuebingen.de:/usr/local/cool-stuff

6.6 Einloggen ohne Passwort

Um sich ohne Eingabe eines Passworts per ssh einzuloggen, wird häufig die Authentifizierung durch ein Public-Key-Verfahren verwendet. Diese Authentifizierungs-Methode kann auf den Rechnern des WSI nicht verwendet werden. Voraussetzung für die Public-Key-Authentifizierung ist es den Public-Key im Home-Verzeichnis abzulegen. Da das Home-Verzeichnis aber im AFS liegt, bräuchte der SSH-Server für den Zugriff auf den Public-Key ein Token, was aber nur nach bereits erfolgter Authentifizierung vorhanden ist. Diese wechselseitige Abhängigkeit kann nicht aufgelöst werden.

Allerdings erlauben die SSH-Gateways die Authentifizierung durch ein Kerberos-V-Ticket. Die Authentifizierung über Kerberos V hat den Vorteil, dass nach einmaliger Eingabe des Passworts um das Ticket zu holen, keine weiteren Passwortabfragen für den Login via ssh mehr notwendig sind. Die folgende Beschreibung richtet sich an erfahrene UNIX-Benutzer und setzt eine entsprechende Version von OpenSSH mit Unterstützung von GSS- und Kerberos-Authentifizierung voraus. (Auf den FreeBSD- und OS-X-Rechnern des WSI ist ein solches OpenSSH installiert.)

Um die Kerberos-Authentifizierung im SSH-Client zu aktivieren, sind die folgenden Einträge in der ~/.ssh/config notwendig:

GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes

Im Zusammenspiel mit dem zufälligen DNS-Eintrag sshgw ist aus ziemlich komplizierten Gründen kein Login mit Kerberos-Authentifizierung möglich. Abhilfe schafft die folgende Konfiguration:

Host *.informatik.uni-tuebingen.de
  GSSAPIAuthentication yes
  GSSAPIDelegateCredentials yes
  ProxyCommand ssh -l mein-wsilogin -o ProxyCommand=none ssh`jot -r 1 1 4`.informatik.uni-tuebingen.de connect %h %p

Der Aufruf jot -r 1 1 4 berechnet eine Zufallszahl zwischen eins und vier. Das Programm jot ist auf BSD-Systemen verfügbar, für Benutzer von Linux-System empfiehlt sich dieses ProxyCommand:

  ProxyCommand ssh -l mein-wsilogin -o ProxyCommand=none ssh`perl -e "print 1+int(rand(4));"`.informatik.uni-tuebingen.de connect %h %p

6.6.1 Konfiguration von Kerberos V

In diesem Abschnitt findet sich eine Sammlung von Kerberos-Konfigurationen für verschiedene Betriebssysteme. Diese Konfigurationen sind lediglich als Hinweise für die Konfiguration des heimischen Rechners zu verstehen und sind daher von üblichen Benutzer-Unterstützung durch die Administratoren des WSI ausgeschlossen. Wir nehmen gerne weitere Konfigurations-Tipps entgegen (per Mail an admin@informatik.uni-tuebingen.de) und veröffentlichen die Tipps an dieser Stelle.

Mit einer Kerberos-V-Installation auf dem heimischen Rechner wird der Login zu den Rechnern des WSI über die SSH-Gateways deutlich komfortabler: OpenSSH kann das Kerberos-Ticket über den sogenannten GSS-Mechanismus an den Server weiterreichen und sich dadurch authentifizieren. Die dafür notwendige SSH-Konfiguration ist im Abschnitt 6.6 beschrieben.

Generell

no-addresses = true

FreeBSD 5.x

MacOS X

[libdefaults]
        default_realm = INFORMATIK.UNI-TUEBINGEN.DE
        forwardable = yes
        dns_lookup_kdc = no
        dns_lookup_realm = no

[appdefaults]
        no-addresses = yes

[realms]
        INFORMATIK.UNI-TUEBINGEN.DE = {
                kdc = KDC2.INFORMATIK.UNI-TUEBINGEN.DE
                kdc = KDC1.INFORMATIK.UNI-TUEBINGEN.DE
                admin_server = KDC1.INFORMATIK.UNI-TUEBINGEN.DE
                default_domain = INFORMATIK.UNI-TUEBINGEN.DE
        }
        GRIS.UNI-TUEBINGEN.DE = {
                kdc = 134.2.176.153
                admin_server = 134.2.176.153
        }

[domain_realm]
        .informatik.uni-tuebingen.de = INFORMATIK.UNI-TUEBINGEN.DE
        informatik.uni-tuebingen.de = INFORMATIK.UNI-TUEBINGEN.DE

[logging]
        default = FILE:/var/tmp/krb5lib.log

SuSE Linux 9.0

Gentoo Linux

emerge heimdal && revdep-rebuild && emerge openssh

6.7 Hinweise für andere SSH-Clients

Dieser Abschnitt gibt einige Hinweise zur Konfiguration von verschiedener SSH-Clientsoftware.

WinSCP

Fugu