SSH: „Permission denied (publickey)“ beheben

Was „Permission denied (publickey)“ tatsächlich bedeutet

„Permission denied (publickey)“ bedeutet, dass Ihr Client einen oder mehrere öffentliche Schlüssel gesendet hat und der Server keinen davon akzeptiert hat. Das Netzwerk funktioniert, und sshd läuft: Die Ablehnung erfolgt im letzten Schritt der Authentifizierung. Die Fehlerbehebung basiert nicht auf Vermutungen, denn ssh -v zeigt Ihnen, welche von fünf Ursachen vorliegt.

Die Angaben in Klammern bezeichnen die Authentifizierungsmethoden, die der Server akzeptieren wollte. Permission denied (publickey) allein bedeutet, dass die Passwortanmeldung auf diesem Server deaktiviert ist. Es gibt daher keine Möglichkeit, auf ein Passwort auszuweichen. Permission denied (publickey,password) bedeutet, dass Passwörter angeboten wurden und auch diese Authentifizierung fehlgeschlagen ist.

Eine Meldung deckt fünf unterschiedliche Fehler ab und bleibt absichtlich ungenau. Ein Server, der mit „Benutzer nicht vorhanden“ oder „Dieser Schlüssel ist nicht installiert“ antworten würde, könnte Angreifern beim Ermitteln gültiger Konten helfen. Beginnen Sie daher nicht damit, Schlüssel auszutauschen und Konfigurationsdateien zu bearbeiten. Führen Sie einen Befehl aus, lesen Sie drei Ausgabezeilen und grenzen Sie die fünf möglichen Ursachen auf eine ein.

Führen Sie zuerst ssh -v aus und lesen Sie drei Zeilen

Wiederholen Sie den fehlgeschlagenen Befehl mit hinzugefügtem -v:

ssh -v deploy@203.0.113.10

Eine gekürzte, aber realistische Ausgabe sieht so aus:

OpenSSH_9.6p1 Ubuntu-3ubuntu13, OpenSSL 3.0.13 30 Jan 2024
debug1: Connecting to 203.0.113.10 [203.0.113.10] port 22.
debug1: Connection established.
debug1: Authenticating to 203.0.113.10:22 as 'deploy'
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Will attempt key: /home/you/.ssh/id_ed25519 ED25519 SHA256:0eL/8sBw... agent
debug1: Offering public key: /home/you/.ssh/id_ed25519 ED25519 SHA256:0eL/8sBw... agent
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
deploy@203.0.113.10: Permission denied (publickey).

Drei Zeilen enthalten alle benötigten Informationen.

Authenticating to 203.0.113.10:22 as 'deploy' ist der Benutzername, der tatsächlich verwendet wird. Es ist nicht unbedingt der gewünschte Name, sondern der Name, den ssh aus der Befehlszeile, aus ~/.ssh/config oder aus Ihrem lokalen Anmeldenamen ermittelt hat.

Authentications that can continue: publickey ist die Liste der vom Server akzeptierten Methoden. Sie wird gesendet, bevor ein Schlüssel ausprobiert wird. Fehlt publickey in dieser ersten Liste, ist die Anmeldung per Public Key auf dem Server deaktiviert. Dann kann kein Schlüssel funktionieren.

Offering public key: ... steht für jeden Schlüssel, den Ihr Client tatsächlich gesendet hat, in einer eigenen Zeile. Die Zeile nennt die Quelldatei und den SHA256-Fingerabdruck des Schlüssels. Ein Schlüssel ohne Offering-Zeile wurde nie an den Server gesendet.

Teilen Sie das Problem nun in zwei Fälle auf:

• Es gibt keine Offering public key-Zeile für den erwarteten Schlüssel. Der Fehler liegt auf Ihrem Rechner, weil der Server Ihren Schlüssel überhaupt nicht gesehen hat.
• Der Schlüssel wird angeboten, und Authentications that can continue: publickey wird erneut ausgegeben. Der Server hat diesen Schlüssel empfangen und abgelehnt. Der Fehler liegt daher auf dem Server.

Die folgenden Ursachen sind danach geordnet, wie häufig sie sich als zutreffende Erklärung herausstellen.

Ursache 1: Sie verbinden sich mit dem falschen Benutzernamen

