Permission denied (publickey).

Mit vorangestelltem `user@host:`. Die Liste in Klammern zeigt die Methoden, die der Server noch zulässt, zum Beispiel `(publickey,password)` oder `(publickey,gssapi-keyex,gssapi-with-mic)`.

Was der Fehler bedeutet

Die SSH-Verbindung und die Prüfung des Hosts waren erfolgreich, aber der Server hat keinen der öffentlichen Schlüssel akzeptiert, die der Client angeboten hat, und Public-Key-Authentifizierung ist die einzige Methode, die er zulässt (die Liste in Klammern). Der Client erfährt nie, warum ein Schlüssel abgelehnt wurde – der Grund steht nur im Log des Servers. Bei GitHub, GitLab und Bitbucket bedeutet dieselbe Meldung, dass keiner deiner Schlüssel beim Konto (oder als Deploy-Key) für dieses Repository registriert ist.

Warum der Fehler auftritt

• Der richtige Schlüssel wird nicht angeboten

  häufig

  Der Schlüssel ist nicht im Agenten, liegt nicht unter einem Standardpfad (`~/.ssh/id_ed25519`, `id_ecdsa`, `id_rsa`) und ist nicht mit `-i` oder `IdentityFile` angegeben. Bei vielen Schlüsseln im Agenten kann der Server die Verbindung trennen (MaxAuthTries), bevor der richtige versucht wurde.

• Der Schlüssel steht nicht in authorized_keys dieses Benutzers

  häufig

  Für einen anderen Benutzer oder Host installiert, bei einer Neuinstallation entfernt oder (bei Git-Hostern) einem anderen Konto hinzugefügt als dem, das den Zugriff auf das Repository hat.

• sshd ignoriert authorized_keys wegen der Berechtigungen

  gelegentlich

  Mit `StrictModes yes` (Standard) lehnt sshd die Datei ab, wenn das Home-Verzeichnis, `~/.ssh` oder `authorized_keys` für die Gruppe oder für alle beschreibbar ist. Im Server-Log steht „Authentication refused: bad ownership or modes“.

• Der Signaturalgorithmus des Schlüssels wird nicht akzeptiert

  gelegentlich

  RSA-Schlüssel, die alte Clients und Bibliotheken mit dem SHA-1-Algorithmus `ssh-rsa` verwenden, werden von Servern ab OpenSSH 8.8 abgelehnt; DSA-Schlüssel sind in OpenSSH 10 vollständig entfernt. Der Server protokolliert „not in PubkeyAcceptedAlgorithms“.

• Falscher Remote-Benutzername

  gelegentlich

  `ssh server` meldet sich mit deinem lokalen Benutzernamen an. Cloud-Images erwarten `ubuntu`, `ec2-user`, `admin`; Git-Hoster erwarten immer `git@`.

So behebst du den Fehler

1. 1.

   Angebotene Schlüssel anzeigen

   `ssh -v` listet jeden Schlüssel auf, den der Client anbietet, und ob der Server ihn akzeptiert hat; `ssh -G` zeigt den effektiven Benutzer und die Identitätsdateien, nachdem die gesamte Konfiguration angewendet wurde.

   ssh -v deploy@server.example.com 2>&1 | grep -E "Offering|Server accepts|Authentications that can continue|send_pubkey_test"
   ssh-add -l                                  # keys the agent offers
   ssh -G deploy@server.example.com | grep -E "^(user|identityfile|identitiesonly) "

2. 2.

   Identität pro Host festlegen

   `IdentityFile` zusammen mit `IdentitiesOnly yes` bietet genau einen Schlüssel an und vermeidet „Too many authentication failures“ bei Agenten mit vielen Schlüsseln.

   # ~/.ssh/config
   Host server.example.com
     User deploy
     IdentityFile ~/.ssh/deploy_ed25519
     IdentitiesOnly yes

3. 3.

   Serverseite korrigieren und ihr Log lesen

   Installiere den öffentlichen Schlüssel für den richtigen Benutzer mit strikten Berechtigungen und suche im Log von sshd nach dem konkreten Grund der Ablehnung.

   # On the server: install the key and fix modes (sshd ignores keys in group/world-writable paths)
   install -d -m 700 ~/.ssh && cat deploy_ed25519.pub >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys
   sudo journalctl -u ssh --since "10 min ago" | grep -E "Authentication refused|not in PubkeyAccepted|Failed publickey"

← Gesamte Signaturfehler-Datenbank durchsuchen