SSH
K (→Sichere passwortlose Logins mit SSH) |
|||
Zeile 4: | Zeile 4: | ||
Für automatisierte Vorgänge (z.B. Backupskripte) können auch passwortlose Schlüssel erzeugt werden. | Für automatisierte Vorgänge (z.B. Backupskripte) können auch passwortlose Schlüssel erzeugt werden. | ||
− | (Passwortlose) Logins können auf dem Zielsystem | + | (Passwortlose) Logins können auf dem Zielsystem in der authorized_keys entsprechend eingeschränkt werden. |
no-pty,no-port-forwarding,no-X11-forwarding,no-agent-forwarding,permitopen="192.168.8.2:80" ssh-dss AAAAB3... | no-pty,no-port-forwarding,no-X11-forwarding,no-agent-forwarding,permitopen="192.168.8.2:80" ssh-dss AAAAB3... | ||
Zeile 14: | Zeile 14: | ||
* [http://www.blisstonia.com/eolson/notes/smboverssh.php Samba/CIFS/SMB file systems over SSH] | * [http://www.blisstonia.com/eolson/notes/smboverssh.php Samba/CIFS/SMB file systems over SSH] | ||
* [http://sites.google.com/site/caughron/ ssh-rekey] (mal näher anschauen) | * [http://sites.google.com/site/caughron/ ssh-rekey] (mal näher anschauen) | ||
− | |||
===SSH-Key erzeugen=== | ===SSH-Key erzeugen=== |
Version vom 21. November 2010, 13:09 Uhr
Inhaltsverzeichnis |
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,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.
Mit ssh-keygen -t rsa erzeugt man 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. Ohne Option -i wird dabei ~/.ssh/id_rsa.pub als identity_file verwendet.
Sonderfall: abweichender Port des SSH-Servers
Mit ssh-copy-id '[-i [identity_file]] [-p [port]] [user@]machine' 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'
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.