ssh (Shell-Befehl)

Der Shell-Befehl ssh (secure shell) ist ein SSH-Client und Teil des Pakets Openssh, welches unter anderem auch den SSH-Server sshd enthält. Das Paket Openssh bietet alles, was für verschlüsselte Verbindungen über das Netzwerkprotokoll Secure Shell / SSH benötigt wird.

Programm	Funktion
ssh	(secure shell) Der Openssh-Client baut verschlüsselte Verbindungen zu entfernten Rechnern auf und führt bei Bedarf auch direkt Befehle aus.
scp	(secure copy) Nicht-interaktives Kopieren von Dateien lokal, zu oder von entfernten Rechnern.
sftp	(secure FTP) Der Openssh-FTP-Client ermöglicht interaktives Kopieren, Verzeichniswechsel und -auflistung, die Änderung von Zugriffsrechten, das Löschen von Verzeichnissen und Dateien usw.
sshd	(secure shell daemon) Der Openssh-Server "sshd" ist als Daemon implementiert und lauscht üblicherweise auf Port 22. Die Clients bauen Verbindungen mit diesem Server auf.
ssh-keygen	Erstellen und Umwandeln von SSH-Schlüsseln.
ssh-keysign	Hilfsprogramm, das bei der rechnerbasierten Authentifizierung eingesetzt wird.
ssh-keyscan	Anzeige öffentlicher Rechnerschlüssel und Anhängen in die Datei "~/.ssh/known_hosts".
ssh-agent	Verwaltung privater SSH-Schlüssel und Vereinfachung des Umgangs mit Passwörtern.
ssh-add	Dieses Werkzeug macht den Openssh-Agenten "ssh-agent" mit neuen Schlüsseln bekannt.

Der Openssh-Client "ssh" ist in den meisten Linux-Distributionen bereits vorinstalliert, während der Openssh-Server "sshd" (aus dem Paket "openssh") meist nachträglich eingerichtet werden muss, falls von anderen Rechnern aus auf den lokalen Rechner zugegriffen werden soll.

Grafische Oberflächen: Cxsshadminn, kssh, Putty, Secpanel, Sshterm (kommerziell)

autossh überwacht bestehende SSH-Verbindungen und baut sie nach einem Zusammenbruch automatisch neu auf.

Funktionsweise

Auf einem entfernten Rechner läuft der SSH-Server "sshd". Er lauscht standardmässig an TCP-Port 22 auf eingehende Verbindungen. Der SSH-Client "ssh" verbindet sich mit dem Server auf diesem Port. Beim Verbindungsaufbau geschieht im Hintergrund folgendes, was mit dem Befehl "ssh -vvv" detailliert mitverfolgt werden kann.

1. SSH-Server und SSH-Client verhandeln, welche Protokollversion sie für die Kommunikation verwenden - zur Zeit stehen die Varianten SSH 1 und SSH 2 zur Verfügung, wobei SSH 2 viel sicherer und seit einiger Zeit als Standard eingestellt ist.

2. SSH-Server und SSH-Client handeln den Verschlüsselungsalgorithmus aus.

3. SSH-Server und SSH-Client handeln den Schlüssel aus, den beide für diesen Datentransfer verwenden. Der Schlüssel gilt einmalig für diese Kommunikation und beide vernichten ihn nach dem Verbindungsende. Für längere Verbindungen ändert sich der Schlüssel zusätzlich in regelmässigen Abständen, standardmässig stündlich.

Beim ersten Login kennt der SSH-Client den Rechnerschlüssel des Servers noch nicht und verlangt deshalb eine Bestätigung vor der Verbindungsaufnahme.

The authenticity of host 'myhost (10.0.1.100)' can't be established.
RSA key fingerprint is 1e:f0:39:0d:g6:c0:6e:d9:f4:32:ed:ef:6f:d6:74:cb.
Are you sure you want to continue connecting (yes/no)? 

Erst nach einer Bestätigung dieser Frage mit "yes" importiert das der SSH-Client den sogenannten Fingerabdruck (engl. fingerprint) in die Datei "~/.ssh/known_hosts". Ändert sich der Rechnerschlüssel, so verweigert der SSH-Client bei einer späteren Anmeldung die Verbindungsaufnahme ("WARNING: Remote host identicfication has changed!"). Dafür kann es mehrere Gründe geben.

• Böswillige Absicht bzw. ein Man-in-the-middle-Angriff: Ein Dritter versucht sich zwischen zwei Verbindungspartner zu stellen und dadurch die Kontrolle über den gesamten Datenverkehr zu übernehmen. Er kann so Informationen nach Belieben ansehen oder sogar verändern.
• Der Systemverwalter hat den Schlüssel nicht geändert oder das System neu installiert.