Die häufigste Ursache ist zugleich die unspektakulärste. sshd, der SSH-Daemon (Secure Shell), teilt Ihnen nie mit, dass ein Account nicht existiert. Er führt den gesamten Austausch für einen erfundenen Benutzernamen durch und verweigert die Verbindung erst am Ende mit derselben Meldung. Das verhindert, dass gültige Accountnamen preisgegeben werden, denn diese Information hilft Angreifern. Ein Tippfehler im Benutzernamen sieht daher genauso aus wie ein defekter Schlüssel.

Prüfen Sie zuerst die Zeile Authenticating to ... as. Wenn dort Ihr Laptop-Login statt des Server-Accounts genannt wird, haben Sie den Benutzernamen im Befehl weggelassen.

ssh -v deploy@203.0.113.10
ssh -v root@203.0.113.10

Der Standard-Account hängt vom Image ab, das Ihr Provider erstellt. Im August 2026 enthalten Ubuntu-Cloud-Images normalerweise einen ubuntu-Account, Debian-Images enthalten debian oder admin, Rocky Linux und AlmaLinux enthalten rocky und almalinux, und viele VPS-Provider installieren Ihren Schlüssel stattdessen direkt in root. Im Control Panel Ihres Providers ist festgehalten, welchen Account er erstellt hat. Kein Befehl, der außerhalb des Servers ausgeführt wird, kann diese Information abfragen.

Ein Host-Block in ~/.ssh/config legt den Benutzernamen ebenfalls fest. Dieser hat Vorrang vor Ihrem lokalen Login-Namen:

Host vps-prod
  HostName 203.0.113.10
  User deploy

Wenn Sie den Account selbst erstellt haben und sich anschließend nicht als dieser anmelden konnten, wurde der Schlüssel wahrscheinlich für den Standardbenutzer des Images installiert und nie auf den neuen Account kopiert. Dieser Schritt gehört zu den ersten zehn Minuten auf einem neuen VPS und wird leicht übersprungen.

Ursache 2: Der Schlüssel, den Sie zu senden glauben, wird nicht gesendet

Standardmäßig bietet ssh nur die Schlüssel aus ssh-agent sowie eine feste Gruppe von Dateinamen aus ~/.ssh an: id_ed25519, id_ecdsa, id_rsa und die Hardware- und DSA-Varianten dieser Namen. Ein unter ~/.ssh/vps-prod gespeicherter Schlüssel ist für ssh unsichtbar, bis Sie ihn angeben. Deshalb enthält die ausführliche Ausgabe dafür keine Offering public key-Zeile.

Geben Sie die Datei an und verhindern Sie, dass die Schlüssel des Agents an ihre Stelle treten:

ssh -i ~/.ssh/vps-prod -o IdentitiesOnly=yes deploy@203.0.113.10

-i allein reicht nicht aus, wenn der Agent Schlüssel enthält. ssh bietet die Schlüssel des Agents weiterhin zuerst und die angegebene Datei zuletzt an. Das ist relevant, weil der Server jeden abgelehnten Schlüssel gegen MaxAuthTries zählt. Der Standardwert ist 6. Ein Agent mit sieben Schlüsseln kann das Limit aufbrauchen, bevor Ihr korrekter Schlüssel erreicht wird. Die Meldung ändert sich dann zu:

Received disconnect from 203.0.113.10 port 22:2: Too many authentication failures

IdentitiesOnly=yes beschränkt den Versuch auf die angegebene Datei. Mit ssh-add -l sehen Sie, welche Schlüssel der Agent enthält. Mit ssh-add -D leeren Sie den Agent, wenn sich dort über Jahre alte Schlüssel angesammelt haben. Tragen Sie die Einstellungen anschließend ein, damit der nächste Login nicht davon abhängt, dass Sie sich an Flags erinnern:

Host vps-prod
  HostName 203.0.113.10
  User deploy
  IdentityFile ~/.ssh/vps-prod
  IdentitiesOnly yes

Es gibt noch eine weitere Falle auf der Client-Seite. ssh verwendet keinen privaten Schlüssel, den andere Konten auf Ihrem eigenen Rechner lesen können. ssh gibt eine Warnung aus und ignoriert den Schlüssel anschließend. Der Schlüssel wird daher nie angeboten, und der Server sieht ihn nie:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/you/.ssh/vps-prod' are too open.

