Inhalt
Inhaltsverzeichnis
- Übersicht
- Beispiele
- Login mit Key, ohne Passwort
- ssh-agent in der .bashrc
- Sicherstellen, dass sshd immer läuft
- Abwehr von automatisierten Einbruchsversuchen
- Tunnelbau mit ssh
- Zugriffe aus der "Windows"-Welt
- sftp Frontends
- Mounten entfernter Datei-Systeme mit dem shfs
- Wofür ssh nicht gedacht ist
- ssh-keygen Generieren/erzeugen von ssh Keys (RSA1, RSA2 und DSA)
- Tipps + Tricks
- Optionen
- Links
- Fragen
Übersicht
SSH dient dem sicheren Zugriff auf entfernte Rechner. Über SSH kann eine Terminalsitzung oder eine Xsession geöffnet werden, aber auch Daten sicher kopiert werden.
OpenSSH ist eine kompatible, freie OpenSource-Implementierung der originalen ssh (Secure Shell). Man kann damit problemlos telnet, rsh, rcp, ftp und andere veraltete und unsichere Dienste ersetzen oder zusätzlich absichern (siehe auch UnsichereProtokolle).
Homepage: http://www.openssh.com/de/
Lizenz: BSD
Weitere Tools: LUFS und SHFS - Filesystem mounten über SSH
Bestandteile:
- sshd - der OpenSSH-Server-Dämon
- ssh - der OpenSSH-Client
- scp - secure copy
- sftp - ftp-ähnlicher Client
Weitere Bestandteile:
- ssh-add - hinzufügen eines RSA oder DSA Schlüssels zum Authentifizierungsagenten
- ssh-agent - der Authentifizierungsagent
- ssh-askpass - X11 basierter Abfragedialog der Passphrase
- ssh-keygen - Zum generieren von SSH-Keys bzw. zum neugenerieren
- ssh-keyscan -
- ssh-copy-id - Zum kopieren einer ID auf einen anderen Rechner in die Datei authorized_keys (nur Debian ?)
- ssh-argv0 - Um sich das eintippen von 'ssh example.com' zu ersparen;
Einsatzmöglichkeiten:
- Fernwartung / Fernbedienung von Servern
- Kopieren von Dateien zwischen Rechnern
- Ausführen vom Befehlen auf Remote-Rechnern
Vorteil:
- alle Daten (auch das Passwort) werden verschlüsselt übertragen
- man kann auch ohne Passwort mit kryptografischen Schlüsseln arbeiten
- optional: Datenkompression
- bequemes Remote-Ausführen von X11-Applikationen
Beispiele
tw@client:/~ > ssh server Macht einen Login auf den Rechner server unter dem aktuellen Usernamen (hier: tw). Üblicherweise wird dann nach dem Passwort gefragt.
tw@client:/~ > ssh root@server Wie oben, aber als root (oft ist der direkte Login als root aus Sicherheitsgründen abgeschaltet!)
tw@client:/~ > scp root@server:/etc/shadow . Kopiert die shadow vom server in das aktuelle Verzeichnis und benutzt dazu den root-Login auf server
tw@client:/~ > scp -r root@server.example.net:/etc root@backup:/backups/inetserver/etc Kopiert das Verzeichnis /etc von server.example.net auf den Rechner backup nach /backups/inetserver/etc Das ist nur ein Beispiel, in der Praxis wäre hier rsync sicher sinnvoller
wm@client:/~ > ssh mybackuphost "cat - > /home/backup/hda1.bin" </dev/hda1 Kopiert ein Image der Platte /dev/hda1 zu einem Backuphost nach /home/backup/hda1.bin.
wm@client:/~ > tar -cf - foo/bar/ | ssh baz@qux tar -xvf - Kopiert einen ganzen Verzeichnisbaum zu einem anderen Rechner.
wm@client:/~ > ssh -X -f user@server kwrite Startet die Anwendung kwrite auf dem Server und leitet das X-Fenster zum lokalen PC um, dazu muss allerdings die Option X11Forwarding yes in der SSH-Konfig-Datei /etc/ssh/sshd_config gesetzt sein.
Login mit Key, ohne Passwort
Wenn man nicht immer das Passwort beim Login auf Rechner remotehost eintippen will, kann man auch Folgendes machen:
Zuerst braucht man ein Schlüsselpaar, falls man noch keines hat, kann man sich so eines generieren:
localuser@localhost:~ > ssh-keygen -b 2048 -t rsa
Ein vorhandenes Schlüsselpaar wird damit überschrieben.
Das Kommando generiert einen 2048 Bit langen RSA-Key für SSH Protokoll Version 2 - die Standardlänge von 1024 Bit wird nicht mehr als unumstritten sicher betrachtet.
Anmerkung: 2048 Bit ist übrigens nicht doppelt so sicher wie 1024 Bit, sondern 2^1024 mal sicherer (ausgerechnet ist das eine Dezimalzahl mit mehr als 300 Stellen!).
Danach muss man den öffentlichen Schlüssel auf den entfernten Rechner übertragen:
# ssh-copy-id -i .ssh/id_rsa.pub remoteuser@remotehost.example.net
oder (wenn man noch kein ssh-copy-id hat)
remoteuser@remotehost:~ > ssh-keygen -b 2048 -t rsa localuser@localhost:~ > ssh remoteuser@remotehost.example.net \ "umask 077; mkdir -p .ssh; cat >> .ssh/authorized_keys" <.ssh/id_rsa.pub
Die umask dient dazu, dass der ssh-Key den Mode 0600 bekommt, weil sonst der sshd die Datei nicht akzeptiert.
Auf dem Remotesystem wird dann der lokale öffentliche Schlüssel in die Datei ~/.ssh/authorized_keys aufgenommen. Ebenso wird in der lokalen Datei ~/.ssh/known_hosts der öffentliche Schlüssel des Remotesystems aufgenommen.
Falls localuser ein anderer Username als remoteuser ist (also so wie im Beispiel oben), dann braucht man noch folgenden Eintrag in der lokalen ssh-Config:
# ~/.ssh/config Host remote Hostname remotehost.example.net User remoteuser # ForwardX11 yes # nur wenn man jedes mal auf dem Remotesystem X11-Programme starten will. # HostKeyAlias remote # nur für spezielle Fälle ;) # Port 42 # nur für spezielle Fälle ;)
Danach sollte dann ein einfaches ssh remote (ohne domain, ohne remoteuser, ohne Passwort) reichen, um sich einzuloggen. Falls es nicht funktioniert und er immer noch ein Passwort wissen will, evtl. im Config-File des Servers überprüfen, ob PubkeyAuthentication aktiviert ist!
Sollte der Verbindungsaufbau lange dauern, muss höchstwahrscheinlich in der Datei /etc/ssh/sshd_config der Wert
GSSAPIAuthentication yes
auf
GSSAPIAuthentication no
gesetzt und anschließend der sshd neu gestartet werden
Es ist nicht ungefährlich, einen Key ohne Passphrase zu verwenden, denn dann kann jeder, der sich irgendwie den Key verschafft, auf dem Server mit den Rechten des Key-Besitzers arbeiten. Solange der Rechner, auf dem der Key liegt, dessen eigener ist und er sich sicher ist, dass da sonst keiner drangeht, mag das noch angehen, aber was ist, wenn es ein fremder Rechner (Uni, Arbeitgeber, etc.) ist? Oder jemand es schafft, auf seinem Rechner ein rootkit zu installieren? Schon hat jemand anderes Zugriff auf den Key - und da er nicht mit einer Passphrase geschützt ist, kann er ihn sofort verwenden. Eine sicherere Alternative dazu bietet sshagent, beschrieben in http://www-106.ibm.com/developerworks/opensource/library/l-keyc.html?dwzone=opensource und den darauf folgenden Artikeln.
Siehe auch http://www.schlittermann.de/ssh.
ssh-agent in der .bashrc
Um sich den Umgang mit dem SSH-agenten zu vereinfachen, ruft man ihn über eine Funktion in der .bashrc auf.
sa() { if ps -o "%p %c" -u `id -u` |grep ssh-agent; then set $(ps -o "%p %c" -u $(id -u)|grep ssh-agent ) SSH_AGENT_PID=$1 export SSH_AGENT_PID SSH_AUTH_SOCK=$(find /tmp/ -type s -name "agent.$(( $1 - 1 ))" -uid $(id -u)) export SSH_AUTH_SOCK echo "ssh-agent lief bereits" else eval $(ssh-agent ) ssh-add ~/.ssh/id_rsa echo "ssh-agent wurde gestartet" fi }
Sicherstellen, dass sshd immer läuft
Übersetzt aus der LinuxGazette #78:
Mit OpenSSH kann man den sshd so konfigurieren, dass er direkt von init gestartet wird. Dies geht mit einem Eintrag in /etc/inittab mit der "respawn"-Direktive und der sshd-Option -D (don't detach):
# Auszug vom Ende der /etc/inittab ss:12345:respawn:/usr/sbin/sshd -D
Dies stellt sicher, dass ein sshd-Dämon immer am Laufen gehalten wird, selbst unter extremen Bedingungen (wie Speichermangel) oder wenn ein achtloser Administrator aus Versehen per killall den laufenden Dämon killt. So lange init funktionieren kann, wird es einen sshd am Laufen halten (genauso wie es auch die getty-Prozesse am Laufen hält).
Dies ist besonders nützlich für außer Haus untergebrachte Server (Colocation), die keine (zuverlässige) serielle Console haben. Es kann einem so eine längere Fahrt oder diesen frustrierenden, zeitraubenden und peinlichen Anruf bei den Rechenzentrumsleuten ersparen.
Abwehr von automatisierten Einbruchsversuchen
Steht ein SSH-Server offen im Internet, versuchen es einige immer wieder, eine User/Passwort-Kombination zu erraten, um den Server z.B. als Spam-Schleuder nutzen zu können. Das kann effektiv durch folgende iptable Befehle verhindert werden:
iptables -A INPUT -p tcp --dport 22 -m recent --set --name ssh --rsource iptables -A INPUT -p tcp --dport 22 -m recent ! --rcheck --seconds 60 --hitcount 4 --name ssh --rsource -j ACCEPT iptables -A INPUT -p tcp --dport 22 --syn -m limit --limit 1/m --limit-burst 3 -j ACCEPT iptables -A INPUT -p tcp --dport 22 --syn -j DROP
Außerdem kann eingeschränkt werden, wer ssh nutzen darf. Dazu ist in der Datei /etc/ssh/sshd_config einzufügen, wer das sein soll nach dem Schlüsselwort AllowUsers
AllowUsers root testuser
Tunnelbau mit ssh
Wenn man UnsichereProtokolle verwenden muss, kann man einen ssh-Tunnel zur Absicherung verwenden (außer bei ftp):
Weiterleitung eines lokalen Ports: ssh remotelogin@remotehost -L localport:remotehost:remoteport Leitet den lokalen Port durch einen ssh-Tunnel auf remoteport auf remotehost. Als localport verwendet man irgendeinen unbenutzten Highport, z.B. 12345, als remoteport muss man den durch das gewünschte Protokoll verwendeten Port angeben (110 für pop3 z.B.). Die (lokale) Client-Anwendung weist man dann an, den lokalen Port auf dem lokalen Rechner zu benutzen, ssh tunnelt das dann zu remotehost:remoteport durch.
Weiterleitung eines fernen Ports: ssh remotelogin@remotehost -R remoteport:local_host:localport Leitet den fernen Port durch einen ssh-Tunnel auf local_port auf local_host. Als remoteport verwendet man irgendeinen unbenutzten Highport, z.B. 12345, als local_port muss man den durch das gewünschte Protokoll verwendeten Port angeben (110 für pop3 z.B.). Die (remote laufende) Client-Anwendung weist man dann an, den remoteport zu benutzen, ssh tunnelt das dann zu local_host:localport durch.
- Beides kombiniert kann man z.B. dazu verwenden, um hinter einer Firewall und/oder einem Masquerading-Router eingehendes ssh zu ermöglichen:
ssh loginzuhause@zuhause -R 12345:arbeitsplatz:22 # auf Rechner am Arbeitsplatz ausführen ssh loginarbeitsplatz@arbeitsplatz -p 12345 # auf Rechner zuhause ausführen
Falls ausgehend keine Verbindungen zu Port 22 erlaubt sind, kann man den sshd zuhause auch z.B. auf Port 80 horchen lassen. Natürlich muss man am Arbeitsplatz zuerst abklären, ob so etwas überhaupt erlaubt ist!
ssh-Zusatzoptionen:
- -g
- erlaubt nicht nur localhost die Verwendung des weitergeleiteten Ports, sondern gibt ihn global frei - Vorsicht!
- -N
- nur Port-Weiterleitung, keine Kommandos auf Serverseite ausführen
- -f
- SSH-Client im Hintergrund ausführen, nachdem die Authentifizierung abgeschlossen ist
- -C
schaltet Kompression ein - empfehlenswert für langsame Verbindungen und hohes Datenaufkommen (z.B. X11)
- -X
- X11-Forwarding einschalten - ssh kümmert sich dann um xauth, $DISPLAY usw.
- -x
- X11-Forwarding ausschalten
Eine weitere Möglichkeit sichere Tunnel zu graben ist stunnel.
Ich habe nach einem Weg gesucht, per ssh einen Rechner hinter einer Firewall fernwartbar zu halten. Dies soll auch funktionieren, wenn die Verbindung neu aufgebaut wird, eventuell mit anderer IP. Folgendes Vorgehen funktioniert, für Verbesserungen bin ich dankbar --ThomasKalka
- auf dem Rechner, von dem aus der Zugang stattfinden soll ("zugang"), einen User anlegen (z.Bsp. "support") , ihm als login-shell "/bin/cat" zuweisen
- user "support" auf dem Rechner anlegen, der ferngewartet werden soll ("remote")
- ein dsa-Schlüsselpaar für support@remote anlegen
- public key an support@zugang:~/.ssh/authorized_keys2 anfügen
- support@remote sollte sich ohne Angabe eines pwd an remote einloggen können
- regelmäßig per cron ssh mit portforward aurufen
0-59/5 * * * * sleep 300 | ssh -R 22000:127.0.0.1:22 -T support@zugang > /dev/null
der Rechner ist nun per ssh -p 22000 support@localhost von "zugang" aus erreichbar
Zugriffe aus der "Windows"-Welt
Ein paar SSH-Clients für "Windows" werden unter /ZugriffVonWindows vorgestellt.
sftp Frontends
Wem sftp zu spartanisch ist, der kann eines der folgenden Frontends verwenden:
Kbear (http://kbear.sourceforge.net/)
im Konqueror (getestet unter KDE 3.1.2) fish://user@ip-adresse eingeben.
Mounten entfernter Datei-Systeme mit dem shfs
Man kann mit dem (Secure) SHell FileSystem SHFS auch ganze Datei-Systeme via ssh mounten.
Wofür ssh nicht gedacht ist
ssh root@localhost "mount -t iso9660 -o loop $debianmages/sarge-i386.$num.iso /mnt"
Das ist nicht sehr sinnvoll. Denn den gleichen Effekt ohne SSH erzielt man mit: su -c "mount -t iso9660 -o loop $debianmages/sarge-i386.$num.iso /mnt". -- BennySiegert 2003-03-26 16:40:11
sudo läßt sich auch in scripts verwenden -- frei nach RonnyBuchmann 2003-10-02 11:44:01
ssh -X root@localhost damit root auf das aktuelle X-Display zugreifen kann.
besser: xauth merge ~user/.Xauthority (siehe auch XFree86)
ssh-keygen Generieren/erzeugen von ssh Keys (RSA1, RSA2 und DSA)
- ssh-keygen -t rsa -b 2048 erzeugt einen RSA2 Key mit 2048 Bit Länge
- ssh-keygen -t dsa -b 2048 erzeugt einen DSA2 Key mit 2048 Bit Länge
- ssh-keygen -t rsa1 -b 2048 ezeugt einen RSA1 Key mit 2048 Bit Länge
Die maximale Schlüsselange beträgt 32768 Bit.
Tipps + Tricks
Um ungewollte Zugriffe zu vermeiden kann man im sshd einschränken, welche User oder welche Gruppen sich tatsächlich einloggen dürfen. Damit verhindert man, das Accounts mit relativ unsicheren Passwörtern, die nur für bestimmte Dienste gebraucht werden dazu dienen sich auf dem Rechner einzuloggen und weiteres auszuspionieren oder den Rechner für Angriffe zu missbrauchen. Beispiele: (z.B. via /etc/ssh/sshd_config): AllowGroups ssh-group oder AllowUsers ssh-user.
Man kann dann in den entsprechenden Logs Einträge wie folgenden sehen: Failed password for illegal user test from 218.93.124.211 port 52084 ssh2 |
Anwendung von ssh-argv0: ln -s `which ssh-arg0` example.com nun kann man sich mittels './example.com' zu dem Rechner verbinden. Es sei erwähnt das dieses Script bei Debian basierten Distibution sich im $PATH befindet.
Unbedingt darauf achten, dass auf dem entfernten Rechner nicht DISPLAY überschrieben wird. Zum Beispiel durch einen Eintrag in der ~/.bashrc. Führt zu dem Phänomen, dass ein remote ausgeführtes Programm nicht lokal angezeigt wird, sondern auf dem remote Rechner.
Optionen
- -b Bit
- (numerischer Wert bis max. 32768 Bits)
- -f
- Dateiname
- -l
- Gibt den Fingerprint des Keys aus
- -p
- ändern der Passphrase eines privaten Keys
- -t type
- mögliche Werte rsa1 (Protocol 1) , dsa und rsa (Protocol 2)
- -C
- neuer Kommentar
- -D Reader
- Liest einen privaten RSA-Key von einem Smartcardreader
- -N
- neue Passphrase
- -P
- alte Passphrase
- -U Reader
- Lädt einen privaten RSA Key in einen Smartcardreader
Links
ssh-Artikel auf ProLinux
SSH durch andere Protokolle (https etc.) tunneln (Vortrag von Johannes Franken)
Fragen
- Ist es möglich, sshd so zu konfigurieren, dass man sich NUR per Zertifikat authentifizieren kann? Damit man sich nicht völlig aussperren kann, wäre es sinnvoll, wenn eine lokale Anmeldung mit Passwort aber weiterhin möglich ist. Nur remote sollte man dies aus Sicherheitsgründen eben nur per Zertifikat können.
In der /etc/ssh/sshd_config kann man die Optionen PasswordAuthentication sowie PAMAuthenticationViaKbdInt auf no setzen.