Teil 2: Den Server absichern
Root-Server-Workshop Teil 2.
Für Anregungen und Kritik benutzen Sie bitte die Diskussions-Seite zum Workshop oder die Mailingliste.
Rückblende
Das Feedback auf den ersten Teil des Workshops war im Großen und Ganzen positiv. Einige Anregungen aus dem Wiki möchte ich hier an die Leser weitergeben.
Netstat mit mehr Optionen
Zum Thema Netstat erwähnte »Heimwerker«, es wäre nützlich, netstat mit den Optionen »pantlu« zu verwenden.
netstat -anptlu | grep -v 127.0.0.1 oder netstat -pantlu # Pantlu kann man sich besser merken ;-)
Damit kann man sich die lokalen Verbindungen des Servers anzeigen lassen. Das macht durchaus Sinn, wenn man versucht, lokal auf seine Dienste zuzugreifen.
Sofern Sie noch keinen Rootserver besitzen und nur über rudimentäre Kenntnisse verfügen, dann testen Sie bitte vorher auf einem Dyndns-Rechner, denn einfach einen Rootserver mieten und nicht abzusichern ist wie einen geladenen Revolver im Kinderbett liegen zu lassen. Andere böse Zeitgenossen können Ihren Rootserver zu einer »Spamschleuder« machen und Gejammer und Ärger sind in den Foren oft genug zu hören.
Abgesehen davon können rechtliche Schritte gegen Rootserver-Besitzer eingeleitet werden, wenn dort Publikationen gefunden werden, die gegen geltendes Recht verstoßen.
Login absichern
SSH-Einstellungen
Root-Login verbieten
Zunächst wollen wir es unterbinden, dass sich Root direkt via SSH einloggen darf.
Das heisst im Umkehrschluss, dass Sie vielleicht zunächst einen User anlegen sollten, mit dem Sie sich dann auf dem Server anmelden. Denn wenn einmal die Tür dicht ist, dann kommen Sie nicht darum herum, das System im Rescue-Modus zu booten, um den Fehler wieder rückgängig zu machen.
Public-Key-Authentifizierung
Eine Möglichkeit ist die Authentifizierung anhand eines öffentlichen Schlüssels, der auf dem Client generiert wird und dann im Home-Verzeichnis des Benutzers unter .ssh/authorized_keys abgelegt wird.
Wollen Sie sich nun auf dem Server einloggen, dann prüft sshd die Datei und fordert Sie auf, das Passwort einzugeben. Haben Sie das korrekte Passwort und den privaten Schlüssel auf Ihrem Client, dann wird Ihnen der Zugang gewährt. Soweit zur Theorie.
Anlegen der Schlüssel
Die Schlüssel werden immer in einem sogenannten Schlüsselpaar erzeugt. Das heißt, es werden ein öffentlicher und ein privater Schlüssel erzeugt. Den öffentlichen Schlüssel können Sie gerne jederzeit überall hin exportieren, den privaten sollten Sie hüten wie Ihren Augapfel. Dieses Verfahren ist Ihnen vielleicht schon von gnupg bekannt.
Mit dem Befehl ssh-keygen -t rsa generieren Sie ein RSA-Schlüsselpaar.
schroedi@blubbi:~$ ssh-keygen -t rsa Generating public/private rsa key pair. Enter file in which to save the key (/home/schroedi/.ssh/id_rsa): Created directory '/home/schroedi/.ssh'. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/schroedi/.ssh/id_rsa. Your public key has been saved in /home/schroedi/.ssh/id_rsa.pub. The key fingerprint is: f7:90:a5:92:d6:f7:0c:16:10:fc:d0:e1:ef:33:62:4a schroedi@192.168.178.24 schroedi@blubbi:~$
Exportieren des Schlüssels auf den Server
Wenn Sie auf dem Zielserver schon das Verzeichnis .ssh vorfinden, haben Sie einen Schritt weniger zu tun, sonst sollten Sie es anlegen und mit den Rechten 700 versehen.
Im Zweifelsfall verwenden Sie die folgende Zeile, wobei zuerst getestet wird, ob das Verzeichnis vorhanden ist. Wenn nicht, wird es angelegt und mit den entsprechenden Rechten versehen. An dieser Stelle ist ssh sehr kleinlich, sollte es zu Anfang nicht klappen, dann prüfen Sie zunächst die Rechte.
ssh 192.168.178.26 "test -d .ssh || mkdir .ssh && chmod 700 .ssh"
Es geht aber auch einfacher: mit dem Befehl ssh-copy-id.
Den Key vom Server zum Client kopieren
In diesem Fall wird der Public Key vom Server auf den Client kopiert. Normalerweise muss dies nur in Ausnahmefällen sein. So zum Beispiel beim rsync-Backup - welches wir in einem späteren Teil des Workshops noch kennenlernen werden.
Sie könnten sich nun mit dem Passwort und dem Public Key vom Server aus auf dem Client anmelden.
ssh-copy-id -i ~/.ssh/id_rsa.pub schroedi@192.168.178.26
Vom Client wird der Key zum Server kopiert
ssh-copy-id -i ~/.ssh/id_rsa.pub schroedi@192.168.178.24
Dieser wird dann dort auf dem Server in der Datei ~/.ssh/authorized_keys abgelegt. Teilweise kann es erforderlich sein, dass Sie das Verzeichnis .ssh anlegen und dem Benutzer darin Schreibrechte geben müssen.
Sollten Sie sich einmal die Datei ~/.ssh/authorized_keys anschauen, dann werden Sie einen oder mehr dieser Keys finden.
Wenn Sie sich nun auf Ihrem Server einloggen, dann werden Sie immer nach dem Passwort gefragt, das Sie bei Generierung des SSH-RSA Schlüsselpaares festgelegt haben. Sollten Sie eine Standard-SSH-Installation verwenden, werden Sie danach gefragt. Falls dies nicht »ab Werk« klappen sollte, dann müssen Sie die Einstellungen in der Datei /etc/ssh/sshd_config aktivieren.
Aktivierung in sshd_config
Um jetzt nur noch Benutzer auf den Server zu lassen, die einen öffentlichen Schlüssel auf dem Server ~/.ssh/id_rsa.pub haben bzw. clientseitig in der Datei authorized_keys den entsprechenden Schlüssel haben, sollten Sie nun in sshd_config die folgenden Zeilen bearbeiten.
26c26 < PermitRootLogin yes --- > PermitRootLogin no 31c31 < #AuthorizedKeysFile %h/.ssh/authorized_keys --- > AuthorizedKeysFile %h/.ssh/authorized_keys
schroedi@mobil:~/.ssh$ sudo /etc/init.d/ssh reload Reloading OpenBSD Secure Shell server's configuration [ ok ] schroedi@mobil:~/.ssh$ sudo /etc/init.d/ssh restart * Restarting OpenBSD Secure Shell server... [ ok ]
Testen
ssh root@192.168.178.26
