SSH absichern: Root-Login & Passwort deaktivieren

Hinweis: Dieser Beitrag enthält Affiliate-Links (mit * gekennzeichnet). Kaufst du über einen dieser Links, erhalte ich eine kleine Provision — für dich ändert sich der Preis nicht.

In Teil 1 hast du dich schon mit einem SSH-Schlüssel statt mit einem Passwort angemeldet — sehr gut. Trotzdem ist dein Server an dieser Stelle noch nicht fertig abgesichert. Denn der Schlüssel ist nur die eine Möglichkeit, sich einzuloggen. Die alten Wege sind oft noch offen: Anmeldung als root und Anmeldung per Passwort. Genau die schließen wir jetzt.

Das ist der Unterschied zwischen „ich habe einen Schlüssel“ und „die Tür lässt sich nur noch mit dem Schlüssel öffnen“. Erst danach laufen die Tausenden automatischen Login-Versuche, die jeden Server im Netz treffen, komplett ins Leere.

Das Problem: Schlüssel da, Tür trotzdem zweifach offen

Sekunden nachdem dein Server online ist, klopfen Bots an Port 22 und probieren Standard-Benutzer und beliebte Passwörter durch — root mit „123456″, „admin“, „password“ und so weiter. Das ist kein gezielter Angriff auf dich, sondern Fließband-Automatik, die das ganze Internet absucht.

Solange auf deinem Server zwei Dinge gelten, hat dieses Fließband eine echte Chance:

Root-Login erlaubt: root ist auf jedem Linux-Server der Benutzername mit allen Rechten — und damit das beliebteste Angriffsziel. Den Namen muss niemand raten.
Passwort-Login erlaubt: Solange Passwörter überhaupt akzeptiert werden, kann jemand sie durchprobieren. Dein Schlüssel schützt dich nicht, wenn die Passwort-Tür daneben offensteht.

Die Lösung hat drei Teile: Du legst einen eigenen Benutzer mit Admin-Rechten an, gibst ihm deinen Schlüssel, und schaltest danach Root-Login und Passwort-Anmeldung ab. Ab dann kommt nur noch rein, wer deinen privaten Schlüssel besitzt.

Voraussetzungen

Bevor wir loslegen:

Ein laufender Server mit SSH-Schlüssel-Login, so wie in Teil 1 eingerichtet (z. B. ein Hetzner Cloud Server*, das Vorgehen gilt aber für jeden vServer mit Debian 12).
Dein SSH-Programm (unter Windows PuTTY mit deinem Schlüssel aus PuTTYgen) — oder ein Terminal unter macOS/Linux.
Dein privater Schlüssel liegt griffbereit, so wie du ihn für die erste Anmeldung benutzt.
Wir arbeiten mit Debian 12 (so wie in der Serie). Bist du auf Ubuntu, gilt fast alles identisch — ein kleiner Unterschied steht weiter unten im Kasten.

Als Platzhalter steht deinbenutzer für den neuen Benutzernamen, den du dir ausdenkst, und DEINE-SERVER-IP für die IP-Adresse deines Servers.

Schritt 1: Einen eigenen Benutzer mit Admin-Rechten anlegen

Melde dich zunächst wie gewohnt als root an. Eine Debian-Besonderheit vorweg: Bei einer minimalen Debian-Installation ist sudo nicht immer schon dabei. Installier es deshalb einmal kurz — ist es bereits vorhanden, meldet Debian einfach „schon aktuell“ und nichts passiert:

apt update && apt install sudo

Dann legst du deinen persönlichen Benutzer an:

adduser deinbenutzer

Du wirst nach einem Passwort gefragt — vergib ein starkes Passwort. Es dient gleich nur noch für sudo (Admin-Aktionen), nicht mehr fürs Einloggen. Die abgefragten Zusatzangaben (Name, Telefon …) kannst du mit Enter überspringen.

Jetzt gibst du dem Benutzer Admin-Rechte, indem du ihn in die Gruppe sudo aufnimmst:

usermod -aG sudo deinbenutzer

Schritt 2: Deinen SSH-Schlüssel auf den neuen Benutzer übertragen