Hier hilft nur, den betreffenden Fingerabdruck aus der Datei "~/.ssh/known_hosts" zu löschen und den neuen Schlüssel zu akzeptieren. Dieses Verhalten wird über die Variable "StrictHostKeyChecking" in der SSH-Client-Konfigurationsdatei "ssh_config" konfiguriert.

Public-Key-Authentication

Die Public-Key-Authentication kann verwendet werden, um das Passwort nicht jedesmal eingeben zu müssen. Diese passwortfreie Anmeldung kommt oft beim automatisierten Kopieren von Dateien auf einen entfernten Zielrechner zum Einsatz.

1. Mit "ssh-keygen" wird ein RSA-Schlüsselpaar von 1024 Bit Länge generiert. Ein RSA-Schlüssel eignet sich für beide SSH-Protokollversionen. Die Schlüssellänge sollte aus Sicherheitsgründen 1024 Bit nicht unterschreiten.

$  ssh-keygen -b 1024 -t rsa

2. Die Software meldet daraufhin, dass sie ein Schlüsselpaar mit einem öffentlichen und einem privaten Schlüssel nach dem RSA-Verfahren erzeugt hat.

3. Die Abfrage nach dem Passwort wird zweimal mit RETURN bestätigt (es wird also kein Passwort eingegeben).

4. Das Programm sagt nun, in welchen Dateien es die Daten ablegt und zeigt den Fingerabdruck des neuen Schlüssels an.

5. Nun wird der öffentliche Schlüssel auf den Zielrechner geschafft und dort in die Datei "~/.ssh/authorized_keys" kopiert.

$ cat id_rsa.pub >> ~/.ssh/authorized_keys

Unter Putty kann der private Schlüssel mit dem Programm "puttygen.exe" in eine Form überführen, die auch Putty verstehen kann. Dazu wird der private Schlüssel (also die Datei "id_rsa") nach Microsoft Windows übertragen, dort "puttygen.exe" gestartet, der private Schlüssel importiert und einfach wieder abgespeichert. Anschliessend kann die so erzeugte Datei in Putty für die Benutzung über das Menü "SSH > Auth" angegeben werden.

Weitere Einzelheiten dazu finden sich in den Manpages zu "ssh", "ssh-keygen", "ssh-agent" und "ssh-add".

Schlüssel

Während der Installation von Openssh werden öffentliche und private Schlüssel für den lokalen Rechner angelegt, die je nach der Methode der Verschlüsselung (DSA, RSA) in verschieden benannten Dateien liegen.

• Der öffentliche Schlüssel (engl. public key) kann an jeden beliebigen Rechner verteilt werden, von dem aus eingeloggt werden können soll.
• Der private Schlüssel (engl. private key) muss geheim bleiben!

DSA	Öffentlicher Schlüssel	Privater Schlüssel
Benutzer "root"	/etc/ssh/ssh_host_dsa_key.pub	/etc/ssh/ssh_host_dsa_key
unprivilegierter Benutzer	~/.ssh/id_dsa.pub	~/.ssh/id_dsa
RSA	Öffentlicher Schlüssel	Privater Schlüssel
Benutzer "root"	/etc/ssh/ssh_host_rsa_key.pub	/etc/ssh/ssh_host_rsa_key
unprivilegierter Benutzer	~/.ssh/id_rsa.pub	~/.ssh/id_rsa

Tunnel

Gemäss der Vorgabe dürfen nur Programme den Tunnel nutzen, die auf demselben Rechner laufen. Um auch anderen Rechnern im Netz den Tunnel zur Verfügung zu stellen, wird dem Befehl beim Aufbau des Tunnels der Parameter "-o GatewayPorts=yes" mitgegeben. Alternativ dazu kann die Option in der Konfiguratiunsdatei "ssh_config" gesetzt werden.

Der Vorgang ähnelt einer VPN-Verbindung, lässt sich aber einfacher verwirklichen. Die SSH-Variante hat allerdings den Nachteil, dass immer nur ein einzelner TCP-Port weitergeleitet wird. Es werden also genausoviele SSH-Tunnels benötigt, wie Ports weitergeleitet werden sollen.

Tunnel darf grundsätzlich jeder Benutzer aufbauen, solche für privilegierte Ports (mit Nummern unter 1024) sind jedoch dem Benutzer "root" vorbehalten.

Verbindungsdaten speichern

Mit Hilfe der Konfigurationsdatei "~/.ssh/config" können für jeden Benutzer alle Einstellungen zu einer Verbindung gespeichert und später wieder aufgerufen werden. Diese Datei wird auch von den anderen Shell_befehlen aus dem Openssh-Paket verwendet, also sowohl von ssh wie auch von scp.

