23    OpenSSH

In diesem Kapitel lernen Sie den fortgeschrittenen Umgang mit dem OpenSSH-Client sowie dem OpenSSH-Server.

Im Jahr 1969 wurde telnet (TELeNETwork) entwickelt. Es eröffnete die Möglichkeit, auf der Kommandozeile eines entfernten Rechners zu arbeiten, als säße man direkt davor. Sie können sich leicht vorstellen, dass telnet sich in Windeseile verbreitete und äußerst beliebt war, weil es das Ende der »Turnschuhadministration« einläutete. Sicherheitsbedenken spielten noch keine Rolle, da die Anzahl der vernetzten Rechner zu Anfang der 70er-Jahre des vergangenen Jahrhunderts noch ausgesprochen übersichtlich war. So störte es zunächst niemanden, dass die Anmeldung ebenso wie der Inhalt der telnet-Session unverschlüsselt übertragen wurde. Das änderte sich, als telnet in den 90ern immer öfter Opfer von Sniffer-Angriffen wurde. 1995 entwickelte der finnische Student Tatu Ylönen das SSH-Protokoll, und 1999 debütierte ein SSH-Fork (Code-Ableger) unter dem Namen OpenSSH als Bestandteil der OpenBSD-Distribution 2.6.

OpenSSH wurde auf eine Vielzahl anderer Betriebssysteme portiert. Wenn Sie sich auf einem Linux-System die Versionsnummer von OpenSSH anzeigen lassen, finden Sie darin ein »p«:

$ ssh -V
OpenSSH_7.6p1, OpenSSL 1.1.0h-fips  27 Mar 2018

Listing 23.1    OpenSSH-Versionsnummer anzeigen lassen

An diesem Buchstaben erkennen Sie, dass es sich um eine portierte Version handelt. Auch die Versionsnummer von OpenSSL, dessen Bibliotheken die SSH-Tools benötigen, wird angezeigt.

23.1    Die SSH-Familie

Zur SSH-Familie gehören folgende Programme:

23.1.1    Die Clients: »ssh«, »scp«, »sftp«

Diese Clientsoftware ist Ihr Standardwerkzeug im Administrationsalltag. Schauen wir uns die Programme der Reihe nach an!

»ssh«

Im einfachsten Fall können Sie sich mit dem folgenden Kommando auf ein entferntes System einloggen:

$ ssh server.example.com

Listing 23.2    Login

Anstelle des Namens können Sie selbstverständlich auch die IP-Adresse eingeben. Wenn Sie sich zum ersten Mal mit diesem Server verbinden, kennt Ihr System natürlich den öffentlichen Schlüssel des Servers noch nicht, und Sie bekommen zunächst eine Folge von Hexadezimalzahlen präsentiert, etwa so:

Authenticity of host 'server.example.com (10.10.47.11)' can't be established.
RSA key fingerprint is 27:53:1c:21:8a:12:db:aa:c2:2a:ec:55:a1:b6:06:97.
Are you sure you want to continue connecting (yes/no)?

Listing 23.3    Fingerprint des öffentlichen Serverschlüssels

Das ist der »Fingerabdruck« (Fingerprint) des öffentlichen Serverschlüssels. Sie müssen den Schlüssel durch Eingabe von »yes« akzeptieren, um fortfahren zu können. Der Server wird Sie nun nach Ihrem Passwort fragen, und wenn Sie es korrekt eingeben, erhalten Sie eine Shell auf dem Remote-System. Das funktioniert aber nur, sofern Sie auf dem lokalen und dem entfernten System den gleichen Benutzernamen haben. Falls nicht, müssen Sie dem Remote-System mitteilen, mit welchem Benutzernamen Sie sich einloggen möchten:

# ssh peer@server.example.com

Listing 23.4    Login mit Benutzernamen

Den öffentlichen Schlüssel des Servers legt Ihr System in der Datei ~/.ssh/known_hosts ab. Der öffentliche Schlüssel des Servers wird dabei von Ihrem System in der Datei ~/.ssh/known_hosts abgelegt.

[+]  Wenn sich der Schlüssel ändert

Bei allen weiteren Verbindungsversuchen wird Ihr System prüfen, ob sich der Schlüssel geändert hat, und in diesem Fall wird es eine eindringliche Warnung ausgeben. Dass sich der Schlüssel geändert hat, kann möglicherweise darauf hindeuten, dass jemand versucht, Ihre SSH-Verbindung zu kapern oder umzuleiten. Es kann jedoch auch ganz harmlose Ursachen haben. Der Server ist möglicherweise neu installiert worden, oder die IP-Adresse hat sich geändert. In jedem Fall ist es legitim und ratsam, sich beim Administrator des Servers zu versichern, dass die Gründe für den Schlüsselwechsel harmlos sind.

Parameter wie Ihren Usernamen oder den Port, falls dieser vom SSH-Standard-Port 22 abweicht, können Sie in der Datei ~/.ssh/config ablegen, um sie nicht bei jedem Verbindungsaufbau neu eintippen zu müssen. Diese Datei kann wie folgt aussehen:

Host example.com
    HostName 10.10.47.11
    Port 2222
    User peer
Host example.net
    HostName 10.10.47.42
    Port 443
    User backup

Listing 23.5    SSH-Client-Konfigurationsdatei

Mit dieser Konfigurationsdatei tippen Sie nur noch:

# ssh example.com

