SSH-Zugang mit Schlüsseln absichern: Passwort- und Root-Login unter Ubuntu abschalten¶

Veröffentlicht am 13. Oktober 2026 · Geschätzte Lesezeit: 7 Minuten

Jeder SSH-Server mit aktivierter Passwort-Anmeldung ist ein Angriffsziel für automatisierte Brute-Force-Versuche aus dem Internet. Statt erratbarer Passwörter verwendest du einen passphrasengeschützten Ed25519-Schlüssel, deaktivierst Passwort- und Root-Anmeldung und machst deinen Server damit deutlich schwerer angreifbar. Die Einrichtung dauert etwa 20 bis 30 Minuten.

Die offizielle Ubuntu-Dokumentation empfiehlt Ed25519-Schlüssel aufgrund ihrer kürzeren Schlüssellänge und geringeren Rechenlast.[1][4] Der OpenBSD-sshd_config-Manpage entnehmen wir die Konfigurationsoptionen.[2] Das Ubuntu-Manual zu sshd_config liefert Details zu Ubuntu-spezifischen Voreinstellungen.[5] Der Praxisartikel von DigitalOcean zeigt den Ablauf ergänzend.[3]

Voraussetzungen

Ein Linux-Server mit Ubuntu 22.04, 24.04 oder 26.04 LTS
Ein zweiter Computer (Notebook, Desktop), von dem aus du dich einloggst – dort erzeugst du den Schlüssel
Terminal-Zugriff mit einem Benutzer, der sudo-Rechte besitzt
Konsolen- oder physischer Zugriff auf den Server als Rückweg, falls etwas schiefgeht

1. Schlüsselpaar auf deinem lokalen Computer erzeugen¶

Der private Schlüssel gehört ausschließlich auf deinen lokalen Computer und verlässt ihn nie. Öffne ein Terminal auf dem Rechner, von dem aus du dich später anmelden möchtest:[1]

ssh-keygen -t ed25519 -a 100 -C "mein-ssh-schluessel"

Bedeutung der Optionen:

Platzhalter/Option	Bedeutung
`-t ed25519`	Moderne Elliptische-Kurve-Kryptografie – kürzer und schneller als RSA
`-a 100`	100 KDF-Runden für die Passphrase – erhöht Brute-Force-Widerstand (100 ist Standardwert)[1]
`-C "mein-ssh-schluessel"`	Kommentar – hilft, mehrere Schlüssel auseinanderzuhalten

Während der Erzeugung wirst du nach einem Speicherort (Enter = ~/.ssh/id_ed25519) und einer Passphrase gefragt. Gib eine starke, aber merkbare Passphrase ein – sie schützt den privaten Schlüssel, falls jemand Zugriff auf deinen Rechner bekommt.

Die Ausgabe sollte etwa so enden:

Your public key has been saved in /home/dein-nutzername/.ssh/id_ed25519.pub

Privaten Schlüssel niemals weitergeben

Die Datei ~/.ssh/id_ed25519 (ohne .pub) ist dein privater Schlüssel. Kopiere, teile oder commite sie nie. Nur der öffentliche Schlüssel (id_ed25519.pub) wird auf Server übertragen.

2. Öffentlichen Schlüssel auf den Server kopieren¶

Verwende ssh-copy-id, um den öffentlichen Schlüssel in die authorized_keys-Datei des Servers einzutragen:[1][3]

ssh-copy-id -i ~/.ssh/id_ed25519.pub <benutzer>@<server-ip>

Ersetze <benutzer> durch deinen Server-Benutzernamen und <server-ip> durch die IP-Adresse deines Servers. Bei einem abweichenden SSH-Port (nicht 22):

ssh-copy-id -i ~/.ssh/id_ed25519.pub -p <port> <benutzer>@<server-ip>

Ersetze <port> durch deinen SSH-Port (zum Beispiel 2222).

3. Schlüssel-Anmeldung testen – bei geöffneter Sitzung¶

Trenne die aktuelle SSH-Verbindung nicht. Öffne ein zweites Terminal und teste die schlüsselbasierte Anmeldung:[1]

ssh -o PreferredAuthentications=publickey <benutzer>@<server-ip>

Ersetze <benutzer> und <server-ip> wie in Schritt 2. Bei abweichendem Port:

ssh -p <port> -o PreferredAuthentications=publickey <benutzer>@<server-ip>

Bei Erfolg wirst du nach deiner Passphrase gefragt (nicht nach dem Server-Passwort) und landest auf dem Server. Prüfe anschließend, ob sudo funktioniert:

id
sudo -v

sudo -v fragt nach deiner Passphrase oder deinem Passwort – je nach Server-Konfiguration. Fahre erst fort, wenn sowohl die Schlüssel-Anmeldung als auch sudo funktionieren.

Nicht ohne funktionierenden zweiten Zugang fortfahren

Solange nur die erste Sitzung aktiv ist, hast du einen Rückweg. Schließe sie erst, wenn die neue Schlüssel-Anmeldung zuverlässig klappt. Ohne funktionierenden zweiten Zugang kannst du dich bei einem Konfigurationsfehler aussperren.

4. Aktuelle SSH-Konfiguration sichern¶

Bevor du Änderungen vornimmst, sicherst du die bestehende Konfiguration:[1]

sudo cp -a /etc/ssh/sshd_config /etc/ssh/sshd_config.before-key-only
sudo cp -a /etc/ssh/sshd_config.d /etc/ssh/sshd_config.d.before-key-only

Mit dieser Sicherung kannst du bei einem Fehler den Ursprungszustand jederzeit wiederherstellen.

Ubuntu verwendet standardmäßig ein Include-System: Dateien in /etc/ssh/sshd_config.d/ werden vor der Hauptdatei geladen. Da OpenSSH bei den meisten Direktiven den ersten gefundenen Wert verwendet, überschreiben Einstellungen in den Snippet-Dateien die Hauptkonfiguration.[1][5]

Erstelle eine neue Snippet-Datei mit einem Namen, der früh einsortiert wird:[1]

sudo tee /etc/ssh/sshd_config.d/00-local-key-only.conf >/dev/null <<'EOF'
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no
EOF

Bedeutung der Direktiven:

Direktive	Wirkung
`PubkeyAuthentication yes`	Schlüssel-Anmeldung erlauben (ist standardmäßig aktiv, wird hier explizit gesetzt) [2]
`PasswordAuthentication no`	Klassische Passwort-Anmeldung verbieten [5]
`KbdInteractiveAuthentication no`	Verhindert, dass PAM eine alternative Passwortabfrage ermöglicht [5]
`PermitRootLogin no`	Direkte Root-Anmeldung per SSH sperren – du verwendest stattdessen `sudo` [2]

MFA-Nutzer: KbdInteractiveAuthentication nicht blind übernehmen

Falls du SSH mit Zwei-Faktor-Authentifizierung über PAM (TOTP, U2F) betreibst, darfst du KbdInteractiveAuthentication nicht auf no setzen. In diesem Fall lässt du die Zeile weg und deaktivierst nur PasswordAuthentication.

6. Konfiguration validieren und aktivieren¶

Prüfe die Syntax aller SSH-Konfigurationsdateien, bevor du den Dienst neu lädtst:[1]

sudo sshd -t

Der Befehl darf keine Ausgabe erzeugen und muss mit Exit-Code 0 enden. Bei einem Fehler korrigierst du das Snippet oder entfernst es:

sudo rm /etc/ssh/sshd_config.d/00-local-key-only.conf

Erst nach erfolgreicher Prüfung aktivierst du die neue Konfiguration:

sudo systemctl reload ssh

sshd -t vor jedem Reload ausführen

Überspringe die Prüfung nie. Ein Syntaxfehler verhindert den SSH-Dienst-Neustart und kann dich aussperren. Der Befehl sshd -t ist gefahrlos – er prüft nur, ohne etwas zu verändern.

7. Effektive Konfiguration prüfen¶

Lass dir die tatsächlich aktiven Einstellungen anzeigen:

sudo sshd -T | grep -E '^(pubkeyauthentication|passwordauthentication|kbdinteractiveauthentication|permitrootlogin) '

Erwartete Ausgabe:

pubkeyauthentication yes
passwordauthentication no
kbdinteractiveauthentication no
permitrootlogin no

Prüfe außerdem, ob der SSH-Dienst läuft:

systemctl is-active ssh

Erwartete Ausgabe: active.

Dienstname unter Ubuntu

Der OpenSSH-Server-Dienst heißt unter Ubuntu ssh, nicht sshd. Verwende systemctl konsequent mit dem Namen ssh.[1]

8. Funktionsprüfungen¶

Führe alle Tests in einem neuen Terminal durch – nicht in der aktiven Sitzung.

Positivtest: Schlüssel-Anmeldung funktioniert

ssh -o PreferredAuthentications=publickey <benutzer>@<server-ip>

Ersetze <benutzer> und <server-ip>. Du wirst nach deiner Passphrase gefragt und angemeldet.

Negativtest: Passwort-Anmeldung ist gesperrt

ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password,keyboard-interactive <benutzer>@<server-ip>

Erwartung: Die Verbindung wird ohne Passwortabfrage mit Permission denied (publickey) abgelehnt.