Die Datei beginnt mit allgemeinen Einstellungen für alle Sitzungen.

• "PreferredAuthentications" legt fest, dass Openssh versuchen soll, zuerst eine Anmeldung per Public Key auszuhandeln und es danach mit einem Passwort zu probieren, ohne andere Methoden einzuschieben. Die übrigen Zeilen im folgenden Beispiel schalten weitere Anmeldemethoden ab, um nutzlose Versuche zu vermeiden.

Danach folgen die Einstellungen für einzelne Sitzungen.

• "Host" leitet eine Sitzung ein. Der Eintrag kann den Namen des Rechners enthalten, auch mit den Platzhaltern Stern ("*") und Fragezeichen ("?"), oder einen beliebigen Kurznamen. In letzterem Fall wird der zu kontaktierende Rechner dann mit dem Eintrag "HostName" bestimmt.
• "Port" legt die Portnummer auf dem zu kontaktierenden Rechnere fest.
• "Protocol" legt die Version des SSH-Protokolls auf dem zu kontaktierenden Rechnere fest.
• "Compression" legt die für langsame Verbindungen zu empfehlende Kompression fest.
• "Port" legt die Portnummer auf dem zu kontaktierenden Rechnere fest.
• "LocalForward" legt einen gesicherten Tunnel fest.
• "CheckHostIP" setzt eine Option, für die es keinen Befehlszeilenschlater gibt: Der ssh-Client prüft beim Verbinden nicht, ob die IP-Adresse des Rechners dieselbe ist, die in der Datei "~/.ssh/known_hosts" gespeichert ist. Das ist für Rechner mit dynamischer IP-Adresse wichtig, da Openssh sonst bei jeder Änderung die neue IP-Adresse zusätzlich in die Datei "known_hosts" einträgt und diese so unnötig aufbläht.
• "ForwardX11" legt das X-Forwarding fest und entspricht der Befehlszeilenoption "-X".

# Beispieldatei "config"

# Allgemeine Einstellungen für alle Sitzungen
PreferredAuthentications publickey,password
PubkeyAuthentication yes
ChallengeResponseAuthentication no
HostbasedAuthentication no
KerberosAuthentication no
RhostsAuthentication no

# Zuhause
# entspricht dem folgenden ssh-Befehl:
# $ ssh -p 56509 -2 -C -L 49580:127.0.0.1:80 sshhost.dyndns.org
# dieser Aufruf lässt sich damit verkürzen auf:
# $ ssh zuhause
# $ scp zuhause:file.txt .
Host zuhause
HostName sshhost.dyndns.org
Port 56509
Protocol 2
Compression yes
LocalForward 49580 127.0.0.1:80
CheckHostIP no

# Sourceforge Shell
Host *.sourceforge.net
User sfname
Protocol 1
PasswordAuthentication no
IdentityFile /home/mik/.ssh/sourceforge.key
Compression yes
ForwardX11 no

Konfiguration

Die Konfigurationsdatei für den Openssh-Server heisst "/etc/ssh/sshd_config".

Die Konfigurationsdatei für den Openssh-Client heisst "/etc/ssh/ssh_config". Benutzerbezogene Einstellungen können in der Datei "~/.ssh/config" gemacht werden. Die Befehlszeile kennt auch sämtliche in diesen Konfigurationsdateien möglichen Optionen.

Falls kein Openssh-Daemon läuft, muss in der Datei "/etc/rc.config" der Schalter für ssh aktiviert werden. Auf der eigenen Seite der Verbindung muss dann nur noch ssh aufgerufen werden, wobei natürlich die IP-Adresse des fernen Rechners sowie eine gültige Benutzerkennung bekannt sein müssen.

Verwendung

Anmeldung als Benutzer "xyz" auf dem entfernten Rechner "remotehost".

$ ssh xyz@remotehost
oder
$ ssh remotehost -l xyz

Anmeldung als Benutzer "xyz" auf dem entfernten Rechner "remotehost" und direkter Aufruf des Befehls "pwd" (anstatt einer Login-Shell). Alles was nach dem Rechnernamen auf der Befehlszeile steht, wird von ssh als Befehl betrachtet, der auf dem entfernten Rechner ausgeführt werden soll. Die SSH-Verbindung endet nach der Ausführung dieses Befehls automatisch.

$ ssh xyz@remotehost pwd

Drucken der lokalen Datei "file.ps" mit lpr als Benutzer "xyz" über den entfernten Rechner "remotehost".

$ cat file.ps | ssh xyz@remotehost lpr

Prüfen, ob auf dem Rechner ein ssh-Daemon läuft.

$ ps -ef | grep ssh
$ netstat -an | grep 22

