ssh (Shell-Befehl)

Der Shell-Befehl ssh (secure shell) ist ein SSH-Client und Teil des Pakets Openssh, das 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: Cxsshadmin, Gnome SSH Tunnel Manager / GSTM, kssh, Putty, Secpanel, Sshterm (kommerziell), Tunnel Manager

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 am angegebenen Ort erzeugt (standardmässig unter "~.ssh/id_rsa" bzw. "~.ssh/id_rsa.pub").

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 (also die Datei "id_rsa.pub") 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ührt werden, 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". Die Befehle "ssh-agent" und "ssh-add" erlauben unter Unix, den privaten Schlüssel so anzumelden, dass die Passphrase nur einmal angegeben werden muss und bei Benutzung durch SSH nicht jedesmal danach gefragt wird.

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.

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.

Anmeldung als Linux-Benutzer "root"

Die Konfiguration erfolgt über den Parameter "PermitRootLogin". Die Optionen sind:

• yes: Erlauben
• no: Verbieten
• prohibit-password: Verbieten aller interaktiven Anmeldearten (z. B. mit Passwort) - erlaubt sind weiterhin die Anmeldung über einen öffentlichen Schlüssel, die rechnerbasierte Anmeldung sowie die GSSAPI-Authentifizierung

Erzwungene Befehle

In Verbindung mit einem Schlüsselpaar können fest bestimmte Befehle irgendwo im Rechnernetz ausgeführt werden, ohne dass das Benutzerkonto für andere Zwecke offen ist.

Der öffentliche Schlüssel liegt bei der Public Key-Authentifizierung in der Datei "~/.ssh/authorized_keys" auf dem Rechner, auf dem die Anmeldung stattfindet. Jede Zeile dieser Datei enthält einen einzelnen öffentlichen Schlüssel. Jede Zeile eines Schlüssel der SSH-Protokollversion 2 ist einige hundert zeichen lang und besteht aus folgenden Bereichen:

• Optionen
• Schlüsselart (z. B. "ssh-rsa")
• Base64-kodierter Schlüssel
• Kommentar

Bei einem neu erzeugten Schlüssel ist das Optionenfeld nicht belegt. Um es für einen Schlüssel zu verwenden, werden am Beginn der Zeile, durch Kommas getrennt, die gewünschten Optionen eingesetzt. Hier sind keine Leerzeichen erlaubt, ausser sie stehen innerhalb von Anführungszeichen.

• Mit "from = Host-Muster" lässt sich festlegen, von welchen Rechnern aus sich ein Benutzer mit diesem Schlüssel anmelden darf. Eine Negativauswahl lässt sich mit "!" vor einer Rechnerbezeichnung treffen.
• Mit "command=Befehl" kann ein bestimmter Befehl zur ausschliesslichen Ausführung mittels dieses Schlüssels bestimmt werden.

Im folgenden Beispiel wird in jedem Fall ausschliesslich der Befehl "dump /home" ausgeführt - interaktive Logins sind also nicht möglich. Die weiteren Parameter "no-pty,no-port-forwarding" verhindern, dass der Befehl in einem Pseudoterminal (PTY) läuft oder dass der SSH-Client TCP-Ports umleitet.

command="dump /home",no-pty,no-port-forwarding 1024 33 23...2323 backup.hut.fi

Selbstverständlich lassen sich auch weitere SSH-Befehle mit einem Schlüssel verbinden. Dieser Mechanismus ist praktisch, wenn ein Rechner (hier "tux") nicht direkt, sondern nur per Umweg über einen anderen Rechner. Das ist häufig beim Anmelden auf einen Rechner hinter einer Firewall der Fall: Ist auf dem Proxy-Rechner der öffentliche Schlüssel installiert, so verbindet dessen "sshd" den Client problemlos weiter zu seinem eigentlichen Ziel. Dort muss ebenfalls ein gültiger öffentlicher Schlüssel liegen. Die zugehörigen privaten Schlüssel bleiben beim Client. Durch dieses Verfahren sind die Rechner im lokalen Rechnernetz erreichbar, trotz Firewall und ohne einen eigenen Port nach innen zu öffnen.

