SSH Absichern: So härtest du SSH auf einem Raspberry Pi/Linux Server mit Debian (Grundlagen)

SSH ist das Standard-Protokoll schlechthin, um Linux-Systeme zu administrieren. Über die Standardeinstellungen hinaus sollte man jedoch ein paar Sicherheitsvorkehrungen treffen – vor allem dann, wenn das System per Internet erreichbar ist.

Vorbereitungen

Falls noch nicht geschehen, installiere zuerst einen SSH-Server. Dies variiert etwas, je nach Plattform und Betriebssystem.

SSH auf dem Raspberry Pi aktivieren

Auf dem Pi lässt sich dies über den Aufruf von sudo raspi-config schnell erledigen: Navigiere zu 3 Interface Options und I2 SSH. Sobald du der Nachfrage zustimmst, ist SSH aktiv und mit einen SSH-Client kann auf die IP-Adresse oder den Hostname deines Pis zugegriffen werden.

SSH auf anderen Linux-Systemen aktivieren

Mietest du einen virtuellen Server bei einem Hoster, ist SSH in der Regel bereits aktiviert. Bei selbst aufgesetzten VMs muss ggf. vorher ein SSH-Server installiert werden. Am verbreitesten ist OpenSSH. Unter Debian/Ubuntu lässt er sich wie folgt installieren und aktivieren:

sudo apt install openssh-server
sudo systemctl start sshd

Absichern des SSH-Servers

Die zentrale Konfigurationsdatei des OpenSSH-Servers ist /etc/ssh/sshd_config – viele der folgenden Einstellungen werden wir darin vornehmen. Sie ist hier dokumentiert. Du solltest die Konfigurationsdatei mit root-Rechten und einem Texteditor deiner Wahl (etwa nano oder vim) öffnen, um die Einstellungen zu prüfen bzw. Änderungen vornehmen zu können.

Viele der genannten Konfigurationseinstellungen sind bereits in der Datei enthalten, aber entweder nicht aktiviert oder sogar auskommentiert. Letzteres ist der Fall, wenn die Zeile mit einer Raute # beginnt. Hier kannst du einfach die Raute entfernen und die vorhandenen Zeilen ggf. anpassen, falls nötig.

#PermitEmptyPasswords no

Leere Passwörter verbieten

Linux erlaubt es theoretisch, Konten mit leeren Passwörtern zu erstellen. Aus Sicherheitsgründen sollte man das natürlich nicht tun. Falls es aus irgend einem Grund dennoch geschieht, macht es Sinn, zumindest den Login per SSH damit zu verbieten. Dies ermöglicht die Einstellung PermitEmptyPasswords:

PermitEmptyPasswords yes

Keine direkte Anmeldung des „root“ Benutzers

Der „Administrator“ unter Linux heißt „root“ und kann sich auch per SSH anmelden. Grundsätzlich ist es sicherheitstechnisch schlechte Praxis, sich direkt als root anzumelden. Zumal dies dazu verleitet, alle Befehle mit diesem Konto auszuführen, auch wenn dies gar nicht immer notwendig ist. Am besten deaktiviert man den SSH-Login für root daher:

PermitRootLogin no
# Alternativ
PermitRootLogin prohibit-password

Aber Achtung: In diesem Falle solltest du zuvor mindestens ein weiteres Konto erstellen, dass root-Rechte per sudo erlangen kann! Ansonsten lassen sich administrative Aufgaben nicht mehr per SSH ausführen bzw. man sperrt sich sogar komplett aus, wenn überhaupt kein weiteres Konto existiert.

Falls du den Login für root nicht gänzlich deaktivieren möchtest, kann prohibit-password ein Kompromiss darstellen. Dadurch ist die Anmeldung nur per SSH-Schlüssel notwendig. Dies ist übrigens grundsätzlich eine sinnvolle Idee, da ein privater Schlüssel schwieriger mit roher Gewalt zu knacken ist als ein Passwort.

Wer bereits komplett auf SSH-Schlüssel setzt, kann die Anmeldung per Passwort ggf. auch komplett deaktivieren:

PasswordAuthentication no

Man sollte allerdings sicherstellen, dass die SSH-Schlüssel sicher aufbewahrt werden. Ansonsten besteht auch hier das Risiko, sich selbst auszusperren.

SSH-Zugriff für bestimmte Benutzer erlauben/verbieten

Auf einigen Systemen gibt es auch Systembenutzer, die nur auf dem selbst benötigt werden und sich nicht per SSH verbinden können sollen. Hierfür gibt es AllowUsers/DenyUsers. Ich würde grundsätzlich Whitelisting bevorzugen, da es weniger fehleranfällig ist. Mehrere Benutzer lassen sich mit einem Leerzeichen getrennt angeben:

AllowUsers daniel max

Handelt es sich um eine größere Anzahl Benutzer, kann man eine Gruppe verwenden und diese entsprechend mit AllowGroups/DenyGroups angeben.

X11 Weiterleitung deaktivieren

Die X11-Weiterleitung ermöglicht es, ein grafisches Programm auf dem entfernten Server zu starten und dessen Oberfläche (per X-Server dargestellt) auf unserem Client darzustellen. Der Server benötigt dafür keine grafische Oberfläche. Das kann praktisch sein, aber bietet theoretisch zusätzliche Angriffsfläche. Wer es nicht braucht, sollte es daher deaktivieren – sicherheitstechnisch ein guter Grundsatz. Unter Debian und dem Raspberry Pi OS ist es nämlich standardmäßig aktiviert. Zur Deaktivierung setzt man folgende Eigenschaft auf no:

