Kurze Antwort
Der Fehler permission denied publickey bedeutet, dass der Server Ihren öffentlichen Schlüssel nicht akzeptiert hat, obwohl das Passwort möglicherweise korrekt ist. Die häufigsten Ursachen sind ein falscher Schlüssel auf dem Client, falsche Berechtigungen für ~/.ssh und authorized_keys oder eine Einstellung in sshd_config. Prüfen Sie diese der Reihe nach und der Zugriff ist ohne Neuinstallation wiederhergestellt.
So erkennen Sie das Problem
- Die SSH-Anmeldung schlägt mit der Meldung Permission denied (publickey) fehl
- Das Passwort wird nicht abgefragt oder der Server lehnt sofort ab
- Derselbe Schlüssel funktionierte gestern, heute nicht mehr
- Die Anmeldung funktioniert von einem Rechner, von einem anderen nicht
- Nach einem Benutzerwechsel oder einer Server-Neuinstallation wird der Schlüssel abgelehnt
Häufigste Ursachen
Falscher oder nicht vorhandener privater Schlüssel
Der SSH-Client versucht sich mit einem Schlüssel anzumelden, den der Server nicht kennt, oder der Schlüssel ist nicht in den Agenten geladen. Prüfen Sie, welcher Schlüssel dem Server tatsächlich angeboten wird.
Falsche Berechtigungen für .ssh und authorized_keys
Wenn das Home-Verzeichnis, ~/.ssh oder authorized_keys zu weitreichende Berechtigungen haben, lehnt sshd sie aus Sicherheitsgründen ab. Das ist die häufigste Ursache nach dem manuellen Kopieren von Dateien.
Schlüssel nicht in authorized_keys für diesen Benutzer
Der Schlüssel wurde dem falschen Konto hinzugefügt, zum Beispiel root statt deploy, oder die Datei wurde überschrieben statt ergänzt. Der Server hat dann nichts zum Vergleichen.
sshd_config erlaubt keine Schlüsselanmeldung
Optionen wie PubkeyAuthentication, AuthorizedKeysFile oder AllowUsers können den Schlüssel oder den Benutzer ausschließen. Nach einer Konfigurationsänderung muss der Dienst neu geladen werden.
SELinux oder Home-Verzeichnis mit falschem Kontext
Auf Systemen mit SELinux kann die Datei einen falschen Sicherheitskontext haben, obwohl die Berechtigungen korrekt sind. Restorecon löst das Problem in der Regel.
Lösung Schritt für Schritt
- 1
Lesen Sie die genaue Meldung und den Benutzer
Starten Sie die Anmeldung mit
-v, um Details zu sehen:ssh -v benutzer@server. Suchen Sie in der Ausgabe, welche Schlüssel der Client anbietet und ob der Server alle ablehnt. Prüfen Sie auch, ob Sie den richtigen Benutzer und Port verwenden, denn der Fehler tritt oft nur für ein Konto auf. - 2
Prüfen Sie, welchen Schlüssel der Client verwendet
Führen Sie auf dem Client
ssh-add -laus, um die Schlüssel im Agenten zu sehen. Wenn ein anderer Schlüssel benötigt wird, geben Sie ihn explizit an:ssh -i ~/.ssh/id_ed25519 benutzer@server. In~/.ssh/configkönnen Sie für den HostIdentityFileundIdentitiesOnly yeshinzufügen, damit der Client keine falschen Schlüssel anbietet. - 3
Vergleichen Sie den Schlüssel-Fingerabdruck mit dem Server
Berechnen Sie auf dem Client den Fingerabdruck:
ssh-keygen -lf ~/.ssh/id_ed25519.pub. Prüfen Sie auf dem Server, wenn Sie einen anderen Zugang haben,ssh-keygen -lf ~/.ssh/authorized_keys. Die Fingerabdrücke müssen übereinstimmen; wenn nicht, wurde der Schlüssel nicht hinzugefügt oder dem falschen Benutzer hinzugefügt. - 4
Korrigieren Sie die Berechtigungen auf dem Server
Melden Sie sich über die Konsole oder ein anderes Konto an und führen Sie aus (ersetzen Sie
benutzerdurch den tatsächlichen Namen und/home/benutzerdurch den tatsächlichen Pfad zum Home-Verzeichnis; wenn Sie nicht root sind, fügen Siesudohinzu):chmod 700 /home/benutzer/.ssh,chmod 600 /home/benutzer/.ssh/authorized_keys,chmod go-w /home/benutzerundchown -R benutzer:benutzer /home/benutzer/.ssh. Der Eigentümer von.sshundauthorized_keyssollte dieser Benutzer sein. Wenn Sie sich bei den vorhandenen Berechtigungen nicht sicher sind, notieren Sie sie zuerst mitstat -c '%a %U:%G' /home/benutzer /home/benutzer/.ssh /home/benutzer/.ssh/authorized_keys. Dies löst die meisten Fälle nach dem manuellen Kopieren. - 5
Fügen Sie den öffentlichen Schlüssel an der richtigen Stelle hinzu
Fügen Sie den Inhalt der Datei
id_ed25519.pubin/home/benutzer/.ssh/authorized_keysdieses Benutzers in einer neuen Zeile hinzu, ohne vorhandene zu löschen. Wenn Siessh-copy-idverwenden, prüfen Sie, ob der Zielbenutzer korrekt ist. Überprüfen Sie nach der Änderung erneut die Berechtigungen aus dem vorherigen Schritt. - 6
Prüfen Sie sshd_config
Prüfen Sie in
/etc/ssh/sshd_config(oder einer Datei insshd_config.d)PubkeyAuthentication yes,AuthorizedKeysFile .ssh/authorized_keysund ob Sie durchAllowUsersoderDenyUsersblockiert werden. Erstellen Sie vor der Änderung eine Kopie der Datei. Führen Sie nach der Änderungsudo sshd -tzur Syntaxprüfung aus. - 7
Laden Sie den SSH-Dienst neu
Wenn die Konfiguration korrekt ist, wenden Sie sie mit
sudo systemctl reload sshdan (unter Debian/Ubuntu:sudo systemctl reload ssh). Ein Reload ist sicherer als ein Neustart, da bestehende Sitzungen nicht unterbrochen werden. Versuchen Sie dann die Anmeldung in einem neuen Terminal, ohne das alte zu schließen. - 8
Beheben Sie den SELinux-Kontext, falls aktiviert
Führen Sie auf Systemen mit SELinux
sudo restorecon -Rv /home/benutzer/.sshaus. Die Statusprüfung istgetenforce. Wenn das Problem weiterhin besteht, suchen Sie im Log/var/log/secureoder/var/log/auth.lognach Meldungen zur Schlüsselablehnung. Deaktivieren Sie SELinux nicht dauerhaft.
Wenn nichts hilft: Zugriff über die Konsole und Ersatzkonto
Wenn der Schlüssel auch nach allen Prüfungen nicht durchkommt, verwenden Sie die Konsole des Anbieters oder KVM-Zugriff auf den Server und melden Sie sich mit Passwort oder über den Recovery-Modus an. Lesen Sie dann aus /var/log/auth.log oder /var/log/secure den genauen Ablehnungsgrund, denn sshd schreibt dort, ob das Problem bei Berechtigungen, Eigentümer oder Konfiguration liegt. Gute Praxis ist, immer ein zweites Administratorkonto mit Schlüssel zu haben und PasswordAuthentication nicht zu deaktivieren, bevor Sie bestätigt haben, dass der Schlüssel funktioniert. Wenn der Server in der Cloud läuft, prüfen Sie auch, ob der öffentliche Schlüssel in der Systemsteuerung des Anbieters mit der Instanz verknüpft ist, denn beim Neuerstellen der Instanz geht er manchmal verloren.
So beugen Sie vor
- Halten Sie ein Ersatz-Administratorkonto mit gültigem Schlüssel bereit
- Prüfen Sie nach jeder Änderung von sshd_config die Syntax mit `sudo sshd -t` vor dem Reload
- Verwenden Sie `ssh-copy-id` und kopieren Sie Dateien nicht manuell ohne Berechtigungseinstellungen
- Prüfen Sie gelegentlich, ob der Schlüssel im Agenten mit dem auf dem Server übereinstimmt
Wann Sie einen Profi rufen sollten
Wenn Sie keine Konsole, kein Ersatzkonto und keinen gültigen Schlüssel haben und der Server produktiv ist, wenden Sie sich besser an den IT-Support, als mit sshd_config zu experimentieren und einen vollständigen Zugriffsverlust zu riskieren.
IT-Infrastruktur-Wartung · Server, Netzwerke, Backup, Sicherheit und HelpdeskHäufige Fragen
Hängt der publickey-Fehler mit dem Passwort zusammen?
Nein. Die Meldung Permission denied (publickey) bedeutet, dass der Server den Schlüssel abgelehnt hat, nicht das Passwort. Das Passwort wird überhaupt nicht geprüft, wenn die Schlüsselanmeldung die einzige erlaubte Methode ist.
Warum funktioniert der Schlüssel für root, aber nicht für einen normalen Benutzer?
Weil authorized_keys aus dem Home-Verzeichnis des angemeldeten Benutzers gelesen wird. Ein Schlüssel, der im Home-Verzeichnis von root hinzugefügt wurde, gilt nicht für ein anderes Konto, und Berechtigungen sowie Eigentümer werden für jeden Benutzer separat geprüft.
Kann ich die Passwortanmeldung wiederherstellen, bis ich den Schlüssel gelöst habe?
Ja, wenn Sie Konsolenzugriff haben und ein Passwort gesetzt ist. Aktivieren Sie vorübergehend `PasswordAuthentication yes` in sshd_config, führen Sie einen Reload aus und stellen Sie die Option direkt nach der Lösung des Schlüsselproblems wieder auf `no`. Das ist sicherheitsrisikoreich, verwenden Sie daher ein starkes Passwort und beschränken Sie den Zugriff nach Möglichkeit per Firewall.