Arbeiten mit ssh - eine Übersicht für den Nutzer

Jürgen Fuhrmann

fuhrmann@wias-berlin.de

Zusammenfassung:

Dieses Dokument soll einige praktische Empfehlungen für die Arbeit mit ssh geben. Es erhebt keinen Anspruch auf Vollständigkeit. Es soll vielmehr eine praktische Anleitung für den weniger bewanderten Netznutzer sein.

Inhalt

Die Zeit vor ssh

telnet

Programm zum Verbindungsaufbau mit einem anderen Rechner im Netzwerk mit obligatorischer Abfrage von Nutzernamen und Paßwort (Authentifizierung).

ftp

``File Transfer Protcol''. Programm zum Übertragen von Dateien von einem Rechner auf den anderen mit Abfrage von Nutzernamen und Paßwort. Diese können aber in der Datei $HOME/.netrc gespeichert sein.

rlogin

``remote login''. Programm zum Verbindungsaufbau mit einem anderen Rechner. Im Unterschied zu telnet kann der Nutzername auf dem Zielrechener in der Kommandozeile angegeben werden und die Paßwortabfrage eingespart werden, wenn auf dem Zielrechner Nutzername und Rechnername des Ausgangsknotens in $HOME/.rhosts eingetragen sind.

rsh

``remote shell''. Ausführung eines Kommandos auf dem Zielrechener. Authentifizierung wie bei rlogin .

rcp

``remote copy''. Dateikopie von einem Rechner zum anderen mit Authentifizierung wie bei rlogin.

X11

Öffnen eines Fensters des Zielrechners auf dem eigenen Bildschirm. Dazu sind zwei Vorraussetzungen nötig. Die Umgebungsvariable $DISPLAY auf dem Zielrechner muß auf den Ausgangsrechner gesetzt sein, und auf dem Ausgangsrechener muß mit Hilfe des Kommandos xhost das Öffnem von Fenstern des Zielrechners erlaubt worden sein.

CVS

``Concurrent Version System'' Management von Quellcodeversionen für parallel arbeitende Entwickler. Dieses System ist netzwerkfähig unter Benutzung von rsh oder aber eines eigenen Netzwerksystems.

Wo liegt hier das Problem ? Das Internet basiert im wesentlichen auf einem TCP/IP genannten Paketvermittlungsprotokoll. Im Prinzip heißt das, daß alle transferierten Daten in kleine Pakete aufgeteilt werden, mit der Adresse des Zielrechners versehen und abgesendet werden. Vermittlungsstellen - Router genannt - definieren den Weg dieser Pakete anhand der Adresse und der verfügbaren Leitungen. In Wirklichkeit sind diese Pakete aber wie Postkarten - jeder, der an die Datenleitung herankommt, kann sie lesen. Das trifft auch für die Paßworte zu. Auch diese werden im Klartext gesendet. Außerdem können Absender gefälscht sein.

Abhilfe kann hier nur durch Verschlüsselung geschaffen werden. ssh mit den weiteren dazugehörenden Kommandos ist ein Werkzeug, welches alle gesendeten Daten verschlüsselt und telnet , rlogin , ftp , rsh , rcp ersetzt, sowie die Schaltung sicherer Verbindungen - Tunnel genannt - für Protokolle wie X11 oder CVS erlaubt. Dabei werden die Daten genauso mit dem TCP/IP-Protokoll übertragen, wie sonst auch, nur werden die Daten jetzt vor dem Absenden verschlüsselt.

Der Zusatz an Funktionalität legt die Befürchtung nahe, daß das Arbeiten mit ssh schwerer, oder aber zumindest unbequemer ist, als mit den anderen Programmen. In Wirklichkeit ist das aber nicht der Fall. Beim Entwurf der Benutzerschnittstelle wurde von den Erfindern offenbar sehr genau darauf geachtet, ein benutzbares System zu entwerfen. Leider ist die Dokumentation nicht so aufgebaut, daß dies beim ersten Lesen offensichtlich wird.

