SSH-Key-Authentifizierung & Härtung unter Ubuntu

Passwortbasierte SSH-Logins sind die meistangegriffene Oberfläche jedes Linux-Servers im Internet. Bots hämmern rund um die Uhr auf Port 22 und raten Zugangsdaten. Die Schlüsselauthentifizierung beseitigt diese gesamte Angriffsklasse: Statt eines Passworts weisen Sie Ihre Identität mit einem kryptografischen Schlüsselpaar nach, das sich praktisch nicht per Brute-Force knacken lässt. Diese Anleitung richtet die SSH-Schlüsselauthentifizierung unter Ubuntu 24.04 ein und härtet anschließend den SSH-Daemon, sodass Passwortangriffe schlicht ins Leere laufen.

Wir erzeugen einen modernen ed25519-Schlüssel, hinterlegen den öffentlichen Schlüssel auf dem Server, testen ihn und deaktivieren erst dann Passwort- und Root-Login. Die Reihenfolge ist wichtig: Wir halten eine funktionierende Sitzung offen und prüfen den Schlüssel-Login, bevor wir irgendetwas abschalten – so bleibt stets ein sicherer Rückweg.

Voraussetzungen

• Ein Server mit Ubuntu 24.04 LTS und SSH-Zugang (vorerst funktioniert der Passwort-Login).
• Ein lokaler Rechner (Linux, macOS oder Windows mit OpenSSH), um den privaten Schlüssel zu erzeugen und zu verwahren.
• Ein Benutzer mit sudo auf dem Server.

Schritt 1: Ein ed25519-Schlüsselpaar erzeugen

Führen Sie dies auf Ihrem lokalen Rechner aus, nicht auf dem Server. Der ed25519-Algorithmus ist schnell, kompakt und sicherer als ältere RSA-Schlüssel:

ssh-keygen -t ed25519 -C 'sie@example.com'

Drücken Sie ENTER, um den Standardpfad zu übernehmen (~/.ssh/id_ed25519). Wird nach einer Passphrase gefragt, vergeben Sie eine – sie verschlüsselt den privaten Schlüssel auf der Festplatte, sodass ein gestohlener Laptop nicht gleich einen gestohlenen Server bedeutet. Sie sehen:

Generating public/private ed25519 key pair.
Your identification has been saved in /home/sie/.ssh/id_ed25519
Your public key has been saved in /home/sie/.ssh/id_ed25519.pub

Es existieren nun zwei Dateien: id_ed25519 (privat – niemals weitergeben) und id_ed25519.pub (öffentlich – darf verteilt werden).

Schritt 2: Den öffentlichen Schlüssel auf den Server kopieren

Am einfachsten geht das mit ssh-copy-id, das Ihren öffentlichen Schlüssel an die ~/.ssh/authorized_keys des Servers anhängt und die Berechtigungen korrigiert:

ssh-copy-id benutzer@server-ip

Es fragt ein letztes Mal nach Ihrem Passwort. Ist ssh-copy-id nicht verfügbar, machen Sie es manuell:

cat ~/.ssh/id_ed25519.pub | ssh benutzer@server-ip 'mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys'

Schritt 3: Den Schlüssel-Login testen (alte Sitzung offen lassen)

Öffnen Sie ein neues Terminal und verbinden Sie sich. Schließen Sie Ihre bestehende Passwort-Sitzung noch nicht:

ssh benutzer@server-ip

Hat Ihr Schlüssel eine Passphrase, werden Sie danach gefragt (nicht nach dem Server-Passwort). Landen Sie ohne Eingabe des Konto-Passworts auf der Shell, funktioniert die Schlüsselauthentifizierung. Bei Bedarf mit ausführlicher Ausgabe bestätigen:

ssh -v benutzer@server-ip 2>&1 | grep -i 'Authentication succeeded'

Schritt 4: Den SSH-Daemon härten

Jetzt verriegeln wir die Tür. Unter Ubuntu 24.04 überschreiben Drop-in-Konfigurationsdateien in /etc/ssh/sshd_config.d/ die Haupt-Datei /etc/ssh/sshd_config und überstehen Paket-Upgrades sauber. Legen Sie eine an:

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

Fügen Sie ein:

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
PermitEmptyPasswords no
MaxAuthTries 3
X11Forwarding no

Was die Zeilen bewirken: PermitRootLogin no unterbindet direkte Root-Logins (nutzen Sie stattdessen sudo). PasswordAuthentication no und KbdInteractiveAuthentication no deaktivieren zusammen jeden Passwortweg, sodass nur Schlüssel funktionieren. MaxAuthTries 3 trennt die Verbindung nach drei Fehlversuchen. X11Forwarding no entfernt eine auf einem Server ohne Grafik unnötige Funktion.

