OpenSSH Tutorial – Teil 2: Grundlegende Absicherung

Nachdem wir im ersten Teil den OpenSSH-Server auf dem Linux Rechner aufgesetzt und danach jeweils erfolgreich eine Verbindung mittels Putty, mittels OpenSSH unter Linux und mittels OpenSSH für Windows hergestellt haben, soll es in diesem (zweiten) Teil der Artikelserie darum gehen, wie man seinen OpenSSH-Server absichert.

Standard Port ändern

Als Erstes sollten wir den Port ändern, auf dem der OpenSSH-Server läuft. Doch warum das? Hierbei geht es um einen klassischen Fall von Sicherheit durch Obskurität (engl. Security by Obscurity). Theoretisch verändert sich der Grad der Sicherheit nicht. Praktisch zeigt sich jedoch, dass die Anzahl der Attacken auf den SSH-Server sinkt. Dies liegt daran, dass viele Angreifer nur auf Port 22, den Standard-SSH-Port, scannen. Ändern wir den Port, fallen wir aus dem Schema. Sicher kann jemand, der speziell unseren Server als Angriffobjekt auserkoren hat, einen Portscan vornehmen, dennoch lohnt sich die Maßnahme, um die eben angesprochenen “planlosen” Scanner auszuschließen.

Um den Port zu ändern, müssen wir eine Änderung in der sshd_config des OpenSSH-Servers vornehmen. Öffnet hierzu einen Terminal auf dem Rechner, auf dem euer OpenSSH-Server läuft.

sudo vim /etc/ssh/shhd_config

In der sshd_config suchen wir nun die Zeile “Port 22” und ersetzen diese durch “Port X”. (Wobei X für einen Port eurer Wahl steht.) Beachtet bei der Portwahl, dass ihr keinen Port wählt, der schon in Benutzung ist. Läuft auf eurem Linux Rechner also zum Beispiel ein Webserver auf Port 80, so eignet sich Port 80 logischerweise nicht mehr als neuer Port für euren OpenSSH-Server.

Nachdem ihr den Port angepasst habt, speichert ihr die Änderungen, schließt die sshd_config und startet den OpenSSH-Dienst neu.

sudo service ssh restart

Hinweis: Wer mit der Bedienung von VIM nicht klarkommt, kann in den Befehlen auch jeweils das “vim” durch ein “nano” ersetzen.

LogLevel erhöhen

Damit der OpenSSH-Server fehlerhafte Anmeldungen und potenzielle Angriffe protokolliert, müssen wir das Log-Level anpassen. Dies geht ebenfalls in der sshd_config.

sudo vim /etc/ssh/shhd_config

Standardmäßig loggt der OpenSSH-Server nur wenig mit. Wenn der Verdacht aufkommt, dass der Dienst unter “Beschuss” steht oder gerne detaillierte Logs haben möchte, der sollte das LogLevel in der sshd_config anpassen. Hierzu muss folgende Zeile angepasst werden.

#alt
LogLevel INFO

#neu
LogLevel VERBOSE

Wie auch schon bei der Portänderung muss der OpenSSH-Dienst nach dem Speichern der Änderungen noch neu gestartet werden.

sudo service ssh restart

Ist das Loglevel auf “VERBOSE” gestellt, schreibt der OpenSSH-Server die Logs nach “/var/log/auth.log”.
Um einen schnellen Blick auf eventuell fehlgeschlagene Logins zu werfen, kann folgender Befehl behilflich sein.

cat /var/log/auth.log | grep "Failed"

(Der obige Befehl kann immer nur eine Hilfe sein und ersetzt natürlich keinen ausführlichen Blick auf das Logfile.)

Root-Login verbieten

Eine weitere Möglichkeit zum Absichern des OpenSSH-Servers ist es, die Anmeldung als “root” zu verbieten und gegebenenfalls sogar nur bestimmte Nutzer zuzulassen. Auch hierzu müssen wieder Änderungen in der sshd_config vorgenommen werden.

sudo vim /etc/ssh/shhd_config

Um den Login als Root zu unterbinden muss die Direktive “PermitRootLogin” angepasst werden.

#alt
PermitRootLogin yes

#neu
PermitRootLogin no

Steht die Direktive auf no, kann sich niemand mehr als root einloggen. Sollte man selbst als Nutzer mal Root-Rechte benötigen, kann man nach dem Login mittels “su” oder “sudo” erhöhte Rechte akquirieren.

Nutzer-Whitelist anlegen

Ein weiterer Schritt ist das Anlegen einer Whitelist mit erlaubten Nutzern. Möchte man zum Beispiel, dass sich nur die Benutzer(-konten) “raffael” und “peter” anmelden können, so muss folgende Zeile in die sshd_config eingefügt werden.

AllowUsers raffael peter

(Ist die Direktive AllowUsers schon in der sshd_config vorhanden, so muss diese natürlich angepasst und nicht ein zweites Mal eingefügt werden.)

Wenn man sogar weiß, dass ein bestimmter Nutzer immer dieselbe IP-Adresse hat (was bei DSL-Anschlüssen ohne Weiteres ja leider nicht der Fall ist), so kann man die Whitelist noch restriktiver gestalten.

AllowUsers raffael@192.168.2.100

Die obige IP-Adresse muss dann natürlich durch eure angepasst werden und dient hier nur exemplarisch. Der Aufbau mit Angabe eines Hosts geschieht nach dem Schema: user@host.

Fazit

Das war auch schon der zweite Teil. Im dritten Teil geht es dann um die Einrichtung der Anmeldung am SSH-Server mittels Private/Public-Key-Verfahren. Wer wissen möchte, was bisher geschehen ist, kann gerne auch noch einen Blick auf den ersten Teil der Artikelserie werfen.