Passwort-Login aus, Schlüssel weg? So schaltest du SSH auf Schlüssel um, ohne dich auszusperren

Du kennst das: Im Log stapeln sich die fehlgeschlagenen Anmeldeversuche von Bots aus aller Welt, und irgendwann denkst du dir, jetzt ist Schluss. Also SSH Passwort Login deaktivieren, nur noch Schlüssel zulassen, fertig. Das dauert fünf Minuten. Die eigentliche Arbeit kommt später, nämlich an dem Tag, an dem der Laptop mit dem Schlüssel im Zug liegen bleibt.

In meinem Fall ging es um einen Raspberry Pi mit Kali Linux, den ich per SSH vom Mac aus verwalte. Bevor ich die Passwort-Anmeldung abgeschaltet habe, habe ich den privaten Schlüssel verschlüsselt in Passbolt abgelegt und die Wiederherstellung einmal komplett durchgespielt. Genau in dieser Reihenfolge zeige ich es dir hier, damit du (oder dein zukünftiges Ich) sich nicht selbst aussperrt.

Ziel

• SSH-Anmeldung am Server (hier ein Raspberry Pi mit Kali Linux) nur noch per Schlüssel.
• Privater Schlüssel als verschlüsselte Notiz in Passbolt.
• Ein erprobter Weg zurück, wenn der Schlüssel auf dem Rechner verloren geht.

Voraussetzungen

• Ein Client (hier macOS) mit funktionierender Schlüssel-Anmeldung, z. B. ~/.ssh/id_ed25519_pi und in ~/.ssh/config:

text
Host pi
HostName 192.0.2.10
User kali
IdentityFile ~/.ssh/id_ed25519_pi
IdentitiesOnly yes

• Ein Passbolt-Konto (ab Version 5 gibt es den Ressourcentyp „Notizen“).
• Ein zweiter Zugang zum Server, der nicht über SSH läuft (Bildschirm und Tastatur, Remote Desktop o. Ä.) – für den Fall, dass etwas schiefgeht.

Schritt 1: Schlüssel in Passbolt sichern

Den privaten Schlüssel nicht anzeigen, sondern direkt in die Zwischenablage kopieren:

pbcopy < ~/.ssh/id_ed25519_pi

In Passbolt: Neu → Notizen. Nicht „Passwort“ – dort können die Zeilenumbrüche verloren gehen, und ohne sie ist der Schlüssel unbrauchbar.

Name z. B. „SSH-Schlüssel Pi (Laptop)“. Den Schlüssel mit ⌘ + V in das Feld Inhalt der Notiz einfügen – das liegt unter Geheimnisse und wird verschlüsselt. Die erste Zeile muss -----BEGIN OPENSSH PRIVATE KEY----- lauten, die letzte -----END OPENSSH PRIVATE KEY-----.

In die Beschreibung (Metadaten) nur Unkritisches: Zielrechner, Benutzer, Dateiname, Kurzanleitung zur Wiederherstellung (siehe Schritt 3). Den Schlüssel selbst nie in die Beschreibung.

Danach die Zwischenablage leeren:

pbcopy < /dev/null

Schritt 2: SSH Passwort Login deaktivieren

Eine eigene Konfigurationsdatei anlegen, statt die Hauptdatei zu ändern:

sudo tee /etc/ssh/sshd_config.d/10-nur-schluessel.conf >/dev/null <<'EOF'
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no
EOF

Konfiguration prüfen, wirksame Werte anzeigen, dann neu laden – bestehende Verbindungen bleiben offen:

sudo sshd -t
sudo sshd -T | grep -iE '^(passwordauthentication|kbdinteractiveauthentication|permitrootlogin)'
sudo systemctl reload ssh

Wichtig: Die SSH-Sitzung, mit der du arbeitest, offen lassen, bis der Test unten erfolgreich war.

So prüfst du es

Passwort erzwingen – muss abgelehnt werden:

