Wie kann ich den SSH-Dienst auf meinem Linux Server absichern?



In diesem Artikel beschreiben wir die Möglichkeit den SSH-Dienst auf Ihrem Linux Server abzusichern am Beispiel eines OpenSSH Servers.

Wir empfehlen allen Kunden, die einen V-Power Server, einen Dedi-Server oder auch einen Multiserver bei STRATO betreiben, den SSH-Dienst zu konfigurieren. Dies kann mit den folgenden Schritten vorgenommen werden, wobei Schritt 3 ein optionales Vorgehen ist:

Inhaltsverzeichnis
1  Einen gesonderten Nutzer anlegen
2  Das Login für den Nutzer root verbieten
3  Das Login nur via PubKeyAuthentication erlauben
3.1 SSH Public Key Einrichtung mit dem Open SSH Client (Linux, MacOS X)
3.2 SSH Public Key Einrichtung mit PuTTy (Windows)


1 Einen gesonderten Nutzer anlegen
Es ist nötig auf dem System einen Nutzer anzulegen, bevor das Login für den Nutzer root verboten wird.

Wir empfehlen die folgende Vorgehensweise:

Einen Nutzer zugehörig zur Gruppe users und mit einem Heimatverzeichnis in /home anlegen:

useradd -g users -d /home/[nutzername] -s /bin/bash [nutzername]

Bitte ersetzen Sie [nutzername] mit einem selbst gewählten Namen (ohne Umlaute, oder Leerzeichen).

Passwort für den neuen Nutzer vergeben:

passwd [nutzername]

Das Heimatverzeichnis für den neuen Nutzer ist allerdings noch als Nutzer root manuell anzulegen:

mkdir /home/[nutzername]

Das neue Verzeichnis dem neuen Nutzer zuordnen:

chown [nutzername]:users /home/[nutzername]/


Bevor Sie nun mit dem nächsten Schritt fortfahren ist es sinnvoll zu prüfen, ob ein SSH-Login mit den neuen Nutzerdaten auch möglich ist.

Achtung Erst nach einem erfolgreichem Login sollte der nächste Schritt vorgenommen werden


2 Das Login für den Nutzer root verbieten
Nachdem Sie im ersten Schritt einen weiteren Nutzer angelegt haben, ist es sinnvoll das Login für den Nutzer root komplett zu deaktivieren.

Sollte Ihr Server über eine serielle Konsole verfügen, ist das Login auf Ihrem Server selbstverständlich weiterhin als Nutzer root möglich.
Beachte auch Wie erzeuge ich eine Verbindung zu meinem Dedi-Server über die RemoteConsole?

Wir empfehlen die folgende Vorgehensweise:

Ändern Sie in der Datei /etc/ssh/sshd_config die Zeile

PermitRootLogin yes

in

PermitRootLogin no

Nun ist es noch nötig die Konfigurationsdateien des Dienstes neu einzulesen:

/etc/init.d/ssh reload (Debian/Ubuntu)
/etc/init.d/sshd reload (SUSE)

Nun ist es nicht mehr möglich sich via SSH als Nutzer root auf dem System einzuloggen. Verwenden Sie nun dazu bitte den neu angelegten Nutzernamen mit dem entsprechendem Passwort. Nach dem erfolgreichen Login verwenden Sie bitte den Befehl su -l, um eine Shell mit veränderter Identität zu starten. Wenn Sie keinen Nutzernamen angeben, wird automatisch der Nutzer root gewählt und Sie werden aufgefordert das root-Passwort einzugeben.

Nach erfolgreicher Eingabe des Passwortes können Sie nun in gewohnter Art und Weise fortfahren als Administrator (root) zu arbeiten.


3 Das Login nur noch via PubKeyAuthentication erlauben
Eine weitere Konfigurationsänderung, die Ihren Server noch wirkungsvoller gegen SSH-Einbruchsversuche schützt, ist die komplette Umstellung des Authentifizierungsverfahrens auf SSH Public Key Authentifizierung. Damit ist für die Benutzerauthentifikation zwingend das Vorhandensein einer Schlüsseldatei auf dem Rechner des Benutzers nötig, der sich auf Ihrem Server einloggen möchte. Eine Authentifikation mittels Passworteingabe beim SSH-Login ist dann nicht mehr möglich.

Selbstverständlich bedarf die Aufbewahrung Ihres privaten Schlüssels einer hohen Sorgsamkeit. Empfehlenswert ist dazu z. B. die Aufbewahrung desselben in einem verschlüsseltem Container, oder auf einem externen Datenträger (USB-Stick). Auch ist Sicherheitskopie der privaten Schlüsseldatei an einem geeignetem Ort ausgesprochen ratsam.

Wir empfehlen die folgende allgemeine Vorgehensweise:
  • Sie erstellen das nötige Schlüsselpaar (privater und öffentlicher Schlüssel)
  • Sie legen im Heimatverzeichnis von [nutzername] ein Verzeichnis namens .ssh für den öffentlichen Schlüssel an
  • Sie laden den öffentlichen Schlüssel auf den Server in das neu erstellte Verzeichnis
  • Sie erlauben zusätzlich die Public Key Authentifizierung
  • Sie testen die Funktionalität der Public Key Authentifizierung
  • Sie stellen den SSH-Dienst komplett um auf ausschliessliche Public Key Authentifizierung

