WardtermSSH-Client
DE
Herunterladen

Passwort-Anmeldung für SSH deaktivieren

Prüfen Sie zuerst, dass eine Schlüssel-Anmeldung funktioniert, und lassen Sie eine Sitzung offen. Legen Sie dann /etc/ssh/sshd_config.d/00-no-passwords.conf mit PasswordAuthentication no und KbdInteractiveAuthentication no an, führen Sie sudo sshd -t aus, laden Sie den Dienst neu und prüfen Sie das Ergebnis mit sudo sshd -T. Allein sshd_config zu bearbeiten bleibt oft wirkungslos, weil eine frühere Drop-in-Datei Vorrang hat.

Bevor die Passwörter wegfallen, braucht jeder Server Ihren Schlüssel, und Wardterm kann ihn dort ablegen. Zeigen

Aktualisiert am . Ausgeführt mit OpenSSH 10.0 unter Debian 13 und einem Client unter macOS, einschließlich der Überschreibung durch Drop-in-Dateien, der Passwort-Anmeldung über keyboard-interactive und sshd, das bei einer fehlerhaften Datei stehen bleibt.

Bevor Sie etwas ändern

Beweisen Sie, dass ein Schlüssel funktioniert. Dieser Befehl probiert nur Schlüssel, ein Passwort kann also kein Problem verdecken:

ssh -o PreferredAuthentications=publickey user@server

Noch kein Schlüssel? Erzeugen Sie einen Ed25519-SSH-Schlüssel und legen Sie ihn zuerst auf den Server.

Prüfen Sie, dass dieses Konto sudo nutzen kann, und lassen Sie bis zum letzten Schritt eine angemeldete Sitzung offen. Bestehende Sitzungen liefen in unserem Test nach einem Reload weiter, diese Sitzung ist also Ihr Rückweg, falls die neuen Einstellungen Sie aussperren. Hat Ihr Anbieter eine Web-Konsole, suchen Sie sie jetzt heraus.

Sehen, was heute gilt

sudo sshd -T | grep -iE '^(passwordauthentication|kbdinteractiveauthentication|usepam|permitrootlogin) '

sshd -T gibt die Werte aus, die sshd nach dem Lesen aller Dateien wirklich verwendet. Verlassen Sie sich darauf, nicht auf das, was Sie in sshd_config lesen.

Warum das Bearbeiten von sshd_config oft nichts bewirkt

