Tipp: Mehr zur OpenSSH Public Key Authentifizierung

OpenSSH Public Key Authentifizierung

Nachdem wir in dem letzten Artikel dieser Reihe schon die einfache Nutzung der Datei authorized_keys kennengelernt haben, geht es in dieser Folge um weitere Einsatzmöglichkeiten.

Darüber hinaus sollen natürlich auch einige wichtige Parameter für die Konfiguration eines OpenSSH-Servers oder -Clients nicht fehlen.

Automatische Ausführung von Befehlen

Die einfachste Art, Befehle mit OpenSSH auf einer entfernten Maschine ausführen zu lassen, ist, den Befehl direkt auf der Kommandozeile anzugeben.

Um die Beispiele zu vereinfachen, gehen wir in der Folge davon aus, dass lokal ein ssh-agent mit einem privaten Schlüssel läuft und der Benutzer auf dem Server in der Datei authorized_key den entsprechenden öffentlichen Schlüssel hinterlegt hat.

user@linux:~$ ssh user@server1 "hostname"
server1

Dies reicht natürlich in vielen Fällen aus. Allerdings bietet sich damit dem Anwender die Gelegenheit, jedes beliebige Kommando auszuführen.

Um das zu verhindern, nimmt man eine einfache Änderung an der Datei authorized_keys des Benutzers user auf dem Server server1 vor und bestimmt, welches Kommando bei einem Verbindungsaufbau startet.

Im Normalfall — also ohne Angaben — ist es die für den Benutzer in der Datei /etc/passwd voreingestellte Shell, z.B. /bin/bash oder /bin/zsh.

Wird dem öffentlichen Schlüssel in der Datei authorized_key ein command="hostname" in der gleichen Zeile vorangestellt, interessiert den Server der vom Client übergebene Befehl nicht mehr, und er führt nur noch den voreingestellten Befehl aus.

Es lässt sich also für jeden öffentlichen Schlüssel jeweils ein Kommando auf dem Server festlegen. Durch das Anlegen mehrerer Schlüsselpaare erfolgt die Steuerung eines Servers über die Schlüssel und die jeweils hinterlegten Kommandos.

OpenSSH Einstellungen auf dem Server

Neben den Schlüssel-spezifischen Einstellung kann auch der Server-Dienst konfiguriert und damit sein Verhalten beeinflusst werden. Dies geschieht in der Datei /etc/ssh/sshd_config.

Standardmäßig ist ein OpenSSH-Server auf allen Adressen bzw. Netzwerkschnittstellen erreichbar und antwortet auf Port 22. Mit  der Option ListenAddress binden Sie den Dienst an eine lokale Adresse; OpenSSH ist dann nur über diese Adresse im entsprechenden Netzwerk erreichbar. Außerdem kann der Standardport mit der Option Port verändert werden: So ist die Wahrscheinlichkeit eines Angriffes deutlich geringer, wenn der mutmaßliche Angreifer erst einmal nach einem offenen Port suchen muss, auf dem ein SSH-Server läuft. Die Kofiguration könnte also so aussehen:

ListenAddress 192.168.1.1
Port 2222

Die Optionen lassen sich auch mehrfach angeben, um den Dienst an mehrere Adressen und/oder Ports zu binden. Außerdem kann auch ListenAddress, getrennt durch einen Doppelpunkt, ein Port mitgegeben werden. So ist es möglich, den Dienst lokal auf Port 22 erreichbar zu machen, während er für alle anderen (0.0.0.0 steht für alle Adressen) auf Port 2222 lauscht:

Port 2222
ListenAddress 0.0.0.0
ListenAddress 192.168.1.1:22

Oftmals werden auf privaten Rechnern für die Benutzer leere Passwörter hinterlegt. Die Bequemlichkeit, beim Login einfach nur „Enter“ drücken zu müssen, siegt leider oftmals über die Sicherheit. Um nicht auch jedem von außen per Netzwerk die Verbindung und damit die Übernahme eines Rechner zu ermöglichen, sollte zumindest die entsprechende Option im OpenSSH-Server aktiviert werden.
Login-Versuche schlagen damit grundsätzlich fehlt, wenn ein leeres Passwort hinterlegt ist:

PermitEmptyPasswords no

Auch direkte root-Logins sind unerwünscht, ist doch root auf jedem Linux-Rechner standardmäßig vorhanden und damit der Benutzer,  mit dem die meisten Angriffe per SSH ausgeführt werden. Ein Kompromiss ist hier, den Login nur ohne Passwort zu erlauben. Damit ist keineswegs ein leeres Passwort gemeint, stattdessen gelingt der Login nur über spezielle Authentifizierungsverfahren wie Public-Key-Authentifizierung, wie wir Sie bereits kennengelernt haben.

PermitRootLogin without-password

Bleibt eine SSH-Verbindung bei Inaktivität über längere Zeit bestehen, wächst die Gefahr von Verbindungsabbrüchen. Die Option TCPKeepAlive kann hier Abhilfe schaffen: Statt einfach untätig zu warten, werden regelmäßig Netzwerkpakete ausgetauscht, die den beteiligten Netzwerkgeräten eine aktive Verbindung signalisieren.

TCPKeepAlive yes

Ein SSH-Server kann dem Client schon vor der Authentifizierung einen Banner übermitteln.

