Login
Login-Name Passwort


 
Newsletter
Werbung

So, 23. April 2006, 00:00

Teil 2: Den Server absichern

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 &#91; ok &#93;
schroedi@mobil:~/.ssh$ sudo /etc/init.d/ssh restart
 * Restarting OpenBSD Secure Shell server... &#91; ok &#93;

Testen

ssh root@192.168.178.26

Sudo

Sudo ermöglicht es einem Benutzer, Programme oder Skripte mit den Rechten des Superusers root auszuführen. Dieser Benutzer muss in einer speziellen Datei sudoers festgelegt werden. Ebenfalls kann in dieser Datei festgelegt werden, wer welche Kommandos absetzen darf, als welcher Benutzer er das tun darf usw.

In der Regel sollte der Benutzer nach Eingabe von sudo Befehl sein User-Passwort, nicht das Root Passwort, zur Authentifizierung eingeben. Nach dieser Authentifizierung ermöglicht Sudo durch Setzen eines Zeitstempels die mehrfache Ausführung des sudo-Kommandos ohne erneute Authentifizierung.

Wie bereits in den ersten Zeilen von /etc/sudoers steht, müssen Sie diese Datei mit dem Programm visudo bearbeiten.

Kommentare (Insgesamt: 0 || Kommentieren )
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung