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. Wenn Ihre Sitzung vorher beendet wird, handelt es sich stattdessen um „connection refused“ oder „connection timed out“. Das ist eine andere Diagnose mit anderen Prüfungen. Die Behebung erfolgt nicht durch Raten, weil ssh -v angibt, welche von fünf Ursachen vorliegt.

Die Wörter in den Klammern bezeichnen die Methoden, die der Server akzeptieren wollte. Permission denied (publickey) allein bedeutet, dass die Anmeldung per Passwort auf diesem Server deaktiviert ist. Es gibt daher kein Passwort als Ausweichmöglichkeit. Permission denied (publickey,password) bedeutet, dass Passwörter angeboten wurden und auch diese Anmeldung fehlgeschlagen ist.

Eine Meldung deckt fünf voneinander getrennte Fehler ab und bleibt absichtlich ungenau. Ein Server, der mit „Benutzer nicht vorhanden“ oder „dieser Schlüssel ist nicht installiert“ antworten würde, würde jedem helfen, nach gültigen Konten zu suchen. Beginnen Sie daher nicht damit, Schlüssel auszutauschen und Konfigurationsdateien zu bearbeiten. Führen Sie einen Befehl aus, lesen Sie drei Ausgabezeilen, und aus fünf möglichen Ursachen wird eine.

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 erforderlichen 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 Benutzername, 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, die gesendet wird, 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: ... enthält eine Zeile für jeden Schlüssel, den Ihr Client tatsächlich gesendet hat. Die Zeile nennt die Quelldatei und den SHA256-Fingerprint. Ein Schlüssel ohne Offering-Zeile wurde nie an den Server gesendet.

Teilen Sie das Problem nun in zwei Bereiche auf:

• Für den erwarteten Schlüssel gibt es keine Offering public key-Zeile. 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 zutreffend erweisen.

Ursache 1: Sie stellen die Verbindung mit dem falschen Benutzernamen her

Die häufigste Ursache ist zugleich die unspektakulärste. sshd, der SSH-Server-Daemon (Secure Shell), teilt Ihnen nie mit, dass ein Konto nicht existiert. Er führt den gesamten Austausch für einen erfundenen Benutzernamen durch und verweigert die Anmeldung erst am Ende mit derselben Meldung, weil gültige Kontonamen einem Angreifer helfen. Ein Tippfehler im Benutzernamen sieht daher genauso aus wie ein fehlerhafter Schlüssel.

Prüfen Sie zuerst die Zeile Authenticating to ... as. Wenn dort der Login-Name Ihres Laptops statt des Kontos auf dem Server steht, haben Sie den Benutzernamen im Befehl weggelassen.

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

Das Standardkonto hängt vom Image ab, das Ihr Anbieter erstellt. Im August 2026 enthalten Ubuntu-Cloud-Images normalerweise ein Konto namens ubuntu, Debian-Images enthalten debian oder admin, Rocky Linux und AlmaLinux verwenden rocky und almalinux, und viele VPS-Anbieter installieren Ihren Schlüssel stattdessen direkt für root. Im Control Panel Ihres Anbieters ist vermerkt, welches Konto er erstellt hat. Kein Befehl, den Sie außerhalb des Servers ausführen, kann diese Information abfragen.

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

Host vps-prod
  HostName 203.0.113.10
  User deploy

Wenn Sie das Konto selbst erstellt haben und sich anschließend nicht damit anmelden konnten, wurde der Schlüssel wahrscheinlich für den Standardbenutzer des Images installiert und nicht auf das neue Konto 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 in ~/.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 zeigt die ausführliche Ausgabe dafür keine Offering public key-Zeile.

Geben Sie die Datei an und verhindern Sie, dass Agent-Schlüssel 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 Agent-Schlüssel 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 der richtige Schlüssel erreicht wird. Die Meldung lautet dann:

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

Wenn Sie stattdessen diese Meldung sehen, hat der Server die Sitzung beendet, bevor Ihr korrekter Schlüssel überhaupt verwendet wurde. Dieses Thema wird unter zu viele Authentifizierungsfehler behandelt. IdentitiesOnly=yes beschränkt den Versuch auf die angegebene Datei. Mit ssh-add -l können Sie die Schlüssel auflisten, die der Agent aktuell hält. Mit ssh-add -D leeren Sie den Agenten, wenn sich darin mehrere Jahre alte Schlüssel angesammelt haben. Tragen Sie die Einstellungen anschließend fest 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 Clientseite. ssh verweigert die Verwendung eines privaten Schlüssels, 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 dann nie angeboten, und der Server sieht ihn nicht:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         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. Informationen zum Speicherort und zur Benennung von Schlüsseln finden Sie unter Grundlagen der SSH-Schlüsselverwaltung.

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

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

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

ssh-keygen -lf auf einer 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. Wenn er nicht in der Liste enthalten ist, wurde der Schlüssel nicht für dieses Konto installiert, unabhängig davon, woran Sie sich bei Ihren bisherigen Schritten erinnern.

Es gibt vier häufige Fehlerquellen:

• Sie haben den privaten Schlüssel statt der .pub-Datei 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 Inhalt wurde auf mehrere Zeilen umgebrochen. Jeder Eintrag muss vollständig in genau einer Zeile stehen. Ein umgebrochener Schlüssel wird daher als mehrere beschädigte Einträge gelesen und passt zu keinem Schlüssel.
• Der Schlüssel wurde in /root/.ssh/authorized_keys gespeichert, 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 gespeichert. Das später erstellte Konto hat deshalb ein leeres Verzeichnis .ssh.

Fügen Sie den 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 nun in der Liste erscheinen. Von einem Rechner, der sich weiterhin per Passwort anmelden kann, erledigt ssh-copy-id -i ~/.ssh/vps-prod.pub deploy@203.0.113.10 dieselbe Aufgabe und setzt die Berechtigungen korrekt.

Ursache 4: Warum sshd authorized_keys ignoriert, wenn die Berechtigungen zu weit gefasst sind

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 beschreibbar ist. 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 lediglich die 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 verursacht:

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 werden abgelehnt.
• ~/.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 durch dieselbe Prüfung. 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 an. Für das Home-Verzeichnis benötigen Sie drwxr-xr-x oder restriktivere Berechtigungen und drwx------ auf .ssh. Wenn diese Zeichenfolgen noch nicht eindeutig sind, lesen Sie wie eine Berechtigungszeichenfolge wie drwxr-xr-x gelesen wird, 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 .ssh-Verzeichnis, das auf ungewöhnlichem Weg erstellt wurde, kann das falsche Datei-Label tragen. Dadurch wird sshd der Lesezugriff verweigert, obwohl die Modi korrekt aussehen. sudo restorecon -Rv /home/deploy/.ssh stellt die Labels wieder her. 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 weiter unten in der Hauptdatei stehen. Deshalb kann eine Änderung zwar korrekt aussehen, aber keinerlei Wirkung haben.

Lassen Sie sich von sshd die tatsächlich verwendete Konfiguration anzeigen:

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 eigenen Ausgabe auf Folgendes:

• pubkeyauthentication no. Es wird niemals ein Schlüssel akzeptiert. Dies erscheint auch in ssh -v als erste Authentications that can continue:-Liste ohne publickey.
• authorizedkeysfile, das auf einen anderen Pfad verweist, 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 Berechtigungsregeln aus Ursache 4.
• allowusers oder allowgroups. Konten, die nicht aufgeführt sind, werden genau mit diesem Fehler und ohne weitere Erklärung abgewiesen. denyusers und denygroups verhalten sich umgekehrt genauso.
• permitrootlogin no, wenn 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. Dadurch kann ein RSA-Schlüssel, der jahrelang funktioniert hat, direkt nach einer Serveraktualisierung nicht mehr funktionieren. Der Client zeigt den Grund eindeutig an:

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 gezeigt. Mit PubkeyAcceptedAlgorithms +ssh-rsa auf dem Server aktivieren Sie die alten Signaturen wieder und erhalten noch heute Zugriff auf den Server. Betrachten Sie dies daher als vorübergehende Möglichkeit, den Server zu erreichen, nicht als endgültige Lösung. Die übrigen serverseitigen Einstellungen, die Sie prüfen sollten, finden Sie unter SSH-Server auf einem VPS härten.

