Tipp: OpenSSH und authorized_keys
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.