Zur nochmaligen Motivation, sich mit ssh auseinanderzusetzen: Betrachtet man die Entwicklung des Internets von der Zeit als telnet , rsh etc. entworfen wurden bis heute, so hat es den Weg von einem kleinen Dorf zu einer Millionen Einwohner zählenden Großstadt zurückgelegt. Auf dem Dorf läßt man schon einmal die Tür offen stehen, legt den Schlüssel unter den Teppich oder benutzt den 50 Jahre alten Bartschlüssel. In der Großstadt aber hat jeder ein Sicherheitsschloß, und wird nicht auf die Idee kommen, die Tür auch nur für fünf Minuten offen zu lassen.

Grundlagen

Verbindungsaufbau mit ssh - Funktionalität von telnet und rlogin

$ssh fuhrmann@gate.wias-berlin.de
fuhrmann@gate.wias-berlin.de's password: 
Last login: Wed Mar 27 11:17:51 CET 2002 from nmnb2.wias-berlin.de
$

Wird der Nutzername nicht angegeben, so wird der Nutzername des aktuellen Rechners benutzt. Nur beim ersten Verbindungsaufbau wird eine Zusatzfrage gestellt:

$ssh fuhrmann@gate.mbi-berlin.de
The authenticity of host 'gate.mbi-berlin.de (194.95.11.140)' 
can't be established.
RSA1 key fingerprint is ce:e0:70:ea:7c:d4:e1:77:09:61:bd:0b:28:46:08:6b.
Are you sure you want to continue connecting (yes/no)?

Für den Fall, daß man Zweifel an der Identität des Zielrechners hat, kann man dessen Systemadministrator auf einem anderen Wege, am besten von Angesicht zu Angesicht (wenn man ihn kennt, natürlich, sonst müßte man auch seine Identität überprüfen) nach dem ``RSA1 key fingerprint'' - dem Fingerabdruck des öffentlichen Schlüssels des Zielrechners - fragen, und ihn mit der Angabe von ssh vergleichen. Antwortet man jetzt mit ``yes'', so erhält man die Nachricht

Warning: Permanently added 'gate.mbi-berlin.de,194.95.11.140' 
(RSA1) to the list of known hosts.

Ist die Verbindung einmal aufgebaut, so wird die gesamte Kommunikation verschlüsselt abegwickelt. Dazu wird als erstes im Dialog zwischen Ausgangs- und Zielrechner ein Sitzungsschlüssel generiert, mit dem die weitere Kommunikation verschlüsselt wird.

Dateikopie mit scp - Funktionalität von rcp und ftp

Beispiel: Kopieren von daten.dat vom Zielrechner auf den Ausgangsrechner:

scp fuhrmann@weyl.wias-berlin.de:/home/unix/3dbe/fuhrmann/daten.dat daten.dat
scp fuhrmann@weyl.wias-berlin.de:daten.dat .

Beispiel: Kopieren von daten.dat vom Ausgangsrechner auf den Zielrechner:

scp daten.dat fuhrmann@weyl.wias-berlin.de:/home/unix/3dbe/fuhrmann/daten.dat
scp daten.dat fuhrmann@weyl.wias-berlin.de:

Letztere Version setzt voraus, daß das Home-Verzeichnis von fuhrmann auf weyl.wias-berlin.de /home/unix/3dbe/fuhrmann ist. Man kann auch die Nutzernamen weglassen, wenn diese auf Ausgangs- und Zielrechner gleich sind. Mehr Informationen zur Syntax finden sich unter man scp.

Falls keine andere Authentifizierungsmethode gewählt wurde, wird bei jedem Aufruf von scp nach dem Paßwort gefragt.

Kommandoausführung mit ssh - Funktionalität von rsh

ssh fuhrmann@weyl.wias-berlin.de ls

ssh -t fuhrmann@weyl.wias-berlin.de  emacs -nw

Sichere X11 -Fenster

Hat man sich mit ssh verbunden und ist X11 -forwarding aktiviert, erzeugt ssh ein Pseudo-display auf dem Zielrechner und setzt die Umgebungsvariable entsprechend. Die X11 -Daten werde von der ssh verschlüsselt weitergeleitet, und das Fenster erscheint auf dem Ausgangsrechner.

Beispiel xxx:

Identitäten und Agenten

ssh stellt eine auf asymmetrischer Verschlüsselung beruhende Alternative zur Verfügung.

Mit dem Kommando ssh-keygen kann man sich ein eigenes Paar aus öffentlichem und privatem Schlüssel generieren, und in einem Paar von Dateien abspeichern. Beispiel:

