In diesem Beitrag beschäftigen wir uns mit der detaillierten Konfiguration unseres SSH-Servers auf unserem Rootserver. Der SSH-Server ist der Dienst, der es uns ermöglicht eine SSH-Verbindung mit unserem Server aufzubauen. Es ist der einzige Punkt, über den wir unseren Server von überall erreichen und vollständig administrieren können. Deswegen liegt es in unserem Interesse, dass dieser so sicher wie möglich ist.

Auch in der Standardkonfiguration ist der SSH-Server nicht als unsicher anzusehen, dennoch lässt er sich an einigen Stellen nochmal deutlich optimieren. Man spricht in diesem Fall von einer “Härtung”. Dabei werden Features und Funktionen, die nicht benötigt werden, deaktiviert und weitere Einschränkungen vorgenommen. Das Ziel ist es, weniger Angriffsfläche für böse Hacker zu bieten und dabei alle selbst benötigten Funktionen zu behalten.

SSH-Audit

Bei ssh-audit handelt es sich um ein Python-Paket, mit dem man seinen SSH-Server prüfen kann. In der Standardkonfiguration lässt der SSH-Server auch Protokolle und Verschlüsselungsalgorithmen zu, die man heute nicht mehr unbedingt verwenden sollte. Entweder sind sie nicht mehr stark genug oder aber sie unterliegen dem Verdacht, eine NSA-Backdoor zu enthalten. Aus Kompatibilitätsgründen sind diese Verfahren dennoch im Standard aktiv. Mit einigermaßen aktuellen Geräten und Betriebssystemen wird man aber kein Problem haben, wenn man diese deaktiviert.

Um sich das ganze mal anzuschauen, installieren wir ssh-audit. Zur Installation wird Python benötigt. Wenn ihr den Beitrag Nützliche Tools auf dem Server umgesetzt habt, ist es bereits installiert. Ansonsten führt vorerst folgenden Befehl zur Aktualisierung der Paketquellen und Installation von Python3 aus:

1

sudo apt update && sudo apt install python3-pip

Jetzt kann ssh-audit mit folgendem Befehl mit dem Python3 Paketmanager pip3 installiert werden:

1

pip3 install ssh-audit

Solltet ihr bei der Installation folgende Meldung (in gelb) erhalten:

dann loggt euch einmal aus (exit) und wieder ein. Diese Meldung kann vorkommen, wenn man zum ersten Mal ein Paket installiert hat.

Um das Tool jetzt zu nutzen, müssen wir es nur mit ssh-audit aufrufen und noch sagen, welcher SSH-Server getestet werden soll. In diesem Fall unser eigener, also localhost.

1

ssh-audit localhost

Was wir jetzt zu sehen bekommen, gefällt uns gar nicht. Einige rote Einträge, gelbe Einträge sind ebenfalls dabei, das werden wir jetzt in den nachfolgenden Schritten beheben.

SSH-Serverkonfiguration anpassen

Die Konfigurationsdatei unseres SSH-Servers liegt unter /etc/ssh/sshd_config. Da es sich um eine Systemdatei handelt, kann sie nicht von einem normalen Benutzer angepasst werden, wir müssen unsere Befehle also als root ausführen und damit immer ein sudo voranstellen.

Zunächst legen wir ein Backup der Datei im gleichen Verzeichnis an und nennen es BACKUP_sshd_config.

1

sudo cp /etc/ssh/sshd_config /etc/ssh/BACKUP_sshd_config

Jetzt öffnen wir die Konfigurationsdatei mit unserem Editor:

1

sudo nano /etc/ssh/sshd_config

Ich werde nun in den nachfolgenden Unterkapiteln durch die einzelnen Punkte gehen, die angepasst werden. Ihr solltet diese Punkte ebenfalls von oben nach unten wiederfinden, sofern es sich um eine Debian Standardinstallation handelt. Falls nicht, enthält der Editor nano auch eine Suchfunktion. Dazu drückt ihr STRG+W (Mac: CONTROL+W), gebt das gewünschte Wort ein (sieht man unten links) und drückt ENTER.

Gibt es einen Treffer, springt der Cursor zu der gefundenen Stelle. Wenn das nicht die richtige Stelle ist, kann man auch weitersuchen, indem man erneut STRG+W (Mac: CONTROL+W) drückt. Das vorherige Suchwort ist dann bereits vorausgefüllt und man muss nur ENTER drücken, ohne etwas einzugeben.

HostKey

Es werden drei verschiedene HostKeys zur Verfügung gestellt. Diese schickt der Server an den Client bei einem Verbindungsaufbau. Wir kennen das von der Meldung beim ersten Verbindungsaufbau mit einem Server, dass der Schlüssel unbekannt ist und wir die Aufnahme des Schlüssels mit “yes” bestätigen sollen. Zukünftig sollen nicht mehr alle drei Schlüssel zur Auswahl stehen, sondern nur noch der sicherste davon. Um den Standard zu überschreiben, entfernen wir das Kommentarzeichen nur beim ed25519-Schlüssel, damit zukünftig nur noch dieser genutzt wird.

