ssh (Shell-Befehl)

Der Shell-Befehl ssh (secure shell) ist ein Programm zur Nutzung des Netzwerkprotokolls Secure Shell / SSH.

Die Programmsammlung Openssh bietet alles, was für verschlüsselte Verbindungen 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, Sshterm (kommerziell)

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

Funktionsweise

Auf einem 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.

1. SSH-Server und -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 -Client handeln den Verschlüsselungsalgorithmus aus

3. SSH-Server und -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.

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.

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".

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".

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.

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 öffentliche Schlüssel des Benutzers "root" findet sich in der Datei "/etc/ssh/ssh_host_dsa_key.pub" bzw. "/etc/ssh/ssh_host_rsa_key.pub"
• Der öffentliche Schlüssel für einen unprivilegierten Benutzer findet sich in der Datei "~/.ssh/id_rsa.pub" bzw. "~/.ssh/id_dsa.pub"

Der private Schlüssel (engl. private key) muss geheim bleiben!

• Der private Schlüssel des Benutzers "root" findet sich in der Datei "/etc/ssh/ssh_host_dsa_key" bzw. "/etc/ssh/ssh_host_rsa_key"
• Der private Schlüssel für einen unprivilegierten Benutzer findet sich in der Datei "~/.ssh/id_rsa" bzw. "~/.ssh/id_dsa"

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).

$ 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

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