$ssh-keygen
Generating public/private rsa1 key pair.
Enter file in which to save the key (/home/fuhrmann/.ssh/identity): mykey       
Enter passphrase (empty for no passphrase):*************** 
Enter same passphrase again:***************
Your identification has been saved in mykey.
Your public key has been saved in mykey.pub.
The key fingerprint is:
5c:23:da:14:00:c6:6f:3f:6d:2d:69:26:e2:9c:60:b0 fuhrmann@nmnb2
$ls -l mykey*
-rw-------    1 fuhrmann users         529 Apr  2 22:24 mykey
-rw-r--r--    1 fuhrmann users         333 Apr  2 22:24 mykey.pub

Der öffentliche Schlüssel in mykey.pub kann getrost an alle weitergeben werden - dabei ist darauf zu achten, daß man dem Partner bekannt ist oder dieser eine Chance hat, die eigene Identiät als Person festzustellen. Die Nutzung des privaten Schlüssels ist nur nach Angabe der Paßphrase möglich, die komplexer sein sollte, als ein übliches Paßwort. Keinesfalls sollte auf sie verzichtet werden (wie in der Frage suggeriert wird).

Hinterlegt man nun den öffentlichen Schlüssel auf dem Zielrechner in der Datei $HOME/.ssh/authorized_keys, so ist es möglich, anstelle der Abfrage des Systempaßworts die durch ein Schlüsselpaar definierte Identität zur Authentifizierung einzusetzen. Zu diesem Zweck wird der Schalter -i der ssh eingesezt, oder aber der Schlüssel in der Dateien $HOME/.ssh/identity, $HOME/.ssh/identity.pub abgelegt.

Beispiel:

$ssh -i .ssh/fuhrmann@nmnb2.wias-berlin.de gate.wias-berlin.de
Enter passphrase for RSA key 'fuhrmann@nmnb2': 
Last login: Tue Apr  2 22:05:35 CEST 2002 from pec-56-32.tnt3.b2.uunet.de
%

Diese Vorgehensweise ist aber immer noch nicht ``bequem'': anstelle der Systempaßwortabfrage muß jetzt jedes Mal die Paßphrase angegeben werden. Die Nutzung des Authentifizierungsagenten ssh-agent löst jedoch dieses Problem. Es ist allerdings etwas gewöhnungsbedürftig, wie er in Gang zu setzen ist. Dies kann beispielsweise wie folgt geschehen:

$ssh-agent xterm
$ssh-agent tcsh

SSH_AGENT_PID=1398
SSH_AUTH_SOCK=/tmp/ssh-XXTSuTUg/agent.1330

exec ssh-agent twm

Mit dem Kommando ssh-add teilt man dem Agenten einen oder mehrere Schlüssel mit, die dann bei ssh-Verbindungen anstelle der über -i angegebenen verwendet werden. Diese werden aktiviert und bleiben aktiv solange das unter ssh-agent gestartete Programm läuft, oder aber bis zum Löschen mit ssh-add -d oder ssh-add -D. ssh-add muß in dem xterm oder der shell ausgeführt werden, welches mit ssh-agent gestartet wurde.

Beispiel:

$ssh-add .ssh/fuhrmann\@nmnb2.wias-berlin.de     
Need passphrase for .ssh/fuhrmann@nmnb2.wias-berlin.de
Enter passphrase for fuhrmann@nmnb2 
Identity added: .ssh/fuhrmann@nmnb2.wias-berlin.de (fuhrmann@nmnb2)

Danach ist alles einfach. Anstelle der Angaben über ssh -i oder $HOME/.ssh-identity wird die dem Agenten mitgeteilte Identität verwendet, und mehr noch, diese ist bereits aktiviert, d.h. das Kommando

ssh fuhrmann@gate.wias-berlin.de

Tunnel

