OpenSSH Public Key Authentifizierung - Teil 3

Autoren: Michael Gisbers and Christian Hesse

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 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 Konfiguration 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 zu 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 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 handelt es sich um Text, der einfach angezeigt wird. Hier kann der Administrator rechtliche Hinweise, Informationen zum Rechner bis hin zu ASCII-Grafiken hinterlegen.

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ürKonfigurationen oder erweiterte Möglichkeiten von Ihnen zu erhalten. Schreiben Sie eine E-Mail an info(at)linux-essentials.de, und wir veröffentlichen Ihre Anregungen und Vorschläge dann auf linux-essentials.de oder wir nehmen sie direkt in einen der nächsten LPI-Tipps des Monats auf. Außerdem können Sie auch über das Forum in der LPI Gruppe auf XING mit uns Kontakt aufnehmen.

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.