Negativtest: Root-Login ist gesperrt

ssh root@<server-ip>

Erwartung: Die Verbindung wird abgelehnt. (Dieser Test allein ist nicht eindeutig, wenn auch für Root kein Schlüssel existiert – zusammen mit der Ausgabe von sshd -T aus Schritt 7 ist er belastbar.)

Bei benutzer- oder adressabhängigen Regeln (falls vorhanden) prüfst du die effektive Konfiguration kontextbezogen:

sudo sshd -T -C user=<benutzer>,host=<server-ip>,addr=<client-ip> | grep -E '^(pubkeyauthentication|passwordauthentication|kbdinteractiveauthentication|permitrootlogin) '

Ersetze <client-ip> durch die IP deines lokalen Rechners.

9. Backup und Rückweg¶

Solange die ursprüngliche SSH-Sitzung noch geöffnet ist, entfernst du das Snippet mit:

sudo rm /etc/ssh/sshd_config.d/00-local-key-only.conf
sudo sshd -t
sudo systemctl reload ssh

Falls du zusätzlich die Hauptdatei verändert hast, stellst du die Sicherung zurück:

sudo cp -a /etc/ssh/sshd_config.before-key-only /etc/ssh/sshd_config
sudo sshd -t
sudo systemctl reload ssh

Bei vollständiger Aussperrung nutzt du die Konsolen-Funktion deines Server-Anbieters (VPS-Webconsole, Proxmox-Shell, iDRAC/iLO) oder einen physischen Zugang:

Melde dich lokal oder über die Konsole an
Entferne das Snippet: sudo rm /etc/ssh/sshd_config.d/00-local-key-only.conf
Prüfe: sudo sshd -t
Lade den Dienst neu: sudo systemctl reload ssh

10. Typische Fehler und Probleme¶

Schlüssel auf dem Server statt auf dem Client erzeugt Der private Schlüssel gehört auf den Rechner, von dem du dich anmeldest. Wenn du ssh-keygen auf dem Server ausführst, hast du dort den privaten Schlüssel – das hilft dir nicht, von deinem Notebook aus zu kommen.

ssh-copy-id ohne -i kopiert den falschen Schlüssel Ohne -i wählt ssh-copy-id automatisch den ersten gefundenen öffentlichen Schlüssel aus. Verwende immer -i ~/.ssh/id_ed25519.pub, um den richtigen Schlüssel zu übertragen.

Zu lockere Berechtigungen in ~/.ssh SSH lehnt einen Schlüssel ab, wenn die Dateirechte zu offen sind. Korrigiere sie mit:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Privaten statt öffentlichen Schlüssel übertragen Die Datei id_ed25519 (ohne .pub) ist der private Schlüssel. Nur id_ed25519.pub kommt auf den Server. Ein versehentlich kopierter privater Schlüssel gefährdet den Zugang von diesem Rechner aus sofort.

sshd -t vor dem Reload ausgelassen Ein Syntaxfehler in der Konfiguration kann den SSH-Dienst an einem erfolgreichen Neustart hindern und dich aussperren. Überspringe die Prüfung nie.

Falscher Dienstname Unter Ubuntu lautet der Dienstname ssh, nicht sshd.[1] Der Befehl sudo systemctl reload ssh ist korrekt.

Fertig¶

Dein SSH-Server akzeptiert jetzt nur noch Anmeldungen mit einem gültigen SSH-Schlüssel. Die Einrichtung ist erfolgreich, wenn:

die Schlüssel-Anmeldung von deinem lokalen Rechner funktioniert (Schritt 8)
die Passwort-Anmeldung mit Permission denied (publickey) abgewiesen wird (Schritt 8)
der Root-Login per SSH nicht mehr möglich ist (Schritt 8)
sudo sshd -T die erwarteten Werte passwordauthentication no und permitrootlogin no anzeigt (Schritt 7)

Du kannst den Schlüssel später auf weiteren Rechnern einrichten, indem du deren öffentliche Schlüssel in ~/.ssh/authorized_keys auf dem Server einträgst.

Sources¶

[1] https://ubuntu.com/server/docs/how-to/security/openssh-server — Ubuntu OpenSSH server documentation [2] https://man.openbsd.org/sshd_config — OpenBSD sshd_config man page [3] https://www.digitalocean.com/community/tutorials/how-to-set-up-ssh-keys-on-ubuntu-20-04 — DigitalOcean: How to Set Up SSH Keys on Ubuntu [4] https://www.openssh.com — OpenSSH official website [5] https://manpages.ubuntu.com/manpages/resolute/man5/sshd_config.5.html — Ubuntu sshd_config man page