Schritt 5: Die Konfiguration prüfen und anwenden

Prüfen Sie die Konfiguration vor dem Neustart auf Syntaxfehler – ein Tippfehler kann SSH komplett lahmlegen:

sudo sshd -t

Gibt der Befehl nichts aus, ist die Konfiguration gültig. Wenden Sie sie durch einen Neustart des Dienstes an:

sudo systemctl restart ssh

Greifen die Änderungen scheinbar nicht, beachten Sie: Ubuntu 24.04 nutzt SSH-Socket-Aktivierung; starten Sie zusätzlich die Socket-Unit neu:

sudo systemctl restart ssh.socket

Schritt 6: Die Härtung aus einer neuen Sitzung überprüfen

Während Ihre ursprüngliche Sitzung als Sicherheitsnetz offen bleibt, öffnen Sie ein weiteres neues Terminal und verbinden sich erneut, um zu bestätigen, dass der Schlüssel-Login weiterhin funktioniert:

ssh benutzer@server-ip

Weisen Sie dann nach, dass die Passwort-Authentifizierung wirklich aus ist, indem Sie sie erzwingen:

ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no benutzer@server-ip

Permission denied (publickey).

Genau dieses Permission denied (publickey) wollen Sie sehen: Der Server bietet die Passwort-Authentifizierung gar nicht erst an. Erst jetzt ist es sicher, Ihre ursprüngliche Passwort-Sitzung zu schließen.

Optional: einen SSH-Config-Alias nutzen

Um nicht jedes Mal den vollständigen Befehl zu tippen, ergänzen Sie einen Eintrag in ~/.ssh/config auf Ihrem lokalen Rechner:

Host meinserver
    HostName server-ip
    User benutzer
    IdentityFile ~/.ssh/id_ed25519

Nun verbinden Sie sich mit nur ssh meinserver.

Häufige Stolperfallen und Fehlerbehebung

• Nach dem Deaktivieren der Passwörter ausgesperrt. Halten Sie immer eine Sitzung offen und prüfen Sie den Schlüssel-Login in einer zweiten Sitzung, bevor Sie sshd neu starten. Sind Sie ausgesperrt, retten Sie sich über die Konsole Ihres Anbieters oder den Rettungsmodus.
• Falsche Berechtigungen. SSH lehnt Schlüssel ab, wenn die Rechte zu offen sind. Der Server braucht ~/.ssh mit 700 und authorized_keys mit 600, im Besitz des Benutzers. Korrigieren mit chmod wie oben.
• Schlüssel wird nicht angeboten. Hat der Client viele Schlüssel, kann der Server MaxAuthTries erreichen, bevor der richtige drankommt. Geben Sie den Schlüssel mit ssh -i ~/.ssh/id_ed25519 oder per IdentityFile in der Config an.
• Falsche Datei bearbeitet. Unter Ubuntu 24.04 können Einstellungen in /etc/ssh/sshd_config.d/*.conf Ihre Änderungen an der Hauptdatei überschreiben. Prüfen Sie auf widersprüchliche Drop-ins.
• Passphrase vergessen. Für eine verlorene Passphrase des privaten Schlüssels gibt es keine Wiederherstellung – erzeugen Sie ein neues Schlüsselpaar und verteilen Sie den öffentlichen Schlüssel neu.

Fazit

Schlüsselauthentifizierung plus ein gehärteter sshd macht aus SSH von Ihrer größten Schwachstelle eine Randnotiz: Mit deaktivierten Passwörtern und abgeschaltetem Root-Login haben Brute-Force-Bots nichts mehr anzugreifen. Die ganze Umstellung dauert wenige Minuten und birgt – in der obigen Reihenfolge – kein Aussperr-Risiko.

Die SSH-Härtung ist eine Säule einer sicheren Grundkonfiguration. Ergänzen Sie eine Host-Firewall mit unserer Anleitung zum Einrichten von UFW unter Ubuntu und sperren Sie Wiederholungstäter automatisch mit fail2ban. Dieselben Kontrollen wendet clouditiv standardmäßig an: Unsere souveräne Cloud ist nach ISO 27001 und BSI C5 gehärtet, mit reinem Schlüsselzugang und Datenhaltung in Deutschland – Sie erben also eine standardmäßig sichere Umgebung, statt sie Host für Host aufzubauen.