Wie behebe ich SSH permission denied (publickey) auf Ubuntu?

Prüfe die Serverseite mit journalctl -u ssh -n 50, bestätige, dass dein öffentlicher Schlüssel in ~/.ssh/authorized_keys des Zielusers liegt, und stelle sicher, dass die Rechte 700 auf ~/.ssh und 600 auf authorized_keys und dem privaten Schlüssel sind.

Warum scheitert ssh -i meinkey trotzdem?

Drei übliche Gründe: Die Rechte des privaten Schlüssels sind zu offen, OpenSSH lädt ihn gar nicht erst; der Server läuft mit OpenSSH 8.8+, das ssh-rsa (SHA-1-Signaturen) deaktiviert hat; oder der Schlüssel liegt nicht in den authorized_keys des richtigen Users.

Wie füge ich meinen öffentlichen Schlüssel einem Server hinzu?

Führe ssh-copy-id user@host aus — hängt deinen öffentlichen Schlüssel mit korrekten Rechten an ~/.ssh/authorized_keys an. Ist Passwort-Login bereits deaktiviert, mach es über eine Konsole, auf die du noch Zugriff hast.

SSH Permission denied (publickey): der echte Fix // mrsaynothing

Q: Warum zeigt SSH Permission denied (publickey)?

Das heißt, jeder vom Client angebotene Schlüssel wurde vom Server abgelehnt, und Passwort- oder Keyboard-interactive-Auth wurde nicht versucht oder ist nicht erlaubt. Es ist ein Verhandlungsurteil über deine angebotenen Schlüssel — kein Tippfehler im Passwort.

Um 02:10 starb ein Deploy an einer Zeile, die ich tausendmal getippt habe: ssh deploy@staging → Permission denied (publickey). Der Schlüssel war in Ordnung. Das Angebot war es nicht.

TL;DR: Permission denied (publickey) heißt, jeder vom Client angebotene Schlüssel wurde vom Server abgelehnt — ein Verhandlungsurteil, kein Passwort-Tippfehler. Diagnostiziere mit ssh -vvv (welche Schlüssel angeboten wurden) und dem Serverlog journalctl -u ssh (welche abgelehnt wurden, und warum). Dann behebe eine der vier Ursachen: falscher User, Schlüssel fehlt in authorized_keys, zu offene Rechte, oder ein ssh-rsa-Schlüssel, den OpenSSH 8.8+ ablehnt. ssh-copy-id verhindert die meisten Wiederholungen.

$ ssh -T [email protected]
[email protected]: Permission denied (publickey).

Der Fehler ist ein Urteil, kein Hinweis: Alles im Angebot wurde abgelehnt.

Warum zeigt SSH „Permission denied (publickey)“?

Public-Key-Auth ist eine Angebot-und-Ablehnung-Verhandlung. Der Client bietet jeden Schlüssel an, den er finden kann — Identitäten vom Agenten, aus deiner ~/.ssh/config, Standard-Dateinamen (id_ed25519, id_rsa) und alles, was per -i übergeben wird. Der Server gleicht jedes Angebot mit den ~/.ssh/authorized_keys des Zielaccounts ab. Passt nichts, und Passwort-Auth ist deaktiviert oder aufgebraucht, druckt der Client die eine Zeile, die jeder Devops-Ingenieur auswendig kennt.

Zwei Fakten zählen beim Debuggen. Erstens: Die Meldung sagt nicht, welchen User du getroffen hast — in der Hälfte der Fälle liegt ein tadellos guter Schlüssel in den authorized_keys des falschen Accounts. Zweitens hat der Server den Grund längst gesagt: sshd loggt jede abgelehnte Offerierung. Der Stacktrace, den niemand bestellt und jeder braucht, ist -vvv.

Wie sehe ich, welchen Schlüssel SSH wirklich anbietet?

ssh -vvv deploy@staging 2>&1 | grep -iE "offering|identity|denied|authentications"
# debug1: Offering public key: /home/you/.ssh/id_ed25519 RSA-SHA256 (explicit)
# debug1: Authentications that can continue: publickey
# deploy@staging: Permission denied (publickey).

Drei Zeilen lesen: Offering public key (was der Client vorgeschlagen hat), Authentications that can continue (was der Server noch akzeptiert — fehlt password, kommt nie eine Passwortabfrage) und das Schlussurteil. Taucht dein Schlüssel nie in der Angebotsliste auf, liegt das Problem beim Client: falscher -i-Pfad, ein vergessener IdentityFile in ~/.ssh/config, oder ein Agent (ssh-add -l), der mit einer veralteten Identität zuerst antwortet.

Was sind die vier echten Ursachen?