Wichtig vorweg: Du brauchst keinen neuen Schlüssel. Ein Schlüsselpaar gehört zu dir, nicht zu einem einzelnen Server-Benutzer — du verwendest denselben Schlüssel wie bisher (kein PuTTYgen nötig). Er muss nur auch im Konto des neuen Benutzers hinterlegt sein. Am einfachsten kopierst du die bereits funktionierende Schlüssel-Datei von root herüber (noch als root ausgeführt):

mkdir -p /home/deinbenutzer/.ssh
cp ~/.ssh/authorized_keys /home/deinbenutzer/.ssh/
chown -R deinbenutzer:deinbenutzer /home/deinbenutzer/.ssh
chmod 700 /home/deinbenutzer/.ssh
chmod 600 /home/deinbenutzer/.ssh/authorized_keys

Die letzten drei Zeilen sind wichtig: Sie sagen, dass der Ordner dem neuen Benutzer gehört und niemand sonst hineinschauen darf. Bei zu offenen Rechten verweigert SSH den Schlüssel-Login kommentarlos.

Schritt 3: Den neuen Login testen (und das Fenster offen lassen!)

Jetzt kommt der entscheidende Sicherheitstest. Lass dein aktuelles root-Fenster offen und öffne eine zweite SSH-Verbindung — diesmal als deinbenutzer:

Windows/PuTTY: neue PuTTY-Sitzung, gleiche Server-IP und gleicher Schlüssel wie bisher, als Benutzername aber deinbenutzer.
macOS/Linux: ssh deinbenutzer@DEINE-SERVER-IP

Du solltest ohne Passwort-Eingabe direkt auf der Eingabezeile landen. Prüfe einmal kurz, ob die Admin-Rechte sitzen:

sudo whoami

Nach Eingabe deines (neuen) Benutzerpassworts muss root als Antwort erscheinen. Klappt beides — Schlüssel-Login und sudo — bist du startklar für den letzten Schritt.

Schritt 4: Root-Login und Passwörter abschalten

Jetzt schließen wir die alten Türen. Arbeite dafür in deinem funktionierenden deinbenutzer-Fenster. Statt die große Hauptkonfiguration zu verändern, legen wir eine kleine eigene Datei an — sauber, übersichtlich und update-fest:

sudo nano /etc/ssh/sshd_config.d/99-haerten.conf

Trag dort genau diese drei Zeilen ein:

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no

Was die Zeilen bewirken: kein Login mehr als root, keine Passwort-Anmeldung mehr, und auch keine Passwort-Abfrage über Umwege. Übrig bleibt genau ein Weg hinein — dein Schlüssel.

Speichern in nano mit Strg+O, Enter, dann Strg+X. Prüfe die Konfiguration zuerst auf Tippfehler — vor dem Neustart:

sudo sshd -t

Kommt keine Ausgabe, ist alles in Ordnung. Erst dann lädst du den SSH-Dienst neu:

sudo systemctl restart ssh

Schritt 5: Die Probe aufs Exempel

Jetzt zeigt sich, ob alles sitzt. Lass dein aktuelles Fenster weiterhin offen und öffne eine frische dritte Verbindung:

Login als deinbenutzer mit Schlüssel — muss weiterhin funktionieren.
Versuch testweise einen Login als root — der muss jetzt abgelehnt werden.

Wenn der neue Benutzer reinkommt und root abgewiesen wird, ist dein SSH-Zugang sauber gehärtet. Glückwunsch — die Bots an Port 22 laufen ab sofort ins Leere.

Lass dich von der Meldung Server refused public-key signature despite accepting key! nicht irritieren — dein Schlüssel ist nicht kaputt. Der Server nimmt den Schlüssel an, weist aber den Benutzer root bewusst ab, genau wie wir es eingestellt haben. Mit deinbenutzer kommst du weiterhin normal rein.

Die Kür: noch eine Stufe mehr (optional)

Für den Grundschutz bist du fertig. Wer mag, dreht zwei weitere Schrauben:

Fail2ban sperrt IP-Adressen, die zu oft erfolglos anklopfen, automatisch aus. Praktisch: Auf einem KeyHelp-Server ist Fail2ban meist schon aktiv — wie du das prüfst, steht in Teil 2: KeyHelp absichern & Backups.
SSH-Port ändern: Verlegst du SSH von Port 22 auf einen anderen (z. B. mit einer Zeile Port 2222 in derselben Datei), verschwindet der Großteil des automatischen Lärms. Das ist Bequemlichkeit, kein echter Schutz — und du musst den neuen Port in deinem SSH-Programm und in der Firewall freigeben. Sperr dich auch hier nicht aus.