chmod 600 ~/.ssh/vps-prod behebt das Problem. Beim Verschieben eines Schlüssels über einen USB-Stick oder eine Windows-Freigabe gehen die Dateirechte häufig verloren. Wo Schlüssel gespeichert werden und wie sie benannt werden, wird unter Grundlagen der SSH-Schlüsselverwaltung beschrieben.

Ursache 3: Der öffentliche Schlüssel wurde nie in authorized_keys eingetragen

Wenn ssh -v zeigt, dass der Schlüssel gesendet wird, der Server die Anmeldung aber weiterhin ablehnt, stellt sich als Nächstes die Frage, ob dieser Schlüssel in der Datei authorized_keys des Kontos steht. Öffnen Sie zur Prüfung die Konsole Ihres Providers, da Sie sich nicht per SSH anmelden können, um dies zu überprüfen.

sudo ls -l /home/deploy/.ssh/
sudo ssh-keygen -lf /home/deploy/.ssh/authorized_keys

ssh-keygen -lf für eine authorized_keys-Datei gibt für jeden Eintrag einen Fingerabdruck aus:

256 SHA256:0eL/8sBw... you@laptop (ED25519)
3072 SHA256:9Tq2yZk... old-laptop (RSA)

Vergleichen Sie diese Fingerabdrücke mit dem Fingerabdruck in Ihrer Offering public key-Zeile. Ist er nicht in der Liste enthalten, wurde der Schlüssel für dieses Konto nicht installiert, unabhängig davon, woran Sie sich bei den vorgenommenen Schritten erinnern.

Vier häufige Fehlerursachen:

• Sie haben statt der Datei .pub den privaten Schlüssel eingefügt. Eine Zeile mit einem öffentlichen Schlüssel beginnt mit ssh-ed25519 oder ssh-rsa. Ein privater Schlüssel beginnt mit -----BEGIN OPENSSH PRIVATE KEY-----.
• Der eingefügte Schlüssel wurde auf mehrere Zeilen umgebrochen. Jeder Eintrag muss genau in einer Zeile stehen. Ein umgebrochener Schlüssel wird daher als mehrere fehlerhafte Einträge gelesen und passt zu keinem Schlüssel.
• Der Schlüssel wurde in /root/.ssh/authorized_keys eingetragen, während Sie sich als deploy anmelden, oder umgekehrt. Die Datei gilt jeweils nur für ein Konto. Es gibt keine gemeinsame Datei.
• Das Feld "add my key" des Providers hat den Schlüssel nur für den Standardbenutzer des Images eingetragen. Das später erstellte Konto hat daher ein leeres Verzeichnis .ssh.

So fügen Sie einen Schlüssel sicher über die Konsole als root hinzu:

sudo install -d -m 700 -o deploy -g deploy /home/deploy/.ssh
sudo tee -a /home/deploy/.ssh/authorized_keys >/dev/null <<'EOF'
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIExampleKeyDataHere you@laptop
EOF
sudo chown deploy:deploy /home/deploy/.ssh/authorized_keys
sudo chmod 600 /home/deploy/.ssh/authorized_keys

Führen Sie anschließend erneut sudo ssh-keygen -lf /home/deploy/.ssh/authorized_keys aus. Der neue Fingerabdruck sollte jetzt in der Liste stehen. Von einem Rechner, auf dem Sie sich noch per Passwort anmelden können, erledigt ssh-copy-id -i ~/.ssh/vps-prod.pub deploy@203.0.113.10 dieselbe Aufgabe und setzt die Berechtigungsmodi korrekt.

Ursache 4: Warum sshd authorized_keys bei zu offenen Berechtigungen ignoriert

StrictModes yes ist der Standardwert von sshd. Mit dieser Einstellung verweigert sshd das Lesen von authorized_keys, wenn diese Datei, das Verzeichnis .ssh oder das Home-Verzeichnis des Kontos von einem anderen Benutzer als dem Eigentümer beschrieben werden kann. Der Grund ist direkt: Wenn die Gruppe oder alle anderen Benutzer in Ihr Home-Verzeichnis schreiben können, kann jedes Konto mit diesem Zugriff authorized_keys ersetzen und die Anmeldung übernehmen. sshd behandelt einen nicht vertrauenswürdigen Pfad so, als wäre kein Schlüssel vorhanden.