X11Forwarding no

Alte Protokollversionen verbieten

Das SSH-Protokoll ist bereits seit etlichen Jahren in Version 2 verfügbar, die Schwachstellen gegenüber V1 behebt. Standardmäßig wird aber auch die alte Version 1 akzeptiert. Besser ist es, explizit nur Version 2 zu erlauben:

Protocol 2

Maximale Authentifizierungsversuche begrenzen

Über MaxAuthTries kann angegeben werden, nach wie vielen (vergeblichen) Authentifizierungsversuchen die Verbindung getrennt wird. Unter Debian und dem Raspberry Pi OS ist diese Einstellung deaktiviert. Ein sinnvoller Wert ist z.B. 3:

MaxAuthTries 5

Allerdings ist dies kein Schutz vor Brute-Forcing (Roher Gewalt). Ergänzend macht es daher Sinn, Programme wie Fail2ban einzusetzen: Es überwacht die Anzahl fehlgeschlagener Anmeldeversuche und sperrt IP-Adressen eine gewisse Zeit aus, wenn ein festgelegtes Limit erreicht ist. Entsprechend eingerichtet, wird Brute-Forcing dadurch massivst erschwert, sodass es bei einem sicheren Passwort alles andere als praxistauglich ist, damit erfolgreich anzugreifen.

Reverse-DNS Auflösung abschalten

Standardmäßig prüft SSH den Reverse-DNS Eintrag eines Clients. Das bringt in den meisten Fällen wenig – zumal typische DSL-Anschlüsse ohnehin in der Regel keinen (sinnvollen) Reverse-DNS Eintrag besitzen (wie etwa kunde19823761987283.isp.de). Auch wenn dies kein direktes Sicherheitsrisiko ist, erhöht es theoretisch die Angriffsfläche ohne Mehrwert. Außerdem kann die DNS-Anfrage ggf. das Anmelden verzögern, daher würde ich es deaktivieren:

UseDNS no

Testen der Änderungen

Grundsätzlich solltest du Änderungen am SSH-Daemon immer zuerst in einer weiteren Sitzung testen und die ursprüngliche Sitzung geöffnet lassen! Falls dabei Probleme festgestellt werden, kann man diese mit der noch offenen Sitzung reparieren. So verhindert man, sich bei fehlerhaften Konfigurationsänderungen selbst auszusperren.

Damit diese wirksam werden, muss zunächst der SSH-Server neu gestartet werden:

sudo systemctl restart sshd

Dies hat keine Auswirkungen auf die Sitzung, in der man den Befehl ausführt. Daher sollte man diese Sitzung offen halten und zum Testen nun eine zweite öffnen. Funktioniert alles, kann die offen gehaltene Sitzung geschlossen werden.

Sollte ich den SSH-Port ändern?

Manche Beiträge empfehlen, den Standardport 22 zu ändern. Dies halte ich im Sinne der Sicherheit für wenig sinnvoll: Es gibt nur maximal 65.535 Ports. Mit einem Portscan sind die relativ einfach und schnell durchprobiert. Einen Angreifer hindert das eben so wenig wie eine angelehnte statt einer offenen Tür. Wesentlich mehr trägt man zur Sicherheit bei, wenn man die Tür schließt und am besten verschließt. Beim SSH-Server wäre das beispielsweise die Nutzung von starken Passwörtern oder noch besser SSH-Schlüsseln.

Gegenüber den minimalen Vorteilen bringt die Änderung der Standardports auch leichte Nachteile: Man muss den selbst gewählten Port bei einer Verbindung explizit angeben. Wer damit leben kann, der kann den Port natürlich ändern – darüber hinaus schadet es nicht. Aber man sollte sich im klaren sein, dass das keine wirksame Sicherheitsmaßnahme ist. Wer sich um die Sicherheit seines Servers sorgt, erreicht mit wirkungsvollen Schutzmaßnahmen statt dem verstecken von Diensten mehr. Neben den bereits genannten Beispielen kann man die Sicherheit etwa durch 2-Faktor Authentifizierung zusätzlich verbessern. Das nutzt wesentlich mehr, da sich eine Multi-Faktor-Authentifizierung nicht so einfach mit einem Portscan umgehen lässt.

Weitere Schutzmaßnahmen

An dieser Stelle sei auch noch darauf hingewiesen, dass dies nur Beispiele sind. Es gibt weitere sinnvolle Maßnahmen, welche die Sicherheit erhöhen können. Dies betrifft nicht nur den SSH-Server. Das regelmäßige einspielen von Aktualisierungen ist beispielsweise eine Grundlage für sichere Systeme. Vor allem Sicherheitsaktualisierungen sollten so schnell wie möglich eingespielt werden, am besten automatisch.

„Sicherheit“ ist ein Prozess – kein Zustand, den man wie ein Projektziel erreicht und danach abhaken kann. Zumal man bei diesem Begriff nicht nur an Angriffe von außen denken sollte. Auch z.B. Hardwaredefekte können die Sicherheit der gespeicherten Daten gefährden, weswegen man auch ein Backup-Konzept haben sollte. Diese Themen werden wir noch in einen Beiträgen genauer anschauen.