Test & Troubleshooting

Die häufigsten Stolpersteine:

Neuer Benutzer kommt nicht per Schlüssel rein: Fast immer stimmen die Rechte nicht. Prüfe (als root im offenen Fenster): Ordner .ssh = 700, Datei authorized_keys = 600, beides gehört deinbenutzer. Genau das machen die chmod/chown-Zeilen aus Schritt 2.
sudo sagt „is not in the sudoers file“: Der Benutzer ist nicht in der Gruppe sudo. Schritt 1 wiederholen: usermod -aG sudo deinbenutzer, danach einmal neu einloggen.
Du hast dich doch ausgesperrt: Kein Drama, wenn du die Reihenfolge eingehalten hast — nutze ein noch offenes Fenster oder die Web-Konsole im Hetzner-Panel. Lösche dort die Datei /etc/ssh/sshd_config.d/99-haerten.conf wieder (rm), systemctl restart ssh, und der alte Zustand ist zurück.
KeyHelp-Panel weiter erreichbar? Ja. Das KeyHelp-Webpanel und die Webseiten deiner Domains laufen über den Webserver (Port 80/443), völlig unabhängig vom SSH-Zugang. Am Panel ändert sich durch das SSH-Härten nichts.

Wie es jetzt weitergeht

Stark: Dein Server akzeptiert jetzt nur noch deinen Schlüssel, kein root und kein Passwort mehr — der mit Abstand größte Sicherheitsgewinn mit wenigen Handgriffen. Die nächsten Etappen:

Noch nicht abgesichert? KeyHelp absichern: 2FA, Updates & Backups (Teil 2) — Login-Schutz fürs Panel und automatische Backups.
Eigene Nameserver: Domain über eigene Nameserver mit Hetzners Secondary DNS betreiben (Teil 3).
Der komplette Fahrplan: alle Anleitungen im Hub Server & Hosting Tutorials.

Häufige Fragen

Ich habe doch schon einen SSH-Schlüssel — reicht das nicht?

Der Schlüssel ist ein sicherer Weg hinein, aber nicht der einzige, solange Passwort-Login und Root-Anmeldung noch erlaubt sind. Angreifer probieren dann weiter Passwörter zu root durch. Erst wenn du beide alten Wege abschaltest, ist der Schlüssel tatsächlich die einzige Tür — und genau das macht dieser Artikel.

Kann ich mich dabei selbst aussperren?

Nur wenn du die Reihenfolge missachtest. Solange du den neuen Login in einem zweiten Fenster testest und dieses Fenster offen lässt, bevor du die alten Türen schließt, kannst du jeden Fehler sofort rückgängig machen. Zusätzlich gibt es bei Hetzner eine Web-Konsole im Server-Panel, über die du immer auf den Server kommst — auch ohne SSH.

Brauche ich überhaupt noch ein root-Passwort?

Zum Einloggen nicht mehr. Du arbeitest künftig als dein eigener Benutzer und führst Admin-Aufgaben mit sudo aus. Das Passwort deines Benutzers brauchst du nur noch, um sudo-Befehle zu bestätigen — nicht mehr für die SSH-Anmeldung selbst.

Sperrt das Abschalten der Passwörter meine KeyHelp-Kunden aus?

Nur, wenn diese sich per SFTP mit Passwort verbinden — denn SFTP läuft über SSH. Auf einem Server, den nur du selbst nutzt, spielt das keine Rolle. Brauchst du Passwort-SFTP für einzelne Konten, lässt es sich gezielt über einen Match-Block wieder freigeben, ohne deinen Admin-Login aufzuweichen.

Muss ich den SSH-Port ändern?

Nein, das ist optional. Ein anderer Port reduziert vor allem den automatischen Lärm in den Logs, ist aber kein echter Schutz — die Sicherheit kommt aus Schlüssel-Login plus abgeschaltetem Passwort und Root-Zugang. Wenn du den Port änderst, denk daran, ihn in deinem SSH-Programm und in der Firewall anzupassen.

Quellen: Debian 12 (Bookworm), OpenSSH — sshd_config (PermitRootLogin, PasswordAuthentication, KbdInteractiveAuthentication), Hetzner Docs — Web-Konsole

SSH absichern: deinen Server-Zugang in 15 Minuten dichtmachen