Banner /etc/issue.net

Dabei haldelt es sich um Text, der einfach angezeigt wird. Hier kann der Administrator rechtliche Hinweise, Informationen zum Rechner  bis hin zu ASCII-Grafiken hinterlegen.

user@linux:~$ ssh user@server1
       Welcome to          ___
  ___ ___ _____  _____ ___<  /
 (_-</ -_) __/ |/ / -_) __/ /
/___/\__/_/  |___/\__/_/ /_/
user@server1:~$

Darüber hinaus gibt es zahlreiche weitere Einstellungen, die Sie in der Konfiguration anpassen können. Ein Blick in die Datei /etc/ssh/sshd_config oder in die Manpage via man sshd_config lohnt sich.

OpenSSH-Einstellungen auf dem Client

Wie auf dem Server gibt es auch auf dem Client zahlreiche Konfigurationsoptionen, allerdings auf verschiedene Dateien verteilt. Globale Einstellungen, die für jeden Benutzer gelten, nimmt der Administrator in der Datei /etc/ssh/ssh_config vor. Für jeden Benutzer kann er zusätzlich eine Datei config innerhalb dessen Home-Verzeichnisses anlegen. Im Verzeichnis .ssh erfolgen individuelle Einstellungen für den Benutzer (z.B. /home/user/.ssh/config). Die Optionen sind hier dieselben wie in der globalen Konfiguration.

Eine interessante Einstellung, um bei Zugriff auf einen Server dessen Integrität auf einen Blick nachzuvollziehen, ist VisualHostKey yes. Nach dem Eintrag in eine der genannten Dateien erfolgt die Ausgabe des vom Server übergebenen öffentlichen Schlüssels als ASCII-Grafik

user@linux:~$ ssh user@server1
Host key fingerprint is 7f:b7:67:a0:a8:a6:4a:39:2f:9e:ff:c0:a6:a8:ad:93
+--[ECDSA  256]---+
|                 |
|                 |
|                 |
|                 |
|        S        |
|     o   .    .  |
| .  + +   ...... |
|E. o.* .. .... .o|
|o+o.=+++o.    .o |
+-----------------+
user@server1:~$

Die so erzeugten Bilder lassen sich oft einfacher überprüfen als die ausgegebenen Fingerprints; Administratoren erkennen schon nach  kurzer Zeit den Unterschied zwischen den Servern anhand dieser Bilder und stellen so fest, ob sich am Server der Schlüssel geändert hat.

Eine dritte Möglichkeit, Einstellungen zu ändern, ist v.a. für kurzfristige Änderungen interessant. Soll beispielsweise die ASCII-Grafik, obwohl grundsätzlich eingeschaltet, für einen Server nicht aktiv sein, ändern Sie über den Parameter -o eine solche Eigenschaft:

user@linux:~$ ssh -o "VisualHostKey no" user@server1
user@server1:~$

Der Parameter kann auch mehrfach angegeben werden, um mehrere Eigenschaften für eine Verbindung zu verändern. Vielleicht ist Ihnen beim Verändern der o.g. Einstellung schon aufgefallen, dass in der Konfigurationsdatei ein Host * vor den Zeilen mit den Einstellungen steht. Diese Zeile zeigt an, dass alle folgenden Einstellungen für alle
aufgerufenen Hosts gilt, solange keine weitere Host-Zeile folgt.

Speichern wir nun innerhalb der Konfigurationsdatei zusätzlich den folgenden Block, gelten die Einstellungen, abweichend von den Vorgaben, nur für den Server server1.

Host server1
 Port 2222
 User root
 Hostname 192.168.1.1

Die im Beispiel genutzten Einstellungen erlauben es uns, als normaler Benutzer ohne Angabe von root@ vor dem Hostnamen oder -l root als Parameter statt des lokalen Benutzernamens einen anderen anzugeben und auch die IP-Adresse sowie den Port für den Zugriff direkt mitzugeben.

Ohne diese Einträge müsste der Zugriff wie folgt aussehen.

user@linux:~$ ssh -p 2222 root@192.168.1.1
root@server1:~$

Mit den Einträgen ist es viel einfacher.

user@linux:~$ ssh server1
root@server1:~$

Auch für die Client-seitigen Einstellungen gibt es eine Manualpage, die Sie mit dem Kommando man ssh_config aufrufen.

Hiermit beenden wir zunächst den Bereich des OpenSSH und würden uns freuen, weitere interessante Beispiele für Konfigurationen oder erweiterte Möglichkeiten von Ihnen zu erhalten. Schreiben Sie eine E-Mail an info@linux-essentials.de, und wir veröffentlichen Ihre Anregungen und Vorschläge dann auf http://linux-essentials.de oder nehmen sie direkt in einen der nächsten LPI-Tipps des Monats auf.

Der nächste Artikel dieser Reihe behandelt übrigens das Thema „Zertifikate mit OpenSSL“. Dabei geht es zunächst weniger um das Erstellen und Zertifizieren, sondern um das Erkennen, ob Zertifikate gültig sind.


Dieser Text ist im Rahmen des Tipp des Monats von Michael Gisbers und Christian Hesse auf der Website des LPI Central Europe unterstützt von der Open Source Press veröffentlicht worden.