Tipp: Sicherer Serverzugriff mit OpenSSH
Bereits vor Aufkommen des Internets war es für Administratoren wichtig, über das Netzwerk – also ohne Zugriff auf eine direkt angeschlossene Tastatur – Server und Rechner zu warten. Die ersten hierfür entwickelten Protokolle waren ‘Telnet’ und ‘rsh’ (Remote Shell), die die Daten (inklusive Login-Daten) unverschlüsselt und damit – nach heutigen Maßstäben – unsicher übertragen.
Der Wunsch nach Sicherheit brachte die Entwickler dazu, ein Protokoll zu entwickeln, das sämtliche Daten inklusive Anmeldung verschlüsselt überträgt.
In Anlehnung an die ‘rsh’ (Remote Shell) erhielt das Protokoll den Namen ‘ssh’ für ‘Secure Shell’. Auf GNU/Linux-Systemen findet man heute meist die freie Implementierung dieses Protokolls mit dem Namen ‘OpenSSH’.
Einloggen auf einen Server
Grundvoraussetzung für eine Secure-Shell-Verbindung ist ein Dienst auf
dem Zielgerät, der auf Netzwerkanfragen wartet. Dieser Dienst (sshd
)
horcht standardmäßig auf dem Port 22/TCP, kann aber auch beliebig
umkonfiguriert werden.
Um die Sicherheit vor Angriffen zu erhöhen, ändern die Administratoren
von Internet-Servern meist den Port auf einen anderen Wert. Angreifer
müssen dann vor dem Angriff zunächst den Port ermitteln, aber auch der
Administrator muss den geänderten Port bei seinem Zugriff über den
Parameter -p <Portnummer>
angeben. Nur wenn der Port auf dem Standard
(22) bleibt, kann die Portangabe wegfallen.
Der Benutzername wird über den Parameter -l <Benutzername>
angegeben. Eine häufig genutzte Alternative ist das Setzen des
Benutzernamens, getrennt mit einem @
vor dem Servernamen.
Der Servername selbst muss zu einer IP-Adresse auflösbar
sein. Alternativ reicht auch eine IP-Adresse. OpenSSH beherrscht die
Protokolle IPv4 und IPv6. Ist eine IPv6-Adresse vorhanden, wird
zunächst der Zugriff über IPv6 versucht, erst danach über IPv4. Mit
den Parametern -4
und -6
lässt sich OpenSSH auch anweisen, das
jeweilige Protokoll zu benutzen.
Nun ein kleines Beispiel für den Zugriff auf einen Server
mit dem Namen server
und dem Benutzer user
. Der Port für
den Zugriff ist auf dem Standard (22) belassen und wird
daher nicht angegeben:
user@linux:~$ ssh user@server
The authenticity of host 'server (10.0.0.15)' can't be established.
RSA key fingerprint is 66:29:d6:04:c1:2e:82:32:8d:99:8a:6d:6a:6d:0b:57.
Are you sure you want to continue connecting (yes/no)?
Wie dem Beispiel zu entnehmen ist, fragt ssh
nicht sofort nach einem
Kennwort. Stattdessen konfrontiert es den Benutzer mit einem zu
bestätigenden ‘Fingerprint’. Dieser Fingerabdruck des Servers besteht
aus der Checksumme des für den Server generierten ‘Private
Key’. Anhand dieses Fingerabdrucks lässt sich der Server eindeutig
identifizieren.
Bei dem Zugriff im Beispiel handelt es sich um den ersten Versuch, mit
dem Server zu kommunizieren. Daher wird der Anwender aufgefordert, den
Fingerabdruck durch die Eingabe von yes
zu bestätigen. Ab sofort
merkt sich ssh
, dass dem Server unter der angegebenen Adresse mit
diesem Fingerabdruck vertraut wird, und legt in
~/.ssh/known_hosts
einen entsprechenden Eintrag ab.
Sollte sich der Fingerabdruck des Servers ändern oder der Server unter einer neuen Adresse erreichbar sein, meldet sich OpenSSH wieder mit einem entsprechenden Hinweis. So wird verhindert, dass der Benutzer einem fremden Server blauäugig sein Kennwort anvertraut.
Server und Client handeln nun die eigentlichen zur Kommunikation verwendeten Schlüssel aus. Das geschieht ohne Zutun des Benutzers im Hintergrund.
Erst jetzt verlangt ssh
das Kennwort. Aus dem eingegebenen Kennwort
wird lokal eine Prüfsumme (‘Hash’) errechnet und über die bereits
verschlüsselte Verbindung an den Server übertragen. Der Server
überprüft anhand der dort vorliegenden Prüfsumme die Korrektheit des
eingegebenen Passwortes.
Hat der Benutzer das korrekte Kennwort getippt, startet die für den Benutzer auf dem Server eingetragene Shell, und er kann interaktiv Befehle ausführen.
Wie bei jeder lokalen Shell wird die über ssh
gestartete Shell jederzeit mit dem Befehl exit
oder der
Tastenkombination Strg+d
auf einer leeren Zeile beendet.
Mit Beendigung der Shell schließt sich auch automatisch die
ssh
-Verbindung, und der Benutzer ist zurück in der Umgebung seiner
lokalen Shell.
Im nächsten Artikel dieser Reihe werden wir auf die weiteren Möglichkeiten des Zugriffs auf den Server eingehen, speziell auf die Nutzung von ‘Public Keys’ statt eine Kennworts.