Bei den meisten Einstellungen verwendet sshd den ersten Wert, den es findet. Unter aktuellem Debian und Ubuntu steht die Zeile Include /etc/ssh/sshd_config.d/*.conf weit oben in sshd_config, die Drop-in-Dateien werden also zuerst gelesen, in der Reihenfolge ihrer Namen. Prüfen Sie Ihr System:

grep -n Include /etc/ssh/sshd_config
ls /etc/ssh/sshd_config.d/

Cloud-Images liefern oft eine Datei wie 50-cloud-init.conf mit PasswordAuthentication yes mit. Diesen Fall haben wir getestet: Mit dieser Datei zeigte sshd -T weiterhin yes, obwohl in sshd_config PasswordAuthentication no gesetzt war.

Eine Datei, die alphabetisch zuerst kommt, gewinnt gegen alle anderen, darum beginnt der Name unten mit 00. Gibt es keine Include-Zeile, wie auf Servern älter als OpenSSH 8.2 oder mit angepasster Datei, schreiben Sie die Einstellungen in sshd_config selbst, oberhalb jedes Match-Blocks, und entfernen Sie frühere Zeilen, die sie setzen.

Die Drop-in-Datei anlegen

sudo tee /etc/ssh/sshd_config.d/00-no-passwords.conf >/dev/null <<'EOF'
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password
EOF

KbdInteractiveAuthentication muss ebenfalls aus sein. Mit nur PasswordAuthentication no und dieser Einstellung auf an akzeptierte unser Testserver weiterhin das Kontopasswort, weil PAM es über keyboard-interactive abfragt. Vor OpenSSH 8.7 hieß die Option ChallengeResponseAuthentication, und der alte Name funktioniert weiterhin als Alias.

UsePAM kann auf yes bleiben. PAM erledigt auch Kontoprüfungen und den Sitzungsaufbau und bietet mit den zwei Zeilen oben keine Passwortabfrage mehr an. Manche Distributionen warnen davor, es abzuschalten, lassen Sie es also in Ruhe.

PermitRootLogin prohibit-password lässt root sich nur mit einem Schlüssel anmelden. Nehmen Sie no, wenn sich niemand als root anmelden soll. Bis OpenSSH 10.0 zeigt sshd -T prohibit-password unter dem älteren Namen without-password.

Datei testen, dann neu laden

sudo sshd -t
sudo sshd -T | grep -iE '^(passwordauthentication|kbdinteractiveauthentication) '

sshd -t gibt nichts aus, wenn die Konfiguration gültig ist. Überspringen Sie es nicht: Wir haben das Reload-Signal an einen sshd mit einer ungültigen Zeile in einer Drop-in-Datei geschickt, und er beendete sich, sodass nichts mehr auf neue Verbindungen lauschte.

sudo systemctl reload ssh     # Debian, Ubuntu
sudo systemctl reload sshd    # RHEL, Fedora, Arch

Bevorzugen Sie reload gegenüber restart. Ein Reload bittet den laufenden sshd nur, seine Konfiguration neu zu lesen, und unsere offene Sitzung überstand es. Unter Debian 13 führt die Service-Datei vor dem Senden des Signals auch sshd -t aus, sodass eine fehlerhafte Datei dort das Neuladen stoppt, verlassen Sie sich aber nicht darauf, dass jede Distribution das tut.

Aus einem anderen Terminal bestätigen

Lassen Sie die offene Sitzung in Ruhe und probieren Sie von Ihrem eigenen Rechner eine Passwort-Anmeldung:

ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password,keyboard-interactive user@server

Das Ergebnis sollte Permission denied (publickey). sein, ohne Passwortabfrage. Prüfen Sie dann mit einer neuen Verbindung, dass Ihr Schlüssel weiterhin funktioniert. Erst danach schließen Sie die alte Sitzung.

Wenn weiterhin eine Passwortabfrage erscheint

  • Führen Sie sudo sshd -T erneut aus. Zeigt es yes, setzt eine andere Datei den Wert zuerst: Suchen Sie mit sudo grep -ri passwordauthentication /etc/ssh/.
  • Suchen Sie nach einem Match-Block. Er kann Passwörter für manche Benutzer oder Adressen wieder einschalten, und ein einfaches sshd -T zeigt das nicht. Übergeben Sie die Verbindungsdaten, um ihn auszuwerten: 
    sudo sshd -T -C user=user,host=example.com,addr=203.0.113.10 | grep -i ^passwordauthentication
  • Prüfen Sie, dass Sie diesen Server und diesen Port erreichen und nicht einen anderen Rechner hinter demselben Namen.
  • Die Abfrage einer Schlüssel-Passphrase ist keine Passwortabfrage. Sie kommt von Ihrem eigenen Rechner und entsperrt Ihren Schlüssel.

Fragen

Reicht PasswordAuthentication no?

Nicht immer. Ist KbdInteractiveAuthentication an, kann PAM das Passwort weiter über keyboard-interactive abfragen. Schalten Sie beides ab.

Warum steht in sshd_config no, aber Passwörter gehen trotzdem?

Eine Datei in /etc/ssh/sshd_config.d wird zuerst gelesen und gewinnt. Prüfen Sie den aktiven Wert mit sudo sshd -T.

Sollte ich UsePAM no setzen?

Nein. PAM übernimmt auch Kontoprüfungen und Sitzungen. Sind die beiden Einstellungen aus, fragt es nicht mehr nach einem Passwort.

Quellen

Mehr zu Schlüssel und Anmeldung

Alle Anleitungen