ssh -o PreferredAuthentications=password,keyboard-interactive -o PubkeyAuthentication=no pi
# kali@192.0.2.10: Permission denied (publickey).

Steht dort nur noch (publickey), bietet der Server kein Passwort mehr an. Mit Schlüssel muss es weiter gehen:

ssh pi 'echo ok'

Schritt 3: Notfall – Schlüssel aus Passbolt wiederherstellen

Und jetzt der Teil, den man üben sollte, bevor man ihn braucht. Zum Test den Schlüssel kurz beiseitelegen:

mv ~/.ssh/id_ed25519_pi ~/.ssh/id_ed25519_pi.test
ssh pi 'echo ok'          # muss jetzt scheitern

Wiederherstellen:

1. In Passbolt die Notiz öffnen und den Inhalt kopieren.
2. Im Terminal in die Datei schreiben, Rechte setzen, Zwischenablage leeren:

bash
umask 077
pbpaste > ~/.ssh/id_ed25519_pi
chmod 600 ~/.ssh/id_ed25519_pi
pbcopy < /dev/null

3. Prüfen und anmelden:

bash
head -1 ~/.ssh/id_ed25519_pi # -----BEGIN OPENSSH PRIVATE KEY-----
ssh-keygen -lf ~/.ssh/id_ed25519_pi # Fingerabdruck vergleichen
ssh pi 'echo ok'

4. Nur beim Test: Ist alles in Ordnung, die Testkopie löschen: rm ~/.ssh/id_ed25519_pi.test.

Auf einem neuen Rechner zusätzlich den Eintrag in ~/.ssh/config wieder anlegen (siehe Voraussetzungen).

Rückweg

• Passwort-Anmeldung wieder erlauben: sudo rm /etc/ssh/sshd_config.d/10-nur-schluessel.conf && sudo systemctl reload ssh.
• Kein Schlüssel und kein Passbolt greifbar: über Bildschirm/Tastatur oder Remote Desktop anmelden und einen neuen öffentlichen Schlüssel in ~/.ssh/authorized_keys eintragen.

Stolperstellen aus der Praxis

• sshd -T schreibt in neuen OpenSSH-Versionen CamelCase (PasswordAuthentication no). Ein grep auf Kleinschreibung findet nichts – und wenn der Reload mit && daran hängt, wird er stillschweigend übersprungen. Daher grep -i.
• Erst nach dem Reload gilt die neue Einstellung. Bietet der Server beim Test noch (publickey,password) an, wurde nicht neu geladen.
• Ein laufender ssh-agent verfälscht den Test. Vorher mit ssh-add -l prüfen, dass der Schlüssel nicht im Agenten steckt – sonst klappt die Anmeldung auch ohne Datei.
• Ältere sshd_config nach Upgrades: Wer Konfigurationsdateien bei Upgrades behalten hat, sollte prüfen, ob Include /etc/ssh/sshd_config.d/*.conf vor den eigenen Einstellungen steht. Bei OpenSSH gilt der erste gefundene Wert.
• Apps wie Termius auf dem Smartphone melden sich oft per Passwort an. Danach brauchen sie einen eigenen Schlüssel, den man zusätzlich in authorized_keys einträgt.
• Universal Clipboard: Auf Apple-Geräten kann die Zwischenablage aufs iPhone wandern. Deshalb nach dem Kopieren sofort leeren.

Fazit

Die Passwort-Anmeldung abzuschalten ist der leichte Teil, das ist eine Datei mit drei Zeilen. Der Praxiswert steckt im Drumherum: den Schlüssel vorher an einem zweiten Ort sichern, die Wiederherstellung einmal echt durchspielen und einen Weg zum Server haben, der nicht über SSH läuft. Wer das einmal gemacht hat, schaltet das Passwort mit gutem Gewissen ab. Wer es weglässt, merkt den Unterschied genau einmal, und dann meist an einem Freitagabend.