Ursache	Indiz	Fix
Falscher User	Schlüssel klappt für `root@host`, scheitert für `deploy@host`	Schlüssel muss in die `~/.ssh/authorized_keys` dieses Users
Schlüssel nicht installiert	Serverlog zeigt `Failed publickey` für jedes Angebot	`ssh-copy-id user@host`
Rechte zu offen	Client: `WARNING: UNPROTECTED PRIVATE KEY FILE` — Schlüssel wird übersprungen, nie angeboten	`chmod 700 ~/.ssh; chmod 600 ~/.ssh/*`
Altes `ssh-rsa`	Server mit OpenSSH 8.8+; alter RSA-Schlüssel wird nie akzeptiert	Als ed25519 neu erzeugen, oder Schlüssel modernisieren

Die Rechte-Ursache verdient eine eigene Notiz, denn OpenSSH erzwingt das hart: Ein privater Schlüssel, den Gruppe oder Andere lesen können, wird vom Client selbst abgelehnt und fällt still aus dem Angebot. Der Fix sind zwei Befehle:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519 ~/.ssh/authorized_keys

Die ssh-rsa-Ursache erwischt alte CI-Images und Raspberry Pis: OpenSSH 8.8 (veröffentlicht 2021-10-01, openssh.com/txt/release-8.8) hat ssh-rsa-Signaturen — die SHA-1-Variante — standardmäßig deaktiviert. Wortlaut der Release Notes: “the ssh-rsa signature scheme is … disabled by default”. Ein RSA-Schlüssel von 2018 ist nicht kaputt; sein Signaturformat wird schlicht nicht mehr gesprochen. Ein ed25519-Schlüssel (ssh-keygen -t ed25519) ist die dauerhafte Antwort, und Cloud-Konsolen geben dir eine Serielle Konsole, wenn du dich mitten im Fix aussperrst.

Startet sshd selbst nicht, während du an der Config editierst, ist das eine andere Jagd — siehe systemd service not starting.

Wie sehe ich, warum der Server den Schlüssel abgelehnt hat?

Das Serverlog ist der ehrliche Zeuge. Unter Ubuntu (systemd) protokolliert sshd das Urteil jedes Angebots:

journalctl -u ssh -n 50 --no-pager | grep -iE "publickey|denied|accepted"
# sshd[4421]: Failed publickey for deploy from 203.0.113.7 port 51422 ssh2: RSA SHA256:...
# sshd[4421]: Accepted publickey for deploy from 203.0.113.7 port 51422 ssh2: ED25519 SHA256:...

Failed publickey mit einem unerwarteten Fingerprint heißt: Der Client hat einen anderen Schlüssel angeboten als gedacht — zurück zu -vvv. Failed publickey mit deinem Fingerprint heißt: Der Schlüssel stimmt, ist aber für diesen Account nicht installiert, oder die Home-Rechte auf der Serverseite stimmen nicht (dieselbe 700/600-Regel gilt für ~/.ssh und ~/.ssh/authorized_keys des Servers).

Wie installiere ich meinen Schlüssel richtig?

ssh-copy-id deploy@staging
# Number of key(s) added: 1
ssh -o BatchMode=yes deploy@staging 'echo ok'   # nicht-interaktiver Beweis

ssh-copy-id hängt deinen öffentlichen Schlüssel mit vernünftigen Rechten an die authorized_keys des Zielaccounts an — die Option existiert, weil Hand-Pasting in authorized_keys genau oft genug an einem Zeilenumbruch oder fehlenden Verzeichnis scheitert. Der BatchMode-Check ist der wahre Test: Er deaktiviert alle Nachfragen, also bedeutet Erfolg, dass der Schlüssel allein den Login getragen hat. Läuft der Schlüssel, erben scp und rsync dieselbe Authentifizierung gratis — die Wahl zwischen beiden ist Bandbreite, nicht Berechtigung (rsync vs scp).

Die 30-Sekunden-Triage

ssh -vvv user@host 2>&1 | grep -i offering      # 1. Welche Schlüssel wurden angeboten?
journalctl -u ssh -n 50 | grep -i publickey     # 2. Warum wurden sie abgelehnt?
ls -ld ~/.ssh ~/.ssh/authorized_keys            # 3. 700 / 600?
ssh-copy-id user@host                           # 4. Installieren, dann per BatchMode prüfen

Permission denied (publickey) ist ein Verhandlungsergebnis, keine Passwortabfrage — der Server hat jeden Schlüssel im Angebot abgelehnt, und sein Log weiß längst, warum.

Vier Befehle in dieser Reihenfolge, und die Störung ist kein Mysterium mehr: Einer benennt jedes Mal den Täter. Bei mir war es eine veraltete Agent-Identität, die vor dem richtigen Schlüssel antwortete — ssh-add -d, und der Deploy wurde um 02:31 wieder grün.

SSH Permission denied (publickey): der echte Fix