"Permission denied (publickey)" bei SSH beheben

Sehen, was Ihr Client anbietet

ssh -v user@server

Achten Sie gegen Ende der Ausgabe auf diese Zeilen:

Zeile	Was sie bedeutet
`Will attempt key: ...`	Die Schlüssel, die Ihr Client versuchen will. Fehlt Ihrer, kennt der Client ihn nicht.
`Offering public key: ...`	Der Schlüssel wurde an den Server gesendet.
`Server accepts key: ...`	Der Server kennt diesen Schlüssel. Ein Fehler nach dieser Zeile ist ein Problem mit dem privaten Schlüssel auf Ihrer Seite.
`Warning: Identity file ... not accessible`	Der Pfad, den Sie `-i` oder `IdentityFile` gegeben haben, existiert nicht.
`Load key "...": bad permissions`	Die private Schlüsseldatei ist zu offen und wurde ignoriert. Siehe Unprotected private key file.

Das Wort in Klammern im Fehler listet die Anmeldemethoden, die der Server noch erlaubt. Nur (publickey) bedeutet, dass Passwörter ausgeschaltet sind und ein funktionierender Schlüssel der einzige Weg hinein ist.

Kommt der Fehler bei git push oder git pull? Siehe git@github.com: Permission denied (publickey).

Das Log auf dem Server lesen

Dem Client wird nie gesagt, warum ein Schlüssel abgelehnt wurde. Das weiß nur der Server. Haben Sie noch einen Zugang, etwa eine andere Sitzung oder eine Konsole des Anbieters, lesen Sie das Log:

sudo journalctl -u ssh -n 50     # Debian, Ubuntu
sudo journalctl -u sshd -n 50    # RHEL, Fedora, Arch
sudo tail -n 50 /var/log/auth.log   # older Debian and Ubuntu
sudo tail -n 50 /var/log/secure     # older RHEL

Logzeile	Ursache
`Invalid user alice from ...`	Dieses Konto existiert auf dem Server nicht.
`Authentication refused: bad ownership or modes for directory ...`	Berechtigungen für das Home-Verzeichnis oder `.ssh`.
`Authentication refused: bad ownership or modes for file ...`	Berechtigungen für `authorized_keys`.
`Could not open user 'user' authorized keys ...: Permission denied`	Die Datei gehört jemand anderem, oft root, nachdem sie mit `sudo` angelegt wurde.
`User user from ... not allowed because not listed in AllowUsers`	Das Konto wird durch `AllowUsers` blockiert. `DenyUsers`, `AllowGroups` und `DenyGroups` funktionieren ähnlich.
`Connection closed by authenticating user user ... [preauth]`	Wurde sonst nichts geloggt, steht der Schlüssel meist einfach nicht in `authorized_keys`.

Gibt das Log keinen Grund, starten Sie einen zweiten sshd im Debug-Modus auf einem freien Port. Er bearbeitet eine Verbindung, gibt jeden Schritt aus und beendet sich. Der Port muss in Ihrer Firewall offen sein.

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

ssh -v -p 2222 user@server

Falscher Benutzer

Prüfen Sie, als wer Sie sich wirklich anmelden, denn eine User-Zeile in Ihrer Konfiguration kann das festlegen:

ssh -G server | grep '^user '

Cloud-Images nutzen oft ein festes Konto wie ubuntu, debian oder ec2-user und lehnen root ab. Ein Schlüssel, der für ein Konto installiert ist, funktioniert für ein anderes nicht, denn jedes Konto hat seine eigene authorized_keys.

Um Benutzer und Schlüssel für einen Host einmal festzulegen, setzen Sie User und IdentityFile in seinen Block der SSH-Konfigurationsdatei.

Falscher Schlüssel oder kein Schlüssel auf dem Server

Vergleichen Sie die Fingerprints. Auf Ihrem Rechner:

ssh-keygen -lf ~/.ssh/id_ed25519.pub

Auf dem Server listet dies jeden Schlüssel in der Datei auf:

ssh-keygen -lf ~/.ssh/authorized_keys

Fehlt der Fingerprint, installieren Sie den Schlüssel. Solange die Anmeldung mit Passwort funktioniert, reicht ein Befehl, der auch die richtigen Rechte setzt:

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server

Akzeptiert der Server nur Schlüssel, fügen Sie ihn über die Konsole des Anbieters oder eine andere Sitzung hinzu, als dieser Benutzer. Setzen Sie Ihre ganze .pub-Zeile anstelle des Beispiels ein:

mkdir -p ~/.ssh && chmod 700 ~/.ssh
echo 'ssh-ed25519 AAAA... you@laptop' >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Ist der Schlüssel da, Ihr Client bietet aber zuerst andere an, nennen Sie ihn und ignorieren Sie den Rest:

ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 user@server