command="ssh -A -2 -1 abc tux" ssh-dss AAAB3N...KElw== abc@vaio

Für regelmässig durchgeführte Aufgaben wie z. B. unbeobachtet arbeitende Cronjobs bieten schlüsselbezogene erzwungene Befehle ein weites Eingabefeld. Ihr Zugriff soll ja gerade auf eine genau begrenzte Aufgabe eingeschränkt werden. Die auszuführenden Befehle können natürlich auch eigene Skripte sein. Achtzugeben ist bei Befehlen (z. B. vi), welche die Möglichkeit eines Shell-Escape bieten.

Im folgenden Beispiel erhält der Benutzer keine Shell angeboten, stattdessen wird die Verbindung nach zwei Stunden automatisch abgebaut - der SSH-Zugang ist so nur noch für das Portforwarding geeignet. Mit der Option "permitopen" kann das Portforwarding auf einen bestimmten Rechner und einen bestimmten Port eingeschränkt werden (hier "localhost:5910").

command="/bin/sleep 2h",permitopen="localhost:5910" ssh-dss AAAB3N...KElw== abc@vaio

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 und sftp. Die Werte in der Konfigurationsdatei wwerden der Reihe nach abgearbeitet, für jeden Parameter wird jeweils nur der erste Treffer genommen. Aus diesem Grunde stehen die Standardwerte am Dateiende unter "Host *" - die Einstellungen, die nur für einzelne Rechner gelten, stehen davor. Eine DNS-Auflösung findet hier aus Sicherheitsgründen nicht statt.

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, alle danach folgenden Anweisungen gelten nur für den genannten Zielrechner. 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 abc@sshhost.dyndns.org
# dieser Aufruf lässt sich damit verkürzen auf:
# $ ssh abc@zuhause
# $ scp abc@zuhause:file.txt .
Host zuhause
  HostName sshhost.dyndns.org
  Port 56509
  Protocol 2
  LocalForward 49580 127.0.0.1:80
  CheckHostIP no
  User abc

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

# Standardwerte
Host *
  StrictHostKeyChecking yes
  Compression yes
  Ciphers blowfish-cbc

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

FAQ

Verbindung "friert ein"

Falls die SSH-Verbindung nach einer Weile des Nichtstuns "einfriert, so kann die Aktivierung folgender Parameter helfen:

• ClientAliveInterval in der Datei "sshd_config"
• ServerAliveInterval in der Datei "ssh_config"

Die eingestellte Zeit sollte kürzer sein als es üblicherweise bis zum "Einfrieren" dauert.

ssh hängt bei "debug2: ssh_connect: needpriv 0"

Meist hat das Problem mit DNS zu tun und tritt nicht mehr auf, wenn ein Rechner anstatt über seinen DNS-Namen direkt über seine IP-Adresse angesprochen wird.

In meinem Fall wurde der lästige Hänger durch Einfügen der folgenden Zeile in die Datei "ssh_config" behoben.

# vi /etc/ssh/ssh_config
AddressFamily inet

Siehe auch http://linuxnshell.blogspot.ch/2015/02/debug2-sshconnect-needpriv-0-stuck-fix.html

Weblinks

Herausgeber	Sprache	Webseitentitel	Anmerkungen
Ubuntu Users	ger	SSHwbm
Universität Innsbruck	ger	SSH public key-Authentifizierungwbm
Waikato Linux Users Group	eng	SSH errorswbm
Wikipedia	ger	Secure Shellwbm	Enzyklopädischer Artikel
O'Reilly	eng	SSH: the secure shell : the definitive guidewbm	Autor: Daniel J. Barrett, Richard E. Silverman. - 1st edition (2001)
Berthold Cogel	ger	Passwortlose Logins mit SSHwbm
Johannes Franken	ger	Openssh, Teil1: Grundlagenwbm
Johannes Franken	ger	Openssh, Teil2: SSH-Tunnelswbm
Johannes Franken	ger	Openssh, Teil3: Firewalls durchbohrenwbm

• http://www.linuxjournal.com/content/use-sshconfig-simplify-your-life
• https://help.ubuntu.com/community/SSH/OpenSSH/PortForwarding