SSH

Version vom 21. November 2010, 14:56 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.

• 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
    Compress 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.