Listing 23.6    SSH-Login, Kurzfassung

Wollen Sie auf dem entfernten System nur einen einzigen Befehl ausführen, können Sie SSH diesen Befehl auch direkt mit auf den Weg geben:

# ssh example.com uptime
13:45:56  18 Tage  2:48 an,  1 Benutzer,  Durchschnittslast: 0,09, 0,03, 0,00

Listing 23.7    SSH-Login mit Befehlsübergabe

»scp«

Secure Copy (scp) funktioniert grundsätzlich wie der bekannte cp-Befehl, allerdings über Rechnergrenzen hinweg.

Wollen Sie die Datei test.txt aus dem aktuellen Verzeichnis auf Ihren Server doku.example.com und dort in das Verzeichnis /usr/local/texte kopieren, lautet das Kommando:

# scp test.txt doku.example.com:/usr/local/texte/

Listing 23.8    Eine Datei mit »scp« kopieren

Falls Sie auf dem Server einen anderen Benutzernamen verwenden als auf Ihrem lokalen System, müssen Sie diesen zusätzlich angeben:

# scp test.txt username@doku.example.com:/usr/local/texte/

Listing 23.9    Eine Datei als anderer User mit »scp« kopieren

scp unterstützt auch das rekursive Kopieren ganzer Verzeichnisbäume. Geben Sie dazu den Parameter -r an:

# scp -r /home/user/meinetexte/* username@doku.example.com:/usr/local/meinetexte/

Listing 23.10    Einen Verzeichnisbaum kopieren

»sftp«

Auch sftp benutzt die gleiche Syntax wie sein herkömmliches Pendant, ftp. Hier ist ein Beispiel für den Beginn einer SFTP-Sitzung:

peer@client:~$ sftp peer@storage.example.com

Connecting to storage.example.com...
peer@storage.example.com's password: ***********

sftp> help Available commands: bye Quit sftp cd path Change remote directory
to 'path' chgrp grp path Change group of file 'path' to 'grp' chmod mode
path Change permissions of file 'path' to 'mode' chown own path Change owner
of file 'path' to 'own'
[…]

Listing 23.11    Eine SFTP-Sitzung

23.1.2    Der Server: »sshd«

Die Konfigurationsdatei, mit der Sie das Verhalten des SSH-Daemons steuern, heißt /etc/ssh/sshd_config. Die in dieser Datei hinterlegten Default-Einstellungen sind vernünftig gewählt, und für die meisten Anwendungsfälle müssen Sie hier keine Änderungen vornehmen. Werfen wir trotzdem einen Blick auf die wichtigsten Schräubchen, an denen Sie im Bedarfsfall drehen können.

Benutzer und Gruppen

Sie können den sshd anweisen, nur bestimmte Benutzer oder solche, die sich in bestimmten Gruppen befinden, zuzulassen.

Mit den folgenden Zeilen gestatten Sie nur den Benutzern »meier«, »mueller« und Mitgliedern der Gruppe »backup« den Login:

AllowUsers meier mueller
AllowGroups backup

Listing 23.12    Einzelne Nutzer und Gruppen zulassen, alle anderen verbieten

Umgekehrt geht's auch: Sie können mit DenyUsers und DenyGroups pauschal alle Nutzer und Gruppen zulassen, mit Ausnahme derer, die Sie explizit benennen.

DenyUsers schmitz schulze
DenyGroups webdesigner marketing[ 38 ]

Listing 23.13    Alle Nutzer und Gruppen zulassen, aber einzelne verbieten

Die Benutzer- und Gruppendirektiven werden in folgender Reihenfolge geprüft:

  1. DenyUsers

  2. AllowUsers

  3. DenyGroups

  4. AllowGroups

Keine root-Logins

In der Regel ist es nicht notwendig, dass man sich mit root-Rechten auf einem System einloggen muss. Ein User-Login reicht aus. Von dort können Sie immer noch in den root-Account wechseln. In der /etc/ssh/sshd_config verbieten Sie root-Logins mit dieser Zeile komplett:

PermitRootLogin no

Listing 23.14    Keine root-Logins zulassen

Wenn Sie – wie gleich auf den nächsten Seiten gezeigt – einen SSH-Schlüssel für root erzeugt und auf dem Server hinterlegt haben, können Sie auch überlegen, den root-Login (nur) mit SSH-Schlüssel zuzulassen:

PermitRootLogin  without-password

Listing 23.15    Keine root-Logins zulassen

Protokollversionen

Ein aktueller sshd unterstützt in seiner Konfiguration serienmäßig nur noch die Protokollversion SSHv2, was Sie an der folgenden Zeile in der Konfigurationsdatei /etc/ssh/sshd_config erkennen:

Protocol 2

Listing 23.16    Die Protokollversion 2 ist Standard.

Wenn Sie noch ein archäologisch interessantes Linux mit einer sehr alten SSH-Implementation betreiben, das aber auf Ihren Server zugreifen können muss, können Sie dem SSH-Server die Erlaubnis geben, zusätzlich SSHv1 anzubieten. Dazu ändern Sie die Protocol-Zeile so:

Protocol 2,1

Listing 23.17    Die Protokollversion 1 wird zusätzlich erlaubt.

Der SSH-Server wird nur bei einer Clientanfrage zunächst das SSHv2-Protokoll anbieten und nur auf SSHv1 zurückfallen, falls die Anfrage misslingt.