Aus

1
2
3

#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
#HostKey /etc/ssh/ssh_host_ed25519_key

wird

1
2
3

#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key

Ciphers and keyring

Unter der Überschrift # Ciphers and keying fügen wir folgende drei Zeilen ein:

1
2
3
4

# Ciphers and keying
KexAlgorithms curve25519-sha256@libssh.org
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com

Hier schränken wir die nutzbaren Verschlüsselungsalgorithmen ein und schließen als nicht mehr ganz so sicher geltende Verfahren aus. Das ist eine Einstellung die nachher für Veränderungen im ssh-audit sorgt.

Root-Login verbieten

Dies wurde bereits im Beitrag Debian Server / vServer grundlegend absichern durchgeführt, der Vollständigkeit halber ist es hier auch nochmal enthalten. Wir möchten nicht, dass root sich direkt auf dem Server per SSH einloggen kann. Stattdessen nutzen wir einen normalen Benutzer, der dann erst auf dem Server zu root werden kann oder aber sudo-Rechte hat.

1

PermitRootLogin no

Kein Login mit Passwort

Es ist besser, den Login per Schlüsseldatei zu nutzen. Dies könnt ihr im Beitrag SSH Login über Schlüsseldatei nachlesen und einrichten. Ein Passwort kann erraten werden, eine Schlüsseldatei die nur auf meinem Gerät liegt nicht. Deswegen deaktivieren die Möglichkeit des Logins per Passwort komplett.

1

PasswordAuthentication no

X11Forwarding

X11Forwarding ist eine Funktion, um einzelne grafische Anwendungen auf seinem Desktop anzuzeigen. Dies wird für gewöhnlich nie genutzt und da X11 nicht auf Sicherheit ausgelegt wurde, deaktivieren wir diese Option.

1

X11Forwarding no

Timeout definieren

Wenn eine Verbindung für einen längeren Zeitraum nicht genutzt wird, soll sie getrennt werden. Ungenutzte Verbindungen sind ein potenzielles Risiko. Hat man vergessen sich auszuloggen und eine andere Person hat daraufhin Zugriff auf das Gerät, könnte diese unberechtigt auf den Server zugreifen.

1
2

ClientAliveInterval 300
ClientAliveCountMax 2

ClientAliveInterval 300 bedeutet, dass alle 5 Minuten (300 Sekunden) geprüft wird, ob die Verbindung noch aktiv ist. ClientAliveCountMax 2 bedeutet, dass diese Verbindung zwei Mal weiterhin bestehen bleibt, wenn die Verbindung inaktiv ist und beim dritten Mal dann getrennt wird. Es werden also Verbindungen getrennt, die seit 15 Minuten inaktiv sind.

Erlaubte Benutzer einschränken

Um zufällige Verbindungsversuche möglichst früh schon zu blockieren, erlauben wir nur unserem eigenen Nutzer den Login. Diese Option muss am Ende der Datei ergänzt werden:

1

AllowUsers viertelwissen nutzername2 nutzername3

Es können mehrere Nutzer berechtigt werden, sollte das notwendig sein (durch Leerzeichen getrennt).

Speichern und schließen

Sind alle Anpassungen eingetragen, speichern wir die Änderungen und schließen die Datei mit
Win: STRG+O, ENTER, STRG+X
Mac: CONTROL+O, ENTER, CONTROL+X

Konfiguration testen und aktivieren

Da wir ausschließen wollen, dass sich in der Konfiguration ein Fehler eingeschlichen hat und wir uns damit aussperren, prüfen wir zunächst einmal, ob der SSH-Server die Konfigurationsdatei noch lesen kann. Dazu führen wir folgenden Befehl aus:

1

sudo sshd -t

Gibt es einen Fehler, werden diese angezeigt mit der Nummer der Zeile, in der der Fehler auftritt. Ist alles in Ordnung, wird nichts angezeigt.

Damit können wir die neue Konfiguration aktivieren mit:

1

sudo systemctl reload sshd

Die bestehende Verbindung wird dabei nicht getrennt und ihr solltet diese auch noch nicht beenden. Stattdessen öffnet ein neues Terminal-Fenster und prüft, ob ihr euch noch einloggen könnt.

Ist das der Fall, ist alles in Ordnung.

Wiederherstellung im Fehlerfall

Solltet ihr euch mit der neuen Konfiguration nicht mehr einloggen können, ist eine Einstellung nicht korrekt. Ihr solltet dann in der noch aktiven Verbindung das Backup zurückspielen und dieses wieder aktivieren:

1
2

sudo cp /etc/ssh/BACKUP_sshd_config /etc/ssh/sshd_config
sudo systemctl reload sshd

Danach sollte der Login wieder funktionieren und ihr probiert es nochmal von vorne aus.

SSH-Audit?

Schauen wir jetzt nochmal nach, was der ssh-audit zu unseren neuen Einstellungen sagt:

1

ssh-audit localhost

Wir sehen keine roten oder gelben Einträge mehr, damit haben wir eine gehärtete Konfiguration unseres SSH-Servers.