So lässt sich nachweisen, dass ein privater Schlüssel zum installierten öffentlichen Schlüssel gehört

Die Ursache für viele Vermutungen bei diesem Fehler ist, dass nicht bekannt ist, ob zwei Dateien zusammengehören. Ein Befehl schafft Klarheit:

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

Der Befehl gibt den aus dem privaten Schlüssel abgeleiteten öffentlichen Schlüssel aus. Die Datei .pub daneben wird nicht gelesen. Daher zeigt die Ausgabe, was der private Schlüssel tatsächlich enthält, und nicht, was eine veraltete Datei .pub behauptet. Wenn der Schlüssel eine Passphrase hat, fordert der Befehl diese an. Damit wird ebenfalls 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 Darstellungen 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 dem Server unter authorized_keys und den Fingerabdruck im Server-Log. Die Stelle, an der die Werte nicht mehr übereinstimmen, zeigt die Fehlerquelle.

Protokollieren Sie den Server-Log, während die Anmeldung fehlschlägt

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

sudo journalctl -u ssh -f

Ubuntu 24.04 installiert rsyslog standardmäßig nicht. /var/log/auth.log ist dort daher 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 und laden Sie den Dienst neu. Jeder Versuch protokolliert anschließend 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...

An diesem Eintrag erkennen Sie, auf welcher Seite der Fehler liegt. Ein Fingerabdruck, den Sie erkennen, bedeutet, dass Ihr Schlüssel den Server erreicht hat und dort abgewiesen wurde. Prüfen Sie daher die Ursachen 3, 4 und 5. Ein Fingerabdruck, den Sie nicht erkennen, 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 im Debug-Modus auf einem anderen Port. Der Prozess bleibt im Vordergrund, akzeptiert eine Verbindung, gibt seine Entscheidungen aus und wird anschließend beendet:

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

Stellen Sie von 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. Dazu gehören auch Zeilen wie Authentication refused: bad ownership or modes for directory /home/deploy. Drücken Sie Ctrl+C, sobald Sie die Ursache gefunden haben. Der eigentliche sshd auf Port 22 bleibt währenddessen unverändert.

So vermeiden Sie, sich selbst auszusperren

Für jeden Schritt, bei dem Sie die Serverkonfiguration ändern, benötigen Sie einen alternativen Zugang, der nicht von SSH abhängt. Richten Sie diesen 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 offene 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. Bei einer ungültigen Datei gibt der Befehl die Datei und 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 bestehende Sitzungen aber nicht. Die Sitzung, in der Sie gerade arbeiten, kann daher nicht bestätigen, ob die Änderung funktioniert.

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

FAQ

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

Der Schlüssel ist in Ordnung, aber eine umgebende Einstellung nicht. 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 nie gesendet: Die Datei liegt nicht unter einem Standardnamen in ~/.ssh 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 dieser Schlüssel in authorized_keys des Kontos, der Pfad dorthin ist für die Gruppe beschreibbar oder die sshd-Konfiguration blockiert den Benutzer. Das Serverprotokoll unterscheidet diese Fälle.

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

ssh -v host gibt für jeden 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 Benutzer beschreibbar ist oder dem falschen Konto gehört. sshd vertraut keinem Pfad, den andere Benutzer ändern können. Daher verhält es sich so, als wäre kein Schlüssel vorhanden. Setzen Sie die Berechtigungen 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 funktionierte direkt nach einem Serverupgrade nicht mehr. Was hat sich geändert?

Wenn es sich um einen RSA-Schlüssel handelt, ist dies wahrscheinlich 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 Clientausgabe zeigt debug1: send_pubkey_test: no mutual signature algorithm. Erzeugen Sie mit ssh-keygen -t ed25519 einen modernen Schlüssel und installieren Sie dessen .pub-Datei. 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 seine 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 zuerst über die Konsole das root-Passwort zurück und korrigieren Sie anschließend die Datei.