21.3 SSH nutzen
Nachdem wir unseren Server konfiguriert haben, wollen wir einen Blick auf die vielfältigen Möglichkeiten werfen, die uns SSH bietet.
21.3.1 Remote-Login
Eines der wichtigsten Features ist das Remote-Login. Dazu gibt es zwei Möglichkeiten: Zum einen kann man unter Unix-Systemen den Kommandozeilen-Client ssh nutzen, zum anderen bietet sich unter Windows-Systemen ein Tool wie PuTTY an.
In Aktion: ssh
Das ssh-Tool gehört zum Inventar eines jeden Unix-Administrators – Sie müssen es einfach kennen. Der Aufruf des Programms selbst ist sehr einfach:
Listing 21.8 Kommandozeilen-ssh unter Unix
ploetner@elbs:~$ ssh root@192.168.128.171
Password:
Last login: Mon Apr 26 16:57:14 2004
ldap-server:~#
[zB]In diesem Beispiel haben wir uns also von unserem aktuellen System elbs aus, auf dem wir mit der Benutzerkennung ploetner eingeloggt sind, mit dem Rechner mit der IP-Adresse 192.168.128.171 verbunden und uns dort als der Superuser root eingeloggt.
Auch wurde die uns von der Konfiguration her bekannte PasswordAuthentication genutzt, die jedem Unix-Benutzer vom normalen Login-Vorgang her geläufig sein sollte. Zudem musste beim Server für diese Aktion die Option PermitRootLogin auf yes gesetzt sein, damit wir uns erfolgreich als Superuser einloggen konnten.
21.3.2 Secure Copy
Oft muss man zwischen Servern auch Dateien austauschen, was ohne entsprechende Dienste recht aufwendig und schnell auch unsicher werden kann. Aus diesem Grund kann man für diese Aufgabe sinnvollerweise auch den SSH-Zugang nutzen, so dass man nicht zu viele selten benötige Dienste pflegen muss und die Daten auch sicher kopieren kann.
Dateien über SSH kopieren
Von welchem Unix-System aus Sie auch arbeiten, die benötigten Client-Programme werden in 99 % aller Fälle bereits installiert sein. Dies gilt auch für scp, das ähnlich wie das bekannte cp-Kommando Dateien kopieren kann. Zusätzlich können Dateien per SSH von Servern geholt beziehungsweise auf Server kopiert werden, was sinnvoll ist. Dazu muss nur die Syntax von cp bezüglich Quelle und Ziel entsprechend angepasst werden:
Listing 21.9 Dateien holen
$ scp user@host:quelle ziel
Listing 21.10 Dateien senden
$ scp quelle [quelle2 ...] user@host:ziel
Genau wie cp kann auch scp rekursiv Verzeichnisse kopieren oder Wildcards wie »*« oder »?« nutzen, die dann auf dem entfernten Rechner aufgelöst werden.
Listing 21.11 Dateien kopieren mit Wildcards
$ scp jploetner@172.20.2.1:~/Projekte/*.PNG .
Password:
pscp.PNG 100 % 53KB 53.2KB/s 00:00
PuTTYgen.PNG 100 % 61KB 61.4KB/s 00:00
PuTTY_term.PNG 100 % 53KB 52.7KB/s 00:00
PuTTY_X11.PNG 100 % 63KB 62.8KB/s 00:00
$
21.3.3 Authentifizierung über Public-Key-Verfahren
RSA in der Praxis
Im Folgenden wollen wir uns mit den bereits angesprochenen Public-Key-Verfahren zur Authentifizierung beim SSH-Server beschäftigen. Bevor man irgendwelche öffentlichen und privaten Schlüssel nutzen kann, muss man diese erst einmal erstellen.
Dazu dient das Kommando ssh-keygen, dem man über den Parameter -t den Algorithmus angeben muss, mit dem wir das Schlüsselpaar später nutzen wollen.
Listing 21.12 Erstellung eines Schlüsselpaares mittels ssh-keygen
cvs@ploetner:~$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (~/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in ~/.ssh/id_rsa.
Your public key has been saved in ~/.ssh/id_rsa.pub.
The key fingerprint is:
df:4e:09:cc:33:02:0a:7f:30:9b:10:79:24:3d:e3:86 cvs@ploetner
cvs@ploetner:~$
Im Allgemeinen wird man sich wohl zwischen RSA und DSA entscheiden. Im Beispiel haben wir uns für das Ihnen bereits bekannte RSA-Verfahren entschieden. Nach der Erzeugung des Schlüsselpaares fragt das Programm, in welcher Datei der erzeugte Schlüssel gespeichert werden soll. Meistens ist die Vorgabe ~/.ssh/id_rsa beziehungsweise ~/.ssh/id_dsa sinnvoll, es sei denn, man möchte den Schlüssel nicht für den aktuellen User auf diesem System generieren.
Als Nächstes wird nach einer Passphrase gefragt. Diese wäre das Äquivalent zu einem ganz normalen Benutzerkennwort, da der private Schlüssel mit ihr verschlüsselt wäre, müsste also bei jeder Benutzung des Schlüssels angegeben werden. Da wir uns aber gänzlich ohne Passwort einloggen möchten – und demzufolge ganz auf die Sicherheit und Integrität des privaten Schlüssels vertrauen --, geben wir keine Passphrase an.
Die Schlüsseldateien
Es wurden also zwei wichtige Dateien erstellt:
- ~/.ssh/id_rsa
In dieser Datei liegt der private Schlüssel. Normalerweise ist er – sofern nichts anderes angegeben wurde – bei RSA und DSA 1024 Bit lang, kann aber durch die Option -b auch verlängert werden. Wurde der Schlüssel nicht über eine Passphrase mit 3DES verschlüsselt, sollte man strengstens darauf achten, dass diese Datei von niemandem gelesen werden kann. - ~/.ssh/id_rsa.pub
Diese Datei enthält den öffentlichen Schlüssel unseres Schlüsselpaares, den wir im Folgenden auf den Servern verteilen müssen, auf denen wir uns später ohne Passwort einloggen wollen.
Listing 21.13 Der private Schlüssel bei RSA: id_rsa
cvs@ploetner:~$ ls -l .ssh/id_rsa
-rw------- 1 cvs cvs 887 Jul 3 11:28 .ssh/id_rsa
Im Falle einer Kompromittierung wären nämlich alle Systeme, auf die man von diesem User-Account aus über den Schlüssel Zugriff hätte, ebenfalls offen.
Dazu hängen wir mit ssh und scp den Inhalt von id_rsa.pub an die Datei authorized_keys im .ssh-Verzeichnis des Benutzeraccounts auf dem Server an, auf dem wir uns nachher so problemlos einloggen möchten. In vielen Fällen müssen wir vorher aber erst noch besagtes Verzeichnis auf dem Rechner anlegen, bevor wir die Datei schließlich kopieren können:
Listing 21.14 Den öffentlichen Schlüssel aktivieren
cvs@ploetner:~$ ssh root@192.168.128.171
The authenticity of host 'ldap-server \
(192.168.128.171)' can't be established.
RSA key fingerprint is \
9e:00:79:9f:de:53:c2:27:2a:9b:4d:b6:eb:1e:b3:cc.
Are you sure you want to continue connecting
(yes/no)? yes
Warning: Permanently added '192.168.128.171' (RSA) \
to the list of known hosts.
Password:
Last login: Wed Jun 30 10:48:50 2004 from elbs
ldap-server:~# mkdir .ssh
ldap-server:~# scp cvs@ploetner:~/.ssh/id_rsa.pub .
Password:
id_rsa.pub 100 % 222 0.2KB/s 00:00
ldap-server:~# cat id_rsa.pub >> .ssh/authorized_keys
ldap-server:~# exit
logout
Dazu loggen wir uns zuerst per SSH auf dem Server ein und erstellen per mkdir das entsprechende Verzeichnis. Schließlich kopieren wir mit scp den Schlüssel zuerst in das aktuelle Verzeichnis.
Da durchaus mehrere öffentliche Schlüssel autorisierte Schlüssel sein können, wollen wir die ~/.ssh/authorized_keys nicht einfach überschreiben, sondern wir hängen den Inhalt der Schlüsseldatei mittels cat und Ausgabeumleitung an die Datei an.
Sicheres Login ohne Passwort
Im Folgenden testen wir, ob die Authentifizierung ohne Passwort funktioniert:
Listing 21.15 Passwortloses Login über Public-Key-Authentifizierung
cvs@ploetner:~$ ssh root@192.168.128.171
Last login: Wed Jun 30 11:58:03 2004 from ploetner
ldap-server:~#
Eine solche Authentifizierung über Public-Key-Verfahren ist besonders beim Einsatz von Diensten und Skripten sinnvoll, die sich ohne Benutzermitwirkung automatisch auf fremden Systemen einloggen sollen.
Achtung auf fremden Systemen
Damit das Ganze wie in dem eben vorgestellten Beispiel funktioniert, muss auf dem Server die bereits erläuterte PubkeyAuthentication-Option gesetzt sein. [Fn. Wir haben also bisher immer implizit das SSH-Protokoll Version 2 genutzt, wie Sie vielleicht bereits an dem verwendeten Verfahren (DSA) gemerkt haben.] Außerdem ist zu beachten, dass die Sicherheit bei einem Schlüssel ohne Passphrase allein darauf beruht, dass niemand außer dem betreffenden Benutzer Zugriff auf diesen Schlüssel hat.
Sicherheitsprobleme
Daraus ergeben sich natürlich Implikationen für Systeme, auf denen Sie kein Vertrauen in den Systemadministrator haben können – und dazu gehören unter Umständen auch Benutzer mit eingeschränkten sudo-Rechten. Schließlich kann root uneingeschränkt auf alle Dateien zugreifen, selbst wenn er formal in der Unix-Rechtemaske keine Rechte hat.
Achten Sie also darauf, von unsicheren Systemen aus niemals mit privaten Schlüsseln ohne Passphrase zu arbeiten.
Diese Anmerkungen betreffen natürlich nicht die Datei authorized_keys und den öffentlichen Schlüssel. Wenn Sie das Prinzip der asymmetrischen Kryptografie verstanden haben, dann ist Ihnen dieser Fakt auch ganz klar: Die Authentifizierung gelingt nämlich immer nur in einer Richtung, sie ist nicht bidirektional. Mit anderen Worten: Sie müssen zwei Schlüsselpaare erstellen, wenn Sie mit Public-Key-Authentifizierung von System A auf System B und von System B auf System A zugreifen wollen.
Die authorized_keys-Datei sollte allerdings immer nur für den Besitzer der Datei schreibbar sein, da sich sonst jeder User, der Schreibrechte auf diese Datei besitzt, Zugriff auf den Account verschaffen kann.
21.3.4 Secure File Transfer
Ersatz für FTP
Ist das sftp-Subsystem (SSH File Transfer Protocol auf dem SSH-Server aktiviert, so kann man FTP-ähnliche Dateitransaktionen über eine SSH-Verbindung laufen lassen. Man braucht dazu nichts weiter als das Programm sftp, das Bestandteil der Open-SSH-Distribution ist. Einmal verbunden, kann man alle bereits vom normalen Konsolen-ftp her bekannten Befehle nutzen:
Listing 21.16 SFTP-Sitzung mit Public-Key-Authentication
$ sftp ploetner@comrades.are-crazy.org
Connecting to comrades.are-crazy.org...
sftp> ls
. .. .alias .bash_history .bash_profile
.bashrc .cshrc .ssh
sftp> get .bash_profile
Fetching /home/ploetner/.bash_profile to .bash_profile
~/.bash_profile 100 % 704 0.7KB/s 00:01
sftp> exit
21.3.5 X11-Forwarding
Entfernte Fenster
Damit Sie Ihre Administration von Unix-Servern perfektionieren können, wollen wir noch die Benutzung des X11 Forwarding erläutern. Mit diesem Feature können bekanntlich auf dem Server ausgeführte X-Anwendungen auf dem Client in einem Fenster dargestellt werden. Damit dies serverseitig überhaupt funktionieren kann, muss die Option X11Forwarding in der Datei /etc/ssh/sshd_config aktiviert (»yes«) sein.
Auf der Client-Seite benötigt man nur einen laufenden X-Server, also reicht zum Beispiel eine ganz normale KDE- oder GNOME-Sitzung des Benutzers, der auch den ssh-Befehl ausführt, [Fn. Normalerweise kann nur der Benutzer auf den X-Server zugreifen, der ihn auch gestartet hat. Wollen Sie zum Beispiel als root ein Fenster auf einem Display öffnen, das jploetner geöffnet hat, so wird das ohne Weiteres nicht funktionieren. Demzufolge würde auch in diesem Fall ein von root versuchtes ssh mit X11 Forwarding fehlschlagen, da er keinen Zugriff auf den Desktop bekommt.] vollkommen aus. Clientseitig kann man das Forwarding entweder über die ~/.ssh/config ähnlich wie in der sshd_config anschalten oder es explizit über die Kommandozeilenoption -X aktivieren.
Anschließend kann man auf dem Server einfach über ein xterm & versuchen, ein grafisches Terminal zu starten. Ist die Applikation auf dem Server installiert, sollte sich nun auf dem Desktop ein Fenster mit der Applikation öffnen. Dieses kann nun ohne Einschränkungen bedient werden. Vor allem für grafische Administrationstools wie YaST2 auf SUSE-Linux-Servern ist dieses Feature äußerst sinnvoll, da es nun wirklich keinen Grund mehr gibt, einen Server permanent mit Bildschirm und Tastatur auszustatten.
21.3.6 SSH-Port-Forwarding
Wie Sie bisher gesehen haben, stellt SSH bereits eine ganze Reihe nützlicher Dienste für die Remote-Administration von Unix-Servern bereit. Es gibt auch den Fall, dass man eine unverschlüsselte Kommunikation über eine unsichere Leitung übertragen muss oder aufgrund von Firewall-Regeln an bestimmte Ports nicht direkt herankommt.
Dienste tunneln
Um so ein Problem zu lösen, gibt es die sogenannten SSH-Tunnel. Zur Errichtung eines SSH-Tunnels verbindet man sich ganz normal mit einem SSH-Server, der dann zu Ihrem gewünschten Kommunikationspartner eine Verbindung aufbaut. Diese Verbindung wird anschließend über die von Ihnen gestartete SSH-Sitzung zu einem Port auf Ihrem lokalen Rechner weitergeleitet. Verbinden Sie sich nun zum Beispiel mittels eines Webbrowsers oder eines beliebigen anderen Programms mit eben diesem lokalen Port auf Ihrem Rechner, so kommunizieren Sie indirekt über die verschlüsselte SSH-Verbindung – also über den Umweg über den SSH-Server – mit Ihrem Kommunikationspartner.
Einen Tunnel richtet man unter Linux wie folgt ein:
Listing 21.16 Einen Tunnel aufbauen
$ ssh -f -N -C -L 8888:rechner:6667 -l user ssh-server
Dieser Aufruf bewirkt Folgendes:
- -f
Nach dem erfolgreichen Verbindungsaufbau forkt [Fn. Mehr zum Thema forking erfahren Sie in Abschnitt fork]. sich SSH in den Hintergrund, so dass die Shell nicht weiter blockiert wird. - -N
SSH führt nach einer erfolgreichen Verbindung auf der Gegenseite kein Kommando aus – wir wollen ja nur die Port-Weiterleitung. - -C
Die Verbindung wird komprimiert, damit der Datentransfer beschleunigt wird. - -L 8888:rechner:6667
Öffnet uns den lokalen Port 8888, der dann über den Tunnel mit dem Port 6667 auf rechner verbunden ist. Die Strecke zwischen den beiden Systemen wird mit SSH bis zu unserem SSH-Server getunnelt und läuft ab dort unverschlüsselt weiter. - -l user
Wir loggen uns auf dem SSH-Server mit dieser Benutzerkennung ein. - ssh-server
Wir verbinden uns, um den Tunnel aufzubauen, mit dem SSH-Port dieses Systems. Von dort wird dann die Verbindung zu dem im Parameter -L angegebenen System aufgebaut.
Jetzt müssen wir, um die verschlüsselte Verbindung zu nutzen, unserem Client-Programm nur noch sagen, dass wir statt mit rechner:6667 mit localhost:8888 sprechen wollen. Ein netstat --tcp sollte uns dann eine Verbindung zum localhost-Port 8888 und eine Verbindung zum ssh-server auf den SSH-Port anzeigen.
[»]Als normaler Benutzer können Sie unter Unix keinen der sogenannten privilegierten
Ports unterhalb von 1024 belegen, da diese root vorbehalten sind. Wählen Sie lieber einen noch nicht belegten höheren Port.
Ihr Kommentar
Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.