Der Client zeigt nur die allgemeine Meldung Permission denied an. Das Server-Log enthält den tatsächlichen Grund:

Authentication refused: bad ownership or modes for directory /home/deploy/.ssh

Oder, wenn die Datei selbst das Problem ist:

Authentication refused: bad ownership or modes for file /home/deploy/.ssh/authorized_keys

Was sshd akzeptiert:

• Das Home-Verzeichnis: nicht für die Gruppe und nicht für alle anderen Benutzer beschreibbar. 755, 750 und 700 sind zulässig. 775 und 777 sind nicht zulässig.
• ~/.ssh: Modus 700.
• ~/.ssh/authorized_keys: Modus 600.
• Eigentümer: Alle drei müssen dem Konto gehören, mit dem Sie sich anmelden, nicht root.

Der Eigentümer ist ebenso wichtig wie der Modus. Eine Datei in /home/deploy/.ssh, die root gehört, fällt bei derselben Prüfung durch. Das passiert, wenn Sie sie mit sudo nano erstellen und anschließend vergessen, den Eigentümer zurückzusetzen. Beides lässt sich gleichzeitig korrigieren:

sudo chown -R deploy:deploy /home/deploy/.ssh
sudo chmod 700 /home/deploy/.ssh
sudo chmod 600 /home/deploy/.ssh/authorized_keys
sudo chmod go-w /home/deploy
ls -ld /home/deploy /home/deploy/.ssh

Der letzte Befehl zeigt das Ergebnis. Für das Home-Verzeichnis benötigen Sie drwxr-xr-x oder restriktivere Berechtigungen und für .ssh drwx------. Wenn diese Zeichenfolgen noch nicht eindeutig sind, lesen Sie wie Sie eine Berechtigungszeichenfolge wie drwxr-xr-x lesen, bevor Sie die Modi auf einem aktiven Server ändern.

Auf Rocky Linux und AlmaLinux gehört SELinux (Security-Enhanced Linux) ebenfalls zu den möglichen Ursachen. Ein über einen ungewöhnlichen Weg erstelltes Verzeichnis .ssh kann das falsche Datei-Label tragen. Dadurch wird sshd der Lesezugriff verweigert, obwohl die Modi korrekt aussehen. sudo restorecon -Rv /home/deploy/.ssh setzt die Labels zurück, und sudo ausearch -m avc -ts recent zeigt, ob SELinux den Zugriff verweigert hat.

Ursache 5: sshd verweigert Ihre Anmeldung