3.1 Erstellung der Schlüssel auf einem Linuxsystem, oder auch Mac OS X System

3.1.1 Schlüsselgenerierung mit dem folgendem Befehl auf dem lokalen Rechner:

ssh-keygen -t dsa

Durch diesen Prozeß werden zwei Schlüsseldateien angelegt:

Your identification has been saved in /home/[nutzername]/.ssh/id_dsa

Your public key has been saved in /home/[nutzername]/.ssh/id_dsa.pub

 

3.1.2 Laden des öffentlichen Schlüssels auf den Zielserver mittels SecureCopy
Mit der folgenen Eingabe laden Sie von einem Linux, oder MacOS X Rechner die öffentliche Schlüsseldatei (id_dsa.pub) unter neuem Dateinamen authorized_keys in das Verzeichnis .ssh/ des neuen Nutzers:

scp ~/.ssh/id_dsa.pub [nutzername]@Ihr_Servername.tld:.ssh/authorized_keys

Achtung Dazu ist es nötig, dass auf dem Zielserver das Verzeichnis ~/.ssh/ bereits existiert.

 

3.1.3 Prüfen ob Public Key Authentifizierung bereits auf dem Zielserver erlaubt ist und ggf. einrichten
Wir empfehlen die folgende Vorgehensweise:

Ändern Sie in der Datei /etc/ssh/sshd_config ggf. die Zeile

PubkeyAuthentication no

in

PubkeyAuthentication yes

Nun ist es noch nötig die Konfigurationsdateien des Dienstes neu einzulesen:

/etc/init.d/ssh reload (Debian/Ubuntu)
/etc/init.d/sshd reload (SUSE)

 

3.1.4 Es gilt nun zu prüfen, ob die Public Key Authentifizierung auch funktioniert
Mit der folgenen Eingabe bauen Sie von einem Linux, oder MacOS X Rechner eine SSH-Verbindung zu Ihrem Server auf, geben den privaten Key an und werden lediglich nach dem Passwort für Ihre lokale Schlüsseldatei gefragt:

ssh -i ~/.ssh/id_dsa -l [nutzername] Ihr_Servername.tld

 

3.1.5 Nach erfolgreichem Login können Sie das Authentifizierungsverfahrens komplett auf SSH Public Key Authentifizierung umstellen.
Wir empfehlen die folgende Vorgehensweise:

Ändern Sie in der Datei /etc/ssh/sshd_config ggf. die Zeile

PasswordAuthentication yes

in

PasswordAuthentication no

und die Zeile

ChallengeResponseAuthentication yes

in

ChallengeResponseAuthentication no

Nun ist es noch nötig die Konfigurationsdateien des Dienstes neu einzulesen:

/etc/init.d/ssh reload (Debian/Ubuntu)
/etc/init.d/sshd reload (SUSE)

3.2 Erstellung der Schlüssel auf einem Windowssystem

3.2.1 Schlüsselgenerierung

Unter Windows verwendet man zum Key-Management das Tool Puttygen. Dieses können Sie sich auf der Putty-Homepage unter:
externer Link http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html herunterladen.

Um einen Key zu erzeugen, wählt man unten den Keytyp (meistens SSH2, RSA oder DSA), trägt die Schlüssellänge in bits ein und klickt anschließend den Button Generate an. Über Mausbewegungen werden dabei Zufallswerte gesammelt, d. h. die "Generierungsleiste" füllt sich nur dann, wenn Sie Ihre Maus bewegen.

Ist der Key erzeugt, geben Sie bitte im Feld Key passphrase noch ein persönliches Passwort ein, welchen im Feld Confirm passphrase bestätigt werden muss.



Die weiteren Schritte entsprechen der unter den Punkten 3.1.3 bis 3.1.5 beschriebenen Weise. Für den Upload des öffentlichen Schlüssels in das Verzeichnis ~/.ssh/ empfehlen wir das Programm externer Link WinSCP, was Sie unter externer Link http://winscp.net/eng/docs/lang:de laden können.

Wenn Sie WinSCP verwenden, werden Sie beim ersten Connect mit Ihrem Server aufgefordert, einen Authentifizierungsschlüssel zu akzeptieren oder abzulehnen. Akzeptieren Sie diesen Schlüssel. Hierdurch weiß Ihr lokaler Client bei den darauf folgenden Connects, dass Ihr Server auch tatsächlich Ihr Server ist, und kein anderer.

 

 

War dieser Artikel hilfreich?   Ja / Nein


Vielen Dank für Ihr Feedback!
Tut uns Leid. Warum hat ihnen der Artikel nicht geholfen?
  Informationen unklar oder unvollständig
  Informationen fehlerhaft
  Artikel behandelt nicht mein Problem
  Artikel zu lang


Kommentar (optional)