Die Passwortanmeldung über SSH ist die größte offene Angriffsfläche eines gewöhnlichen Servers. Weder Fail2ban noch irgendein Schwellenwert helfen dagegen: Tausend Adressen mit je einem Versuch pro Stunde erreichen nie ein Limit, und sie raten genau so lange weiter, wie Raten überhaupt möglich ist. Schlüssel nehmen diese Möglichkeit weg, und von der ganzen Härtungsliste ist das die eine Einstellung, die die Lage qualitativ verändert.

Nur eines daran macht Angst: das Passwort abzuschalten und draußen zu bleiben. Hier die Reihenfolge, bei der das ausgeschlossen ist.

Der Schlüssel

Wird auf dem eigenen Rechner erzeugt, nicht auf dem Server:

ssh-keygen -t ed25519 -C "Arbeitsnotebook"

ed25519 statt RSA: kürzer, schneller und ohne Fragen zur Schlüssellänge. RSA brauchen Sie nur, wenn Sie auf etwas sehr Altes zugreifen müssen; dann -t rsa -b 4096.

Eine Passphrase auf den Schlüssel zu setzen lohnt sich: Die Schlüsseldatei kann vom Notebook gestohlen werden, und ohne Passphrase funktioniert sie sofort. Eingeben müssen Sie sie nicht jedes Mal — dafür ist ssh-agent da, und unter macOS und den meisten Desktop-Linux-Systemen läuft er bereits.

Das Kopieren auf den Server ist ein Befehl, solange das Passwort noch funktioniert:

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@203.0.113.25

Ist ssh-copy-id nicht verfügbar, wird der Inhalt der .pub-Datei als Zeile an ~/.ssh/authorized_keys auf dem Server angehängt. Die Rechte sind wichtig: das Verzeichnis .ssh 700, die Datei 600, Eigentümer der Benutzer selbst. Bei anderen Rechten weigert sich sshd stillschweigend, die Datei zu lesen — und das ist die häufigste Ursache für „der Schlüssel funktioniert nicht“.

Die Prüfung, auf die es ankommt

Bevor Sie irgendetwas abschalten, öffnen Sie eine zweite Verbindung, ohne die erste zu schließen:

ssh -o PasswordAuthentication=no user@203.0.113.25

Die Option verbietet dem Client, auf ein Passwort zurückzufallen — wenn die Anmeldung also gelingt, dann per Schlüssel. Solange dieser Befehl nicht durchläuft, gehen Sie keinen Schritt weiter. Und die erste Verbindung bleibt bis zum Schluss offen: Über sie reparieren Sie alles, was Sie kaputt machen.

Das Abschalten und ein nicht offensichtlicher Haken

Die Einstellungen kommen in eine eigene Datei, damit ein Paket-Update sie nicht überschreibt. Aber der Dateiname ist entscheidend:

sudo tee /etc/ssh/sshd_config.d/10-hardening.conf <<'EOF'
PasswordAuthentication no
PermitRootLogin no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
LogLevel VERBOSE
EOF

Der Punkt ist: OpenSSH verwendet den zuerst gefundenen Wert eines Parameters, nicht den letzten wie fast überall sonst. Die Dateien in sshd_config.d werden alphabetisch gelesen, und Cloud-Abbilder von Ubuntu legen dort 50-cloud-init.conf ab, in der häufig PasswordAuthentication yes steht. Ihre Datei mit der Nummer 90 bewirkt in dieser Lage nichts: Die Einstellung scheint vorhanden, das Passwort funktioniert weiter. Daher die Nummer 10 — sie wird früher gelesen.

Was tatsächlich herauskam, sehen Sie ohne Raten:

sudo sshd -T | grep -Ei 'passwordauth|permitrootlogin|pubkeyauth'

Dieser Befehl gibt die wirksame Konfiguration nach allen Einbindungen aus. Ihm glauben Sie, nicht dem Inhalt der Dateien.

Danach Syntaxprüfung und sanftes Neuladen des Dienstes:

sudo sshd -t && sudo systemctl reload ssh

sshd -t ist Pflicht: Ein Tippfehler in der Konfiguration lässt den Dienst bei restart liegen und Sie draußen. reload trennt außerdem keine offenen Sitzungen.

Ubuntu 24.04: Der Port steht nicht dort, wo Sie denken

Eine eigene Falle neuerer Ubuntu-Versionen: sshd wird dort über einen systemd-Socket gestartet. In diesem Modus bewirkt die Zeile Port in der sshd_config nichts — es lauscht der Socket, nicht der Dienst. Wenn Sie den Port ändern, muss er bearbeitet werden:

sudo systemctl edit ssh.socket

und ListenStream= (ein leerer Wert setzt den vorherigen zurück) muss den neuen Port benennen. Das verräterische Symptom: Die Konfiguration ist geändert, der Dienst neu gestartet, und der Server antwortet weiterhin auf 22.

Zum Thema Portwechsel: Als Schutz wirkt er nicht — Scanner finden einen Dienst auf jedem Port binnen Minuten. Sein einziger Effekt sind ruhigere Protokolle, weil das massenhafte Raten nur auf 22 läuft. Das ist bequem, aber verwechseln Sie es nicht mit Sicherheit.

Wer sich überhaupt anmelden darf

Eine nützliche Ergänzung ist eine ausdrückliche Liste:

AllowUsers deploy admin

Alles, was nicht aufgeführt ist, wird abgewiesen, noch bevor der Schlüssel geprüft wird. Damit ist auch der Fall abgedeckt, dass irgendein Paket einen Systembenutzer mit Shell und Heimatverzeichnis anlegt.

Ein zweiter Weg hinein

Ein Schlüssel auf einem Notebook ist ein einzelner Ausfallpunkt. Die Platte stirbt, das Notebook geht verloren, und der Server ist für immer unerreichbar. Ein vernünftiges Minimum:

  • ein zweiter Schlüssel von einem anderen Gerät in authorized_keys;
  • eine Kopie des privaten Schlüssels im Passwortmanager oder auf einem verschlüsselten Stick;
  • ein erprobter Konsolenzugang beim Hoster — VNC oder seriell. Erprobt heißt, dass Sie sich darüber mindestens einmal angemeldet haben, nicht dass „es irgendwo im Panel einen Knopf gibt“.

Sehen Sie bei der Gelegenheit nach, was in authorized_keys bereits liegt — bei Ihrem Benutzer und bei root. Ein fremder Schlüssel dort überlebt jeden Passwortwechsel und bleibt ein funktionierender Zugang.

Danach

Das Passwortraten verschwindet nicht, es wird nur nutzlos: In den Protokollen bleiben Tausende Failed password-Zeilen, von denen keine mit Erfolg enden kann. Betrachtenswert sind jetzt die erfolgreichen Anmeldungen: von welcher Adresse, unter welchem Benutzer, zu welcher Zeit. Eine erfolgreiche Schlüsselanmeldung von einer unbekannten Adresse ist ein weit wichtigeres Ereignis als eine Million Fehlversuche — und im allgemeinen Strom weit schwerer zu bemerken. Genau dieses Bild zeigt die Demo-Seite unten.