Das Lesen von /etc/ssh/sshd_config reicht auf einem aktuellen Ubuntu- oder Debian-System nicht aus. Die Datei beginnt mit Include /etc/ssh/sshd_config.d/*.conf, und OpenSSH verwendet für jede Einstellung den ersten gefundenen Wert. Eine Drop-in-Datei wie 50-cloud-init.conf wird daher zuerst gelesen und hat Vorrang vor allen Änderungen, die Sie weiter unten in der Hauptdatei vornehmen. Deshalb kann eine Änderung korrekt aussehen und trotzdem keinerlei Wirkung haben.

Rufen Sie die tatsächlich verwendete Konfiguration von sshd ab:

sudo sshd -T | grep -Ei 'pubkeyauth|authorizedkeysfile|permitrootlogin|allowusers|allowgroups|denyusers'

Eine funktionierende Ausgabe sieht so aus:

permitrootlogin prohibit-password
pubkeyauthentication yes
authorizedkeysfile .ssh/authorized_keys .ssh/authorized_keys2

Achten Sie in Ihrer Ausgabe auf Folgendes:

• pubkeyauthentication no. Kein Schlüssel wird akzeptiert. Dies erscheint auch in ssh -v als erste Authentications that can continue:-Liste ohne publickey.
• authorizedkeysfile verweist auf einen anderen Speicherort, zum Beispiel /etc/ssh/authorized_keys/%u. Ihre Datei im Home-Verzeichnis wird dann vollständig ignoriert. Für den neuen Pfad gelten stattdessen die in Ursache 4 beschriebenen Rechte- und Modusregeln.
• allowusers oder allowgroups ist vorhanden. Konten, die nicht aufgeführt sind, werden mit genau diesem Fehler und ohne weitere Erklärung abgewiesen. denyusers und denygroups bewirken das Gegenteil.
• permitrootlogin no ist gesetzt, während Sie versuchen, sich als root anzumelden. prohibit-password ist die sinnvolle mittlere Einstellung: root darf einen Schlüssel verwenden, aber kein Passwort.

Match-Blöcke erscheinen nicht in einer einfachen sshd -T-Ausgabe, weil ihr Ergebnis davon abhängt, wer die Verbindung herstellt. Fragen Sie eine bestimmte Verbindung ab:

sudo sshd -T -C user=deploy,host=vps.example.com,addr=198.51.100.7

Eine weitere Einstellung betrifft ältere Schlüssel. OpenSSH 8.8 akzeptiert SHA-1-Signaturen (ssh-rsa) standardmäßig nicht mehr. Daher kann ein RSA-Schlüssel, der jahrelang funktioniert hat, direkt nach einem Server-Upgrade nicht mehr funktionieren. Der Client gibt den Grund eindeutig aus:

debug1: send_pubkey_test: no mutual signature algorithm

Die richtige Lösung ist ein neuer Schlüssel: ssh-keygen -t ed25519 -C "deploy@vps-prod". Installieren Sie anschließend die Datei .pub wie oben beschrieben. Wenn Sie PubkeyAcceptedAlgorithms +ssh-rsa auf dem Server setzen, werden die alten Signaturen wieder aktiviert, und Sie erhalten heute wieder Zugriff. Betrachten Sie dies daher als Möglichkeit, den Server zu erreichen, nicht als endgültige Lösung. Die übrigen serverseitigen Einstellungen, die Sie prüfen sollten, sind unter den SSH-Server auf einem VPS härten beschrieben.

So weisen Sie nach, dass ein privater Schlüssel zum installierten öffentlichen Schlüssel gehört

Die meisten Vermutungen bei diesem Fehler entstehen, weil unklar ist, ob zwei Dateien zusammengehören. Ein Befehl schafft Klarheit:

ssh-keygen -y -f ~/.ssh/vps-prod

Damit wird der aus dem privaten Schlüssel abgeleitete öffentliche Schlüssel ausgegeben. Die danebenliegende Datei .pub wird dabei nicht gelesen. Der Befehl zeigt daher, wie der private Schlüssel tatsächlich lautet, und nicht, was eine veraltete Datei .pub behauptet. Wenn der Schlüssel mit einer Passphrase geschützt ist, fordert der Befehl diese an. Damit wird zugleich bestätigt, dass Sie die Passphrase noch kennen.

ssh-keygen -lf ~/.ssh/vps-prod.pub
ssh-add -l

Der erste Befehl gibt den Fingerabdruck einer öffentlichen Schlüsseldatei aus. Der zweite gibt die Fingerabdrücke aus, die Ihr Agent gespeichert hat. Vergleichen Sie nun vier Ansichten derselben Zeichenfolge: den Fingerabdruck in der Zeile Offering public key aus ssh -v, den Fingerabdruck Ihrer Datei .pub, die Fingerabdrücke in ssh-keygen -lf auf authorized_keys des Servers und den Fingerabdruck im Server-Log. An der Stelle, an der die Werte nicht mehr übereinstimmen, liegt die Ursache bei Ihnen.

Protokoll des Servers während des fehlgeschlagenen Logins mitlesen

Der Client erhält absichtlich keine verwertbare Information. Der Server protokolliert den tatsächlichen Grund. Starten Sie in der Konsolensitzung einen Log-Follower. Führen Sie anschließend auf Ihrem Laptop den fehlschlagenden Befehl ssh aus.

sudo journalctl -u ssh -f

Ubuntu 24.04 installiert rsyslog standardmäßig nicht. Daher ist /var/log/auth.log dort möglicherweise nicht vorhanden. Unter Rocky Linux und AlmaLinux heißt die Unit sshd. Dieselben Einträge werden dort außerdem in /var/log/secure geschrieben.

Setzen Sie LogLevel VERBOSE in der sshd-Konfiguration. Laden Sie anschließend den Dienst neu. Jeder Versuch protokolliert dann den Fingerabdruck, den der Server tatsächlich empfangen hat:

Failed publickey for deploy from 198.51.100.7 port 49812 ssh2: ED25519 SHA256:0eL/8sBw...

Anhand dieser Zeile erkennen Sie, auf welcher Seite der Fehler liegt. Ein Ihnen bekannter Fingerabdruck bedeutet, dass Ihr Schlüssel den Server erreicht hat, dort aber abgelehnt wurde. Prüfen Sie daher die Ursachen 3, 4 und 5. Ein Ihnen unbekannter Fingerabdruck bedeutet, dass Ihr Client einen anderen Schlüssel gesendet hat als beabsichtigt. Gehen Sie daher zurück zu Ursache 2.

Wenn das Protokoll weiterhin unklar ist, starten Sie einen zweiten sshd an einem anderen Port im Debug-Modus. Er bleibt im Vordergrund, verarbeitet eine Verbindung, gibt seine Analyse aus und wird anschließend beendet:

sudo /usr/sbin/sshd -ddd -p 2222

Stellen Sie in der Konsolensitzung auf demselben Server über die Loopback-Adresse eine Verbindung her:

ssh -p 2222 -i ~/.ssh/vps-prod -o IdentitiesOnly=yes deploy@127.0.0.1

Die Verbindung über 127.0.0.1 hält die Firewall aus dem Test heraus. Die Debug-Ausgabe nennt die geöffnete Datei, den verglichenen Fingerabdruck und die genaue Ablehnung, einschließlich Zeilen wie Authentication refused: bad ownership or modes for directory /home/deploy. Drücken Sie Ctrl+C, sobald Sie die Ursache gefunden haben. Der produktive sshd an Port 22 bleibt währenddessen unverändert.

So vermeiden Sie, sich selbst auszusperren

Für jeden Schritt, der die Serverkonfiguration ändert, benötigen Sie einen Zugang, der nicht von SSH abhängt. Richten Sie diesen Zugang ein, solange SSH noch funktioniert, nicht erst nach einem Ausfall.

1. Öffnen Sie die Konsole Ihres Providers über eine serielle Verbindung oder VNC (Virtual Network Computing) und prüfen Sie, ob Sie sich dort anmelden können.
2. Stellen Sie sicher, dass Sie ein funktionierendes lokales Passwort für ein Konto mit sudo kennen. Falls nicht, setzen Sie zuerst das root-Passwort über die Provider-Konsole zurück.
3. Lassen Sie Ihre aktuelle SSH-Sitzung geöffnet. Eine geöffnete Sitzung übersteht systemctl restart ssh und bleibt daher ein Rückweg, falls die neue Konfiguration fehlerhaft ist.
4. Prüfen Sie die Syntax, bevor Sie den Dienst neu starten: sudo sshd -t gibt bei einer gültigen Datei nichts aus und bei einem Fehler die Datei sowie die Zeilennummer aus.
5. Öffnen Sie ein zweites Terminal und melden Sie sich dort neu an, bevor Sie das erste Terminal schließen. Eine fehlerhafte Konfiguration verhindert neue Anmeldungen, beendet aber bestehende Sitzungen nicht. Die Sitzung, in der Sie gerade arbeiten, kann daher nicht zeigen, ob die Änderung funktioniert.

Starten Sie den Dienst unter Debian und Ubuntu mit sudo systemctl restart ssh neu, unter Rocky Linux und AlmaLinux mit sudo systemctl restart sshd. Unter Ubuntu 24.04 wird sshd über eine Socket-Unit gestartet. Daher erfordern Änderungen an Port oder ListenAddress zusätzlich sudo systemctl restart ssh.socket, bevor sie wirksam werden.

FAQ

Warum erhalte ich Permission denied (publickey), obwohl derselbe Schlüssel auf einem anderen Server funktioniert?

Der Schlüssel ist in Ordnung. Das Problem liegt an einer anderen Stelle. Führen Sie ssh -v aus und suchen Sie die Zeile Offering public key. Wenn Ihr Schlüssel dort nicht aufgeführt ist, hat ssh ihn nicht gesendet: Die Datei liegt nicht unter ~/.ssh unter einem Standardnamen und ist nicht im Agent geladen. Fügen Sie sie daher mit -i /path/to/key -o IdentitiesOnly=yes hinzu. Wenn der Schlüssel aufgeführt ist und der Server ihn trotzdem ablehnt, fehlt der Schlüssel in authorized_keys des Kontos, der Pfad dorthin ist für die Gruppe beschreibbar oder die sshd-Konfiguration blockiert den Benutzer. Das Server-Log unterscheidet diese Fälle.

Wie sehe ich, welchen Schlüssel SSH tatsächlich sendet?

ssh -v host gibt pro Schlüssel eine Zeile debug1: Offering public key: aus. Jede Zeile nennt die Quelldatei und einen SHA256-Fingerabdruck. ssh-add -l listet die Fingerabdrücke auf, die der Agent enthält. ssh-keygen -lf ~/.ssh/id_ed25519.pub gibt den Fingerabdruck einer einzelnen Schlüsseldatei aus. ssh-keygen -y -f ~/.ssh/id_ed25519 gibt den öffentlichen Schlüssel aus, der tatsächlich aus einem privaten Schlüssel abgeleitet wird. Damit die Anmeldung erfolgreich ist, muss der Fingerabdruck aus der Zeile Offering auch in der Ausgabe von ssh-keygen -lf erscheinen, ausgeführt gegen authorized_keys des Servers.

Warum ignoriert sshd meine authorized_keys-Datei?

Weil StrictModes standardmäßig aktiviert ist und entweder die Datei, das Verzeichnis .ssh oder das Home-Verzeichnis für die Gruppe oder alle anderen Benutzer beschreibbar ist oder dem falschen Konto gehört. sshd vertraut keinem Pfad, den eine andere Person ändern kann. Daher verhält es sich so, als wäre kein Schlüssel vorhanden. Setzen Sie die Rechte des Home-Verzeichnisses auf 755 oder restriktiver, .ssh auf 700 und authorized_keys auf 600. Alle drei Pfade müssen dem Anmeldekonto gehören. Mit LogLevel VERBOSE protokolliert der Server Authentication refused: bad ownership or modes for directory /home/deploy/.ssh.

Mein Schlüssel funktioniert direkt nach einem Server-Upgrade nicht mehr. Was hat sich geändert?

Wenn es sich um einen RSA-Schlüssel handelt, ist dies höchstwahrscheinlich auf die Änderung bei SHA-1 zurückzuführen. OpenSSH 8.8 hat ssh-rsa-SHA-1-Signaturen standardmäßig deaktiviert. Ein Schlüssel, der nur auf diese Weise signieren kann, wird daher jetzt abgelehnt. Die ausführliche Client-Ausgabe zeigt debug1: send_pubkey_test: no mutual signature algorithm. Erzeugen Sie mit ssh-keygen -t ed25519 einen modernen Schlüssel und installieren Sie dessen Datei .pub. Wenn Sie sofort Zugriff benötigen, reaktiviert PubkeyAcceptedAlgorithms +ssh-rsa auf dem Server die alten Signaturen. Entfernen Sie diese Zeile, sobald der neue Schlüssel funktioniert.

Ich habe sshd_config bearbeitet und kann mich jetzt überhaupt nicht mehr anmelden. Wie erhalte ich wieder Zugriff?

Verwenden Sie die Konsole Ihres Providers. Diese Verbindung läuft nicht über SSH. Melden Sie sich dort mit einem lokalen Passwort an. Führen Sie sudo sshd -t aus, um den Syntaxfehler und dessen Zeilennummer anzuzeigen. Machen Sie die Änderung rückgängig und starten Sie den Dienst neu. Prüfen Sie anschließend sudo sshd -T, um die aktiven Werte zu bestätigen, da eine Datei in /etc/ssh/sshd_config.d/ die Hauptkonfiguration überschreiben kann. Wenn Sie kein lokales Passwort haben, setzen Sie das root-Passwort zuerst über die Konsole zurück und reparieren Sie anschließend die Datei.