Manchmal beendet ssh die Verbindung nicht, obwohl man sich auf dem entfernten Rechner abgemeldet hat. Dann hilft die Tastenkombination "~." (Tilde Punkt), die ein Verbindungsende erzwingt.

Mit "~#" (Tilde Raute) werden alle aktuell durch SSH-Tunnel geleiteten Verbindungen angezeigt.

"~?" (Tilde Fragezeichen) zeigt die Online-Hilfe für alle Tilden-Befehle.

Tunnel

Aufbau eines Tunnels zum entfernten Rechner "remotehost", wobei der entfernte Port 4000 getunnelt wird und auf dem lokalen Rechner unter Portnummer 4444 erreichbar gemacht wird.

$ ssh -L 4444:remotehost:4000 remotehost

Aufbau eines Tunnels zum entfernten Rechner "remotehost" über den Rechner "relayhost", wobei der entfernte Port 4000 getunnelt wird und auf dem lokalen Rechner unter Portnummer 4444 erreichbar gemacht wird.

$ ssh -L 4444:relayhost:4000 remotehost

Doppelte Portweiterleitung eines Ports von Rechner "zicke" via Rechner "panda" auf Rechner "emu". Im Anschluss daran können auf dem lokalen Rechner die folgenden URLs aufgerufen werden:

• http://localhost:58080/
• http://panda:7070/
• http://zicke:8080/

mik@emu:~> ssh -C -g -L 58080:panda:7070 sisis@panda
sisis@panda:~> ssh -C -g -L 7070:zicke:8080 sisis@zicke
Password:
sisis@zicke:~>

Portweiterleitung von zwei Ports des Rechners "zicke" auf Rechner "emu". Im Anschluss daran können azf dem lokalen Rechner folgende URLs aufgerufen werden:

• https://localhost:50443/
• http://localhost:58080/
• https://zicke:443/
• http://zicke:8080/

mik@emu:~> ssh -C -g -L 50443:zicke:443 -L 58080:zicke:8080 sisis@zicke
Password:
sisis@zicke:~>

Auf dem entfernten Rechner "remotehost" läuft ein Proxy auf Port 3128, der für transparentes Proxying konfiguriert ist. Alle HTTP-Anfragen werden dann wie folgt umgeleitet.

$ ssh -o GatewayPorts=yes -L 80:remotehost:3128 remotehost

Das Tunneln funktioniert auch in umgekehrter Richtung. Mit dem folgenden Befehl wird ein Tunnel vom entfernten Rechner "remotehost" zum lokalen Rechner "localhost" aufgebaut.

$ ssh -o GatewayPorts=yes -R 3128:localhost:80 remotehost

Grafische Tunnel

Um das X Window System zu tunneln, emuliert der Openssh-Daemon "sshd" einen X11-Server und besetzt ein Display, standardmässig die Nummer 11. Wenn man sich auf dem Server einwählt, setzt dieser die Umgebungsvariable "DISPLAY" auf diesen Wert, genauer gesagt auf "localhost:11.0", um Kollisionen mit dem lokal laufenden X-Server zu verhindern. Alle Daten, die ein Rechner an dieses Display sendet, wandern verschlüsselt zum lokalen Rechner.

Zum Aktivieren des X11-Forwarding muss in der Server-Konfigurationsdatei "/etc/ssh/sshd_config" die Variable "X11Forwarding yes" gesetzt sein. Die Variable "X11DisplayOffset 10" bestimmt ausserdem den Abstand des virtuellen Displays zum realen Display. Zusätzlich muss auf dem Rechner, der das getunnelte X11 anzeigen soll in der Client-Konfigurationsdatei "/etc/ssh/ssh_config" ebenfalls die Variable "X11Forwarding yes" gesetzt sein.

Anmelden auf dem entfernten Rechner "10.0.5.5" mit X-Weiterleitung. Danach können auf dem Zielrechner grafische Programme aufgerufen werden, deren Programmfenster auf dem lokalen Desktop erscheinen. Durch die aufgeführten Befehle werden auch die Belegung der Variable "DISPLAY", der Prozess und die Netzwerkverbindungen angezeigt.

$ ssh -X abc@10.0.5.5
abc@10.0.5.5$ xclock &
[1] 6788
abc@10.0.5.5$ echo $DISPLAY
localhost:10.0
abc@10.0.5.5$ ps aux | grep xclock | grep -v grep
sisis     6788  0.3  0.5  5048 2872 pts/1    S    16:12   0:00 xclock
abc@10.0.5.5$ netstat -tpn | grep xclock
tcp        0      0 127.0.0.1:32867         127.0.0.1:6010          VERBUNDEN   6788/xclock

Weblinks

Herausgeber	Sprache	Webseitentitel	Anmerkungen