16.3 SSH nutzen 

Nachdem wir unseren Server konfiguriert haben, wollen wir einen Blick auf die vielfältigen Möglichkeiten werfen, die uns SSH bietet.

16.3.1 Remote-Login 

Eines der wichtigsten, aber bei Weitem nicht das einzige Feature ist natürlich das Remote-Login. Dazu gibt es zwei Möglichkeiten: Einmal kann man unter Unix-Systemen natürlich den Kommandozeilenclient ssh nutzen, unter Windows-Systemen dagegen bietet sich ein Tool wie PuTTY an.

In Aktion: ssh

Das ssh-Tool gehört zum Inventar eines jeden Unix-Administrators, und Sie müssen es einfach kennen.

Der Aufruf des Programms selbst ist sehr einfach:

ploetner@elbs:~$ ssh root@192.168.128.171 
Password: 
Last login: Mon Apr 26 16:57:14 2004 
ldap-server:~#

Listing 16.8    Kommandozeilen-ssh unter Unix

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 hier im Beispiel die uns von der Serverkonfiguration 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.

16.3.2 Secure Copy 

Oft muss man zwischen Servern auch Dateien austauschen, was ohne entsprechende Dienste schon recht aufwendig und schnell auch unsicher werden kann. Aus diesem Grund kann man für diese Aufgabe sinnvollerweise auch den SSH-Zugang nutzen, sodass man nicht zu viele selten benötige Dienste pflegen muss und die Daten auch sicher kopieren kann.

Dateien über SSH kopieren

Egal von welchem Unix-System aus Sie arbeiten, die benötigten Clientprogramme werden in 99 % aller Fälle bereits installiert sein. Das gilt auch für scp, das ähnlich wie das bekannte cp-Kommando Dateien kopieren kann. Zusätzlich können sinnvollerweise Dateien per SSH von Servern geholt beziehungsweise auf Server kopiert werden. Dazu muss nur die Syntax von cp bezüglich Quelle beziehungsweise Ziel entsprechend angepasst werden:

$ scp user@host:quelle ziel

Listing 16.9    Dateien holen

$ scp quelle [quelle2 ...] user@host:ziel

Listing 16.10    Dateien senden

Genauso wie cp kann scp auch rekursiv Verzeichnisse kopieren oder Wildcards wie »*« oder »?« nutzen, die dann remote aufgelöst werden.

$ 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 
$

Listing 16.11    Dateien kopieren mit Wildcards

16.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« noch den Algorithmus angeben muss, mit dem wir das Schlüsselpaar später nutzen wollen.

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:~$

Listing 16.12    Erstellung eines Schlüsselpaares mittels ssh-keygen

Im Allgemeinen wird diese Entscheidung wohl zwischen RSA und DSA fallen, und hier 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 Passphrase wäre das Äquivalent zu einem ganz normalen Benutzerkennwort, da der private Schlüssel mit ihr verschlüsselt wäre. Sie 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

Im Folgenden haben wir also zwei wichtige Dateien erstellt bekommen:

• /.ssh/id_rsa

• In dieser Datei liegt der private Schlüssel. Normalerweise ist dieser – sofern nichts anderes angegeben wurde -- bei RSA und DSA 1024 Bit lang, kann aber durch die »-b« Option 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.

cvs@ploetner:~$ ls -l .ssh/id_rsa 
-rw-------  1 cvs  cvs  887 Jul 3 11:28 .ssh/id_rsa

Listing 16.13    Der private Schlüssel bei RSA: 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.

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

Dazu kopieren wir beispielsweise mit scp die id_rsa.pub in die Datei authorized_keys im .ssh-Verzeichnis des Benutzer-Accounts auf dem Server, 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:

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

Listing 16.14    Den öffentlichen Schlüssel aktivieren

Dazu loggen wir uns zuerst per SSH auf dem Server ein und erstellen per mkdir das entsprechende Verzeichnis. Schließlich kopieren wir per scp den Schlüssel zuerst in das aktuelle Verzeichnis.

Da ja durchaus mehrere öffentliche Schlüssel »autorisierte Schlüssel« sein können, wollen wir die /.ssh/authorized_keys nicht einfach überschreiben, sondern 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:

cvs@ploetner:~$ ssh root@192.168.128.171 
Last login: Wed Jun 30 11:58:03 2004 from ploetner 
ldap-server:~#

Listing 16.15    Passwortloses Login über Public-Key-Authentifizierung

So eine Authentifizierung über Public-Key-Verfahren ist besonders beim Einsatz von Diensten und Skripts sinnvoll, die sich ohne Benutzermitwirkung automatisch auf fremden Systemen einloggen können sollen.

Achtung auf fremden Systemen

Damit das Ganze so schön funktioniert wie in dem eben vorgestellten Beispiel, muss auf dem Server die bereits erläuterte PubkeyAuthentication-Option gesetzt sein. <Wir haben also bisher immer implizit das SSH-Protokoll Version 2 genutzt, wie Sie vielleicht bereits an dem genutzten 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 auf ihn Zugriff 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 eben keine Rechte hat.

Achten Sie also darauf, von unsicheren Systemen aus niemals mit privaten Schlüsseln ohne Passphrase zu arbeiten.

Diese Anmerkungen haben natürlich nichts mit der authorized_keys und den öffentlichen Schlüsseln zu tun. Wenn Sie das Prinzip der asymmetrischen Kryptographie 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 mittels 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 zu dem Account verschaffen kann.

16.3.4 Secure File Transfer 

Ersatz für FTP

Ist das sftp-Subsystem auf dem SSH-Server aktiviert, so kann man auch »normales« FTP über eine SSH-Verbindung laufen lassen. Man braucht dazu nichts weiter als das sftp-Programm, das Bestandteil der Open-SSH-Distribution ist. Einmal verbunden, kann man alle bereits vom normalen Konsolen-ftp bekannten Befehle nutzen:

$ 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

Listing 16.16    Secure-FTP-Sitzung mit Public-Key-Authentication

16.3.5 X11 Forwarding 

Entfernte Fenster

Damit die Administration von Unix-Servern perfekt wird, wollen wir noch die Benutzung des X11 Forwarding erläutern. Mit diesem Feature können ja bekanntermaßen 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 /etc/ssh/sshd_config aktiviert (»yes«) sein.

Auf der Clientseite benötigt man nur einen laufenden X-Server, also reicht zum Beispiel eine ganz normale KDE- oder Gnome-Sitzung als der Benutzer, der auch den ssh-Befehl ausführt, <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 nun auf dem Desktop ein Fenster mit der Applikation aufgehen. 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.

16.3.6 SSH-Port-Forwarding 

Wie Sie bisher gesehen haben, stellt SSH schon selbst eine ganze Reihe nützlicher Dienste für die Remote-Administration von Unix-Servern bereit. Aber es gibt natürlich 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. Dazu 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 Webbrowser oder einem beliebigen anderen Programm 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:

$ ssh -f -N -C -L 8888:rechner:6667 -l user ssh-server

Listing 16.17    Einen Tunnel aufbauen

Dieser Aufruf bewirkt Folgendes:

• -f

• Nach dem erfolgreichen Verbindungsaufbau forkt sich SSH in den Hintergrund, sodass 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

• Dies ö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 »-L«-Parameter spezifizierten 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 keine 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