SSH-Passwortanmeldung abschalten, ohne sich auszusperren
Keys-only ist die stärkste Einzeländerung an einem exponierten SSH-Server. Die sichere Reihenfolge, die Konfigurationszeilen, auf die es wirklich ankommt, und was es nicht behebt.
Warum das die wertvollste Änderung ist
Nahezu jede Übernahme eines Linux-Servers im Internet beginnt mit einem gültigen Passwort — erraten, aus dem Leak eines anderen wiederverwendet oder gephisht. Schalten Sie die Passwortauthentifizierung ab, und diese ganze Kategorie hört auf, möglich zu sein. Nicht schwerer: unmöglich. Es gibt kein Passwort zu erraten.
Nichts sonst auf einer Härtungsliste kommt dem beim Aufwand nahe. Es sind zwei Konfigurationszeilen und ein Reload.
Aufgeschoben wird es aus Angst, es falsch zu machen, und die Sorge ist berechtigt: Bei falscher Reihenfolge trennen Sie sich von einer Maschine, die Sie nur über SSH erreichen. Der Rest dieses Guides ist genau diese Reihenfolge.
Die sichere Abfolge
Jeder Schritt wird verifiziert, bevor der nächste kommt, und die Sitzung, in der Sie sind, bleibt durchgehend offen. Schließen Sie sie erst ganz am Ende.
Zuerst einen Schlüssel erzeugen, falls keiner da ist. Ed25519 ist der aktuelle Standard: kürzer, schneller und mindestens so stark wie ein 4096-Bit-RSA-Schlüssel.
# 1. Auf der eigenen Maschine, nicht auf dem Server
ssh-keygen -t ed25519 -C "du@example.com"
# 2. Öffentlichen Schlüssel auf den Server kopieren (fragt ein letztes Mal nach dem Passwort)
ssh-copy-id user@server
# 3. Aus einem ZWEITEN Terminal prüfen, ohne das erste zu schließen
ssh -o PreferredAuthentications=publickey -o PasswordAuthentication=no user@serverDie Konfiguration, auf die es ankommt
Erst nachdem Schritt 3 gelingt, die Serverkonfiguration bearbeiten. Auf modernen Distributionen ist die zu bearbeitende Datei womöglich nicht sshd_config selbst: viele liefern ein Verzeichnis /etc/ssh/sshd_config.d/, dessen Dateien eingebunden werden und überschreiben können, was Sie weiter oben schreiben.
Vier Einstellungen erledigen die Arbeit:
# /etc/ssh/sshd_config.d/10-hardening.conf (oder direkt sshd_config)
PasswordAuthentication no
KbdInteractiveAuthentication no # älterer Name: ChallengeResponseAuthentication
PermitRootLogin prohibit-password # oder 'no', wenn root nie direkt verbindet
PubkeyAuthentication yes
# Vor dem Reload immer die Konfiguration prüfen — das fängt Tippfehler,
# die sshd sonst gar nicht zurückkommen ließen:
sudo sshd -t
# Dann reload statt restart: bestehende Sitzungen überleben
sudo systemctl reload ssh # oder 'sshd' in der RHEL-FamiliePrüfen, dass es gegriffen hat
Trauen Sie nicht der Konfigurationsdatei — fragen Sie sshd, worauf es tatsächlich aufgelöst hat. sshd -T druckt die wirksame Konfiguration nach allen Includes und Überschreibungen:
sudo sshd -T | grep -iE 'passwordauthentication|kbdinteractiveauthentication|permitrootlogin'
# erwartet:
# passwordauthentication no
# kbdinteractiveauthentication no
# permitrootlogin prohibit-password
# Und von außen beweisen: das muss jetzt abgewiesen werden
ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password user@serverWas es nicht behebt
Keys-only entfernt das Rate-Risiko. Es entfernt weder den Verkehr noch jeden Weg hinein.
Die Bots verbinden sich weiter. Sie kennen Ihre Konfiguration nicht, bieten also weiter Passwörter an und werden weiter abgewiesen — jeder Versuch kostet nach wie vor eine TCP-Verbindung, einen sshd-Fork und eine Protokollzeile. Ihr Authentifizierungsprotokoll füllt sich weiter mit Rauschen, und das eine Ereignis, das Sie brauchten, altert weiter heraus. Irgendetwas muss die Quellen trotzdem blockieren.
Und ein privater Schlüssel ist eine Datei. Auf einem gestohlenen Laptop, in einem versehentlich committeten Repository, in der Umgebung eines CI-Runners. Schützen Sie Schlüssel mit einer Passphrase, halten Sie sie von geteilten Maschinen fern und rotieren Sie sie, wenn jemand geht — ein geleakter Schlüssel ist genauso schlimm wie ein geleaktes Passwort.
Es tut auch nichts gegen einen ungepatchten sshd, einen exponierten Dienst auf einem anderen Port oder eine verwundbare Anwendung auf demselben Host. Es ist die beste verfügbare Einzeländerung und eine Maßnahme unter mehreren.
Das Gegenstück
Mit abgeschalteten Passwörtern bleibt das Volumen. SSH Protector liest denselben Authentifizierungsstrom, sperrt die Quellen, die weiter ankommen — subnetzweise, dauerhaft, beim Booten wiederhergestellt — und setzt Ihre eigene Adresse auf die Whitelist, bevor irgendetwas blockiert wird.
Er ermittelt den echten SSH-Port aus sshds Konfiguration, statt 22 anzunehmen, ein bereits verlegter Server ist also ohne Konfiguration abgedeckt.
Keys-only gegen das Risiko. Quellsperren gegen die Last — und für das lesbare Protokoll, in dem Sie das eine Ereignis bemerken, auf das es ankommt.
FAQ
- Wie schalte ich die SSH-Passwortanmeldung sicher ab?
- Schlüssel erzeugen, mit ssh-copy-id kopieren, dann aus einem zweiten Terminal prüfen, dass die Anmeldung nur mit Schlüssel funktioniert, während die erste Sitzung offen bleibt. Erst dann PasswordAuthentication no und KbdInteractiveAuthentication no setzen, sshd -t für die Syntax laufen lassen und reload statt restart. Die offene erste Sitzung macht einen Fehler behebbar.
- Warum fragt SSH trotz PasswordAuthentication no weiter nach einem Passwort?
- Fast immer aus einem von zwei Gründen. Entweder steht KbdInteractiveAuthentication noch auf yes, sodass PAM über einen anderen Mechanismus eine Passwortabfrage anbietet, oder eine Datei in /etc/ssh/sshd_config.d/ wird nach Ihrer Änderung eingebunden und überschreibt sie. Führen Sie sudo sshd -T | grep -i passwordauth aus, um den Wert zu sehen, auf den sshd tatsächlich aufgelöst hat.
- Ed25519 oder RSA?
- Ed25519, sofern nichts in Ihrer Umgebung damit nicht umgehen kann. Die Schlüssel sind weit kürzer, die Prüfung schneller und die Sicherheit mindestens gleichwertig zu einem 4096-Bit-RSA-Schlüssel. RSA bleibt ein gültiger Rückfall für alte Appliances und Legacy-Clients; wenn Sie es nutzen, erzeugen Sie mindestens 4096 Bit.
- Stoppt Keys-only-SSH Brute-Force-Versuche?
- Es sorgt dafür, dass sie nie gelingen können, und das ist der Punkt. Ihre Zahl senkt es nicht: Die Bots können Ihre Konfiguration nicht kennen und verbinden sich unbegrenzt weiter, um Passwörter anzubieten. Sie zahlen weiterhin für jeden Versuch in Verbindungen, Forks und Protokollzeilen, das Blockieren der Quellen lohnt sich also weiterhin.