SSH

Version vom 28. Mai 2011, 19:30 Uhr

Sichere passwortlose Logins mit SSH

Für ein passwortloses Login wird ein SSH-Key benötigt. Der Public-Key muß dazu auf das Zielsystem in die Datei ~/.ssh/authorized_keys kopiert werden. Der Privat-Key verbleibt beim SSH-Client und sollte mit einer Passphrase gesichert sein.

Für automatisierte Vorgänge (z.B. Backupskripte) können auch passwortlose Schlüssel erzeugt werden. (Passwortlose) Logins können auf dem Zielsystem in der authorized_keys entsprechend eingeschränkt werden.

no-pty,no-port-forwarding,command="./backup.sh",from="backupserver.meine-domain.de" ssh-dss AAAAB3...

Startet das Backupskript nur, wenn die Verbindung vom Backupserver kommt.

no-pty,no-port-forwarding,no-X11-forwarding,no-agent-forwarding,permitopen="192.168.8.2:80" ssh-dss AAAAB3...

In diesem Falle werden das Öffnen eines Terminals (no-pty), Tunnel (no-port-forwarding) allgemein verboten, jedoch mit permitopen einzelne Tunnel wieder erlaubt.

permitopen="192.168.8.2:80"

... kann mehrfach wiederholt werden.

• SSH ohne Passwort -- Kurze Anleitung zur Nutzung
• SSH und Putty
• SSH-Key-Webgenerator
• Samba/CIFS/SMB file systems over SSH
• ssh-rekey (mal näher anschauen)

SSH-Key erzeugen

Es ist empfehlenswert, den SSH-Key auf einem (lokalen) vertrauenswürdigen System zu erzeugen, da man sich nur so sicher sein kann, daß der private Schlüssel samt Passphase nicht schon beim erzeugen in fremde Hände gelangt.

$ ssh-keygen -t rsa

Erzeugt einen RSA-Schlüssel für Protokollversion 2 mit 2048 Bit Schlüssellänge, welcher dann unter ~/.ssh/id_rsa bzw. ~/.ssh/id_rsa.pub abgelegt wird.

Statt rsa kann auch dsa verwendet werden. Von einigen SSH-Tools wird RSA als Voreinstellung verwendet, bei DSA muß dies dann extra angegeben werden. Welches der beiden Verfahren sicherer ist, kann man nicht allgemeingültig beantworten.

SSH-Key auf entfernten Host übertragen

Üblicherweise überträgt man seinen SSH-Key mit

$ ssh-copy-id [-i [identity_file]] [user@]machine

auf einen entfernten Host. Als identity_file muß immer der public key (*.pub) angegeben werden. Ohne Option -i wird dabei ~/.ssh/id_rsa.pub als identity_file verwendet.

Sonderfall: abweichender Port des SSH-Servers

$ ssh-copy-id '[-i [identity_file]] [-p [port]] [user@]machine'

Damit kann der Port gewählt werden. Wichtig sind die Hochkommas.

Ohne diese erhält man folgende Fehlermeldung:

Bad port 'umask 077; test -d .ssh || mkdir .ssh ; cat >> .ssh/authorized_keys'

Falls ssh-copy-id nicht vorhanden ist geht das auch so:

$ cat [identity_file] | ssh [-p [port]] [user@]machine 'umask 077; test -d .ssh || mkdir .ssh ; cat >>.ssh/authorized_keys'

SSH-Client konfigurieren

Um sich Tipparbeit bei der täglichen Verwendung von ssh zu sparen, kann man die Konfiguration der verschiedenen Hosts, verschiedene Logins zu dem selben Host oder auch allgemeine Optionen für eine Gruppe von Hosts bzw. von der serverweiten Konfiguration abweichende Einstellungen in der ~/.ssh/config ablegen.

Beispiel:

Host ipcop123
    HostName ipcop.irgendwo.de
    Port 222
    User hans
    Compression yes
    ServerAliveInterval 30
    ServerAliveCountMax 120
    # IPcop Webinterface
    LocalForward 10445 localhost:445
    # Terminalserver
    LocalForward 13389 192.168.111.2:3389

Mit ssh ipcop123 wird daraufhin eine SSH-Verbindung zu ipcop.irgendwo.de auf den vom Standard abweichenden Port 222 als Benutzer hans aufgebaut. Die Verbindung wird dabei transparent komprimiert. Damit die Verbindung bei Inaktivität nicht abbricht werden aller 30s Keepalive-Pakete 1 Stunde lang (120 * 30s) versandt. Für das Webinterface des IPcops wird ein Tunnel vom lokalen Port 10445 zum Port 445 des IPcops (localhost aus Sicht des Tunnelendes) sowie ein weiterer Tunnel für eine RDP-Verbindung zum Terminalserver im entfernten Netz aufgebaut.

Agent Forwarding

Mit eingeschaltetem 'Agent Forwarding' kann der private Schlüssel ausschließlich auf dem eigenen Client liegen bleiben und man sich trotzdem mit dem lokalen Schlüssel vom Server aus zum Nächsten verbinden.

~/.ssh/config:

Host MyServer
     ...
     ForwardAgent yes
     ...

Dies verschafft gelegentlich auch eine trügerische Sicherheit. Beim Testen von 'restricted keys', etwa einem passwortlosen Backupschlüssel, wird stattdessen der 'forwarded key' verwendet, der wahrscheinlich keine Restriktionen aufweist. Somit funktioniert der manuelle Test des Backups, aber das Cron-gesteuerte Backup scheitert danach. In dem Falle sollte eine SSH-Verbindung ohne 'Agent Forwarding' verwendet werden.

X11Forwarding

Sollen X11-Sessions per SSH weitergeleitet werden, muß dies auf der Serverseite sowohl in der sshd_config erlaubt sein als auch auf der Clientseite in der Config mit ForwardX11 yes bzw. mit dem Kommandozeilenparameter -X aktiviert werden. Weiterhin muß auf dem Server xauth installiert sein, damit die .Xauthority im Homeverzeichnis angelegt und die DISPLAY-Variable gesetzt wird.