Hier ist wieder ein kurzer Exkurs in ``höheres UNIX'' nötig. Ein Rechner im Netz hat nicht nur einen Namen, sondern auch eine ``Telefonnummer'', die sogenannte IP-Adresse. Beim Aufruf eines Rechnernames wird ein ``Nameserver'' angefragt, welche IP-Adresse der Rechner hat, die Verbindung wird schließlich mit Hilfe der Nummer aufgebaut. Wird ein Rechner ``angwählt'', so ist es neben der Angabe der Telefonnummer (IP-Adresse) notwendig, die Nummer der ``Nebenstelle'' anzugeben, deren Dienst verlangt wird. Diese ``Nebenstellennummer'' heißt Portnummer. Normalerweise merkt man die Existenz dieser Nebenstellennumer nicht, denn jedem Dienst (telnet , rsh etc.) ist eine standartisierte Portnummer zugeordnet. Diese Zuordnung ist auf jedem UNIX-Rechner in /etc/services abgelegt. Beispiel (SuSE Linux 7.3):

#
# Network services, Internet style
#
# Note that it is presently the policy of IANA to assign a single well-known
# port number for both TCP and UDP; hence, most entries here have two entries
# even if the protocol doesn't support UDP operations.
#
# This list could be found on:
#            http://www.isi.edu/in-notes/iana/assignments/port-numbers
#
#                 0/tcp    Reserved
#                 0/udp    Reserved
tcpmux            1/tcp                 # TCP Port Service Multiplexer
tcpmux            1/udp                 # TCP Port Service Multiplexer
compressnet       2/tcp                 # Management Utility
compressnet       2/udp                 # Management Utility
...
ftp-data         20/tcp                 # File Transfer [Default Data]
ftp-data         20/udp                 # File Transfer [Default Data]
ftp              21/tcp                 # File Transfer [Control]
fsp              21/udp                 # UDP File Transfer
ssh              22/tcp                 # SSH Remote Login Protocol
ssh              22/udp                 # SSH Remote Login Protocol
telnet           23/tcp                 # Telnet
telnet           23/udp                 # Telnet
...
finger           79/tcp                 # Finger
finger           79/udp                 # Finger
http             80/tcp                 # World Wide Web HTTP
http             80/udp                 # World Wide Web HTTP
www              80/tcp                 # World Wide Web HTTP
www              80/udp                 # World Wide Web HTTP
www-http         80/tcp                 # World Wide Web HTTP
www-http         80/udp                 # World Wide Web HTTP
...

Eine Funktionalität von ssh ist nun die Portweiterleitung (port forwarding, tunneling). Man kann sich das als die vom Zielrechner Z vermittelte Schaltung einer Leitung zwischen einer Nebenstelle a des Ausgangsrechners A und einer Nebenstelle d eines dritten Rechners D vorstellen. Rückübersetzt heißt das, daß Port d von D an Port a von A weitergeleitet wird. Das Kommando dazu lautet:

ssh -L a:D:d Z

Beispiel xxx:

Windows Client

Beispiel WIAS/MBI Berlin: gate ohne home-Verzeichnisse

Konfigurationsbeschreibung auf Ausgangsrechner in $HOME/.ssh/config.

#alle nachfolgenden Kommandos gelten für gate.
Host gate.wias-berlin.de
## Tunnel für ssh-Port 22 von über gate nach hilbert, lokal auf Port 7001
LocalForward 7001 hilbert.wias-berlin.de:22
## Tunnel für ssh-Port 22 von über gate nach weyl, lokal auf Port 7002
LocalForward 7002 weyl.wias-berlin.de:22
##Default: Kompression (für Modemverbindung)
Compression yes
## Benutze Port 7001 (anstelle von 22) bei ssh localhost
Host localhost 
Port 7001

Herstellen der Internetverbindung Aufbau eines Tunnels zu gate.wias-berlin.de (Systempaßwortabfrage von gate)

$ssh gate.wias-berlin.de

Verbindung mit hilbert über Tunnel:

$ssh localhost

Verbindung mit weyl über Tunnel:

$ssh -p 7002 localhost

Falls wie oben beschrieben mit Identitäten (auf hilbert in $HOME/.ssh/authorized:keys angeben) gearbeitet wird, fällt die Paßwortabfrage etc. weg.

Arbeiten mit CVS.

CVS_RSH=rsh
CVSROOT=:ext:user@hilbert.wias-berlin.de:/home/unix/darcy/cvsroot
.rhosts-Eintrag 
(Wie früher, aber ohne CVS_SERVER setzen zu müssen).

Außerhalb des WIAS: Tunnelkonfiguration wie oben

CVS_RSH=ssh
CVSROOT=:ext:user@localhost:/home/unix/darcy/cvsroot

#!/bin/sh
exec ssh -p 7001 $*