Ein häufiger Fehler bei der manuellen Installation ist ein Schlüssel, der über zwei Zeilen verteilt ist. Jeder Schlüssel muss in einer Zeile stehen: siehe die Datei authorized_keys erklärt.

Berechtigungen und Besitzer

Mit dem Standard StrictModes yes ignoriert sshd authorized_keys, wenn andere Benutzer in die Datei oder in die darüberliegenden Verzeichnisse schreiben könnten. Schreibrecht der Gruppe auf das Home-Verzeichnis genügt, um das auszulösen. Auf dem Server, als dieser Benutzer:

chmod go-w ~
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Haben Sie die Dateien mit sudo angelegt, korrigieren Sie auch den Besitzer:

sudo chown -R user:user /home/user/.ssh

Um jede Ebene des Pfads auf einmal zu sehen:

namei -l /home/user/.ssh/authorized_keys

Auf Systemen mit aktivem SELinux, etwa RHEL und Fedora, können verschobene Dateien außerdem das falsche Label tragen. Setzen Sie es mit restorecon -Rv ~/.ssh zurück.

AuthorizedKeysFile zeigt woandershin

Ihr Schlüssel steht vielleicht in der richtigen Datei für das Standard-Setup, aber nicht für diesen Server. Fragen Sie sshd, was für diesen Benutzer gilt. -C wertet auch alle Match-Blöcke aus:

sudo sshd -T -C user=user,host=example.com,addr=203.0.113.10 | grep -iE '^(authorizedkeysfile|pubkeyauthentication) '

Der Standard ist .ssh/authorized_keys .ssh/authorized_keys2, relativ zum Home-Verzeichnis. Ein Wert wie /etc/ssh/authorized_keys/%u bedeutet, dass der Schlüssel stattdessen dorthin gehört. Prüfen Sie auch, dass pubkeyauthentication yes sagt.

Altes RSA und PubkeyAcceptedAlgorithms

OpenSSH 8.8 hat die Signatur ssh-rsa, die SHA-1 nutzt, standardmäßig abgeschaltet. Das betraf die alte Signatur, nicht RSA-Schlüssel. Ein RSA-Schlüssel funktioniert weiterhin, wenn beide Seiten rsa-sha2-256 oder rsa-sha2-512 unterstützen, was OpenSSH seit Version 7.2 tut.

Trifft ein neuer Client auf einen Server, der dafür zu alt ist, zeigt ssh -v eine Zeile wie no mutual signature algorithm, und der Schlüssel wird nie angeboten. Die eigentliche Lösung ist, den Server zu aktualisieren. Bis dahin erlauben Sie die alte Signatur für genau diesen Host in ~/.ssh/config:

Host oldbox
  PubkeyAcceptedAlgorithms +ssh-rsa
  HostKeyAlgorithms +ssh-rsa

Verbindet sich ein alter Client mit einem neuen Server, gehört dieselbe Zeile in die sshd-Konfiguration und wirkt für jeden Benutzer dieses Servers:

PubkeyAcceptedAlgorithms +ssh-rsa

Vor OpenSSH 8.5 hieß die Option PubkeyAcceptedKeyTypes. Wenn möglich, wechseln Sie zu einem ed25519-Schlüssel und entfernen Sie diese Zeilen.

Fragen

Wie füge ich meinen SSH-Schlüssel zum Server hinzu?

Führen Sie ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server aus, solange die Anmeldung mit Passwort noch funktioniert. Akzeptiert der Server nur Schlüssel, hängen Sie Ihre .pub-Zeile über die Konsole des Anbieters an ~/.ssh/authorized_keys an und führen Sie dann chmod 600 für die Datei aus.

Warum meldet SSH Permission denied (publickey), obwohl der Schlüssel auf dem Server liegt?

Meist wegen der Rechte: sshd ignoriert authorized_keys, wenn andere in das Home-Verzeichnis, in .ssh oder in die Datei schreiben können. Prüfen Sie auch, ob der Schlüssel in der Datei des Kontos steht, mit dem Sie sich anmelden.

Wie sehe ich, welchen Schlüssel SSH anbietet?

Führen Sie ssh -v user@server aus und suchen Sie die Zeilen Offering public key. Um nur einen Schlüssel zu verwenden, ergänzen Sie -o IdentitiesOnly=yes und -i mit seinem Pfad.

Funktionieren RSA-Schlüssel mit aktuellem OpenSSH noch?

Ja. OpenSSH 8.8 hat die alte Signatur ssh-rsa mit SHA-1 abgeschaltet, nicht RSA-Schlüssel. Diese funktionieren mit rsa-sha2-256 oder rsa-sha2-512.

Quellen

Mehr zu Schlüssel und Anmeldung

Alle Anleitungen