SSH-Schlüssel, Port ändern und Anmeldung als Root verwehren

Nachdem mir meine Zugangsdaten zum vServer übergeben worden waren, war meine erste Aktion mit dem neuen SpielArbeitsgerät den SSH-Zugang abzusichern. Die folgende Anleitung zeigt in Kürze, wie man verhindert, dass Root sich per SSH anmelden darf, SSH auf einem anderen Port lauscht und eine Anmeldung nur noch mit einem gültigen SSH-Schlüssel möglich ist und das Einloggen per Passworteingabe deaktiviert wird.
Diese Prozedur ist bei jedem öffentlich zugänglichen Server sinnvoll, wie ein Vorfall letzte Woche wieder einmal gezeigt hat. In einer größeren Institution wurde ein Server kompromittiert, bei dem sich der Angreifer mit Hilfe einer Wörterbuch-Attacke direkt Rootzugriff über SSH verschaffen konnte, indem er innerhalb weniger Stunden ca. 40.000 Passwörter ausprobieren durfte. Software wie denyhosts, fail2ban oder eine Firewalleinstellung, die nur Zugriff aus "vertrauenswürdigen" Netzen erlaubt und natürlich ein stärkeres Passwort, wäre hier eine Möglichkeit gewesen den Einbruch zu verhindern.
Mein kleines Projekt bietet mir die einfache Möglichkeit auf noch mehr Sicherheit, da außer mir selbst niemand Shellzugriff benötigt und nichts dagegen spricht den berechenbaren Namen des Root-Zugangs zu deaktivieren und nur noch die Authentifizierung per SSH-Public-Key-Verfahren zu erlauben. Bevor das geschieht, muss man natürlich einen weiteren, unprivilegierten Benutzer mit adduser hinzufügen.

Schlüsselerzeugung

ssh-keygen

Ohne weitere Argumente erstellt dieser Befehl einen privaten und öffentlichen RSA-Schlüssel für die SSH-Protokollversion 2 auf dem lokalen Rechner. Bejaht man alle folgenden Fragen, wird das Schlüsselpaar in ~/.ssh/ gespeichert. Ebenso wird man nach einem Passwort gefragt, um den privaten Schlüssel später entsperren zu können. Ich empfehle eines zu setzen, auch wenn man dadurch einmal pro Sitzung das Passwort eingeben muss.

Öffentlichen Schlüssel auf den Server transferieren

ssh-copy-id user@euervps123.de

Der öffentliche RSA-Schlüssel befindet sich danach auf eurem Server in ~/.ssh.

Einloggen

Funktioniert wie bisher,

ssh user@euervps123.de

nur dass ihr jetzt das Passwort zum Entsperren des privaten Schlüssels auf eurem Rechner eingeben müsst. Die Rechte der privaten Schlüsseldatei id_rsa müssen restriktiv sein.

chmod 600 ~/.ssh/id_rsa

Schlüssel ohne Eingabe des Passworts benutzen

Unter Gnome 3 genügte bei mir

ssh-add

auszuführen, um den privaten Schlüssel dem Authentifizierungsagenten, ssh-agent, hinzuzufügen, der hier durch die Anwendung gnome-keyring bereitgestellt wird. Nach einmaliger Eingabe des Passwortschutzes für den privaten Schlüssel ist dieser die gesamte Sitzung ohne weitere Passwortabfrage benutzbar.
Arbeitet ihr ohne X auf der Konsole müsst ihr zuerst den

ssh-agent zsh

mit eurer bevorzugten Shell aufrufen und könnt danach den privaten Schlüssel wieder wie oben beschrieben mit ssh-add für die Sitzung dauerhaft entsperren.

Root-Zugang deaktivieren, Port verändern und Passwort-Authentifizierung abschalten

Hierzu muss die Datei /etc/ssh/sshd_config auf dem Server angepasst werden.
Wichtig! Bevor ihr die Veränderung vornehmt, solltet ihr absolut sicher sein, dass ihr euch mit dem neu generierten Schlüssel anmelden könnt. Ebenso müsst ihr unbedingt die Einstellungen der Firewall so anpassen, dass ein Anmelden über den neuen SSH-Port erlaubt ist. (siehe nächster Beitrag).
Folgende Optionen werden geändert:

Port 44443
PermitRootLogin no
RSAAuthentication yes
PubkeyAuthentication yes
PasswordAuthentication no
X11Forwarding no

Fazit

Der Port kann im Prinzip beliebig gewählt werden. Die Liste der standardisierten Ports hilft bei der Entscheidung. Der Wechsel von Port 22 auf z.B. Port 44443 lässt die Mehrzahl automatischer Programme ins Leere laufen, die nur überprüfen, ob auf dem Standardport ein SSH-Dienst angeboten wird. Anmelden kann man sich ab sofort mit

ssh -p 44443 user@euervps123.de

Das Abschalten der Passwort-Authentifizierung macht Wörterbuch-Attacken aussichtslos. Das Deaktivieren des Root-Logins erzwingt die Anmeldung mit einem unprivilegierten Benutzer, so dass ein Angreifer nicht nur die Hürde des SSH-Schlüssels überwinden, sondern noch ein weiteres Passwort in Erfahrung bringen muss.
Sicherheit ist ein Prozess, heißt es so schön. Für mein spezielles Benutzerszenario funktioniert dieser Weg. Fehlerhaft konfigurierte Dienste und Sicherheitslücken kann aber auch diese Anleitung nicht verhindern.

Links

https://help.ubuntu.com/community/SSH/OpenSSH/Configuring
http://bodhizazen.net/Tutorials/SSH_keys
Sicherer Datentausch: Ein sftp-Server mit chroot