SSH-Meldung „Permission denied (publickey)“ mit ssh -v richtig lesen

Worum es geht

Der OpenSSH-Client gibt user@host: Permission denied (publickey). aus, sobald jede Authentifizierungsmethode, die der Server zu versuchen bereit war, mit einer Ablehnung geendet hat. Die Methodennamen in Klammern sind lediglich das, was der Server zum Versuch angeboten hat, und nicht der Grund, aus dem etwas konkret fehlgeschlagen ist. Die Meldung selbst enthält keine Angaben dazu, welcher Schlüssel probiert wurde oder warum er nicht funktioniert hat.

Warum es wichtig ist

Die Meldung ist absichtlich allgemein gehalten (mehr Details würden einem Angreifer helfen, gültige Benutzernamen oder Schlüssel auszuspähen). Die Ursache durch Raten zu beheben kostet deshalb nur Zeit. Tatsächlich kommt nur eine kleine Zahl von Ursachen infrage, und ssh -v benennt sie direkt, sodass kein Ausprobieren nötig ist.

So wird es angewendet

• Zuerst mit erhöhter Ausführlichkeit diagnostizieren: ssh -v (oder -vvv für mehr Details) zeigt genau, welche Schlüssel der Client in welcher Reihenfolge angeboten hat und wie der Server auf jeden reagiert hat ("Offering public key", "Server accepts key", "Authentications that can continue"). Dieses Protokoll lesen, bevor irgendeine Konfiguration geändert wird.
• Häufige Ursachen, geordnet vom am wenigsten bis zum am stärksten eingreifenden Fix:
  1. Falscher Benutzername auf dem Server: Die Verbindung läuft unter dem lokalen Kontonamen, der Server erwartet aber einen anderen (z. B. ec2-user, git). Dann -l user übergeben oder den Eintrag User im passenden Host-Block korrigieren.
  2. Der richtige Schlüssel liegt zwar auf der Platte, wurde aber nicht angeboten. Standardmässig probiert ssh Schlüssel aus einem Agent und aus den Standarddateinamen. Den richtigen Schlüssel deshalb explizit mit -i path/to/key zusammen mit IdentitiesOnly yes angeben (dokumentiert in ssh_config(5)). So schickt ssh nicht zusätzlich unpassende Schlüssel an den Server und läuft nicht Gefahr, das serverseitige Limit für Versuche zu erreichen, bevor der richtige an der Reihe ist.
  3. Rechte auf dem Server: sshd_config(5) dokumentiert StrictModes. Damit lehnt sshd die Authentifizierung ab, wenn das Home-Verzeichnis, ~/.ssh oder authorized_keys für andere als den Eigentümer beschreibbar sind. Eigentümer und Zugriffsrechte (üblicherweise 700 für ~/.ssh, 600 für authorized_keys) auf dem Server prüfen und korrigieren; anhand des serverseitigen Auth-Logs bestätigen, dass dies die Ursache ist.
  4. Seit OpenSSH 8.8 verwenden Client und Server standardmässig keine RSA-Signaturen mit SHA-1 (den Algorithmus ssh-rsa) mehr, so die Release Notes von OpenSSH 8.8. RSA-Schlüssel selbst funktionieren weiter über rsa-sha2-256/512, das seit OpenSSH 7.2 unterstützt wird. Fehler treten auf, wenn eine Seite 8.8 oder neuer ist und die andere nur ssh-rsa spricht (sehr alte Server, Appliances, alte SSH-Bibliotheken). Vorzuziehen ist, diese Seite zu aktualisieren oder auf einen ed25519-Schlüssel zu wechseln. Nur als vorübergehende, die Sicherheit schwächende Notlösung lässt sich der Algorithmus mit PubkeyAcceptedAlgorithms +ssh-rsa (Name ab OpenSSH 8.5) in einem Host-Block für genau diesen einen Host wieder aktivieren, nicht global.
• Keine Lösung: wiederholtes Neuversuchen oder das unsichere Kopieren eines privaten Schlüssels zwischen Rechnern, statt einen passenden Schlüssel bereitzustellen oder Agent Forwarding zu nutzen.

Stolpersteine

• Eine Lösung auf der Client-Seite zu suchen, obwohl die eigentliche Ursache in den Rechten von authorized_keys auf dem Server liegt, was nur die Logs des Servers zeigen.
• Anzunehmen, ein Schlüssel „funktioniere noch“, weil er gestern funktioniert hat, obwohl ein OpenSSH-Upgrade auf einer der beiden Seiten die akzeptierten Algorithmen über Nacht geändert hat.