SSH Permission Denied (publickey): Fehler beheben

Was bedeutet der Fehler ssh permission denied publickey, und was tun Sie zuerst?

Der Fehler ssh permission denied publickey bedeutet, dass der Server keinen der angebotenen Schlüssel akzeptiert. Führen Sie zuerst ssh -v benutzer@host aus, prüfen Sie, welchen Schlüssel der Client versucht, und kontrollieren Sie, ob der passende Public Key auf dem Server oder in Ihrem GitHub Konto steht.

Bleiben Sie ruhig. Meist steckt hinter dem Fehler kein Serverausfall, sondern eine kleine Abweichung zwischen zwei Dateien. Wir zeigen Ihnen deshalb die Diagnose Reihenfolge aus unserer Praxis, von der wahrscheinlichsten bis zur unwahrscheinlichsten Ursache, denn wahlloses Probieren kostet nur Zeit.

Wie lösen Sie ssh permission denied publickey in den ersten fünf Minuten?

Die folgende Liste deckt die meisten Fälle ab. Testen Sie die Verbindung nach jedem Schritt erneut, und hören Sie auf, sobald sie funktioniert.

1. Zunächst prüfen Sie Benutzername und Host. Bei GitHub lautet der Benutzername immer git.
2. Dann verbinden Sie sich mit ssh -v und prüfen Sie, ob in den Zeilen "Offering public key" der richtige Schlüssel auftaucht.
3. Kontrollieren Sie, ob Ihr Public Key in der Datei authorized_keys des Servers oder in Ihrem GitHub Konto steht.
4. Prüfen Sie mit ssh-add -l, ob der Agent Ihren Schlüssel hält, und laden Sie ihn sonst mit ssh-add.
5. Danach schränken Sie die Rechte des Ordners ~/.ssh und Ihrer Schlüsseldateien ein.
6. Außerdem legen Sie bei mehreren Schlüsseln eine Zeile IdentityFile in ~/.ssh/config fest.
7. Zuletzt testen Sie die GitHub Verbindung mit ssh -T git@github.com.

Jeden Schritt erklären wir unten in einem eigenen Abschnitt. Zunächst klären wir, warum der Fehler überhaupt auftritt.

Warum tritt ssh permission denied publickey auf?

Die Anmeldung mit Public Key nutzt zwei Teile. Den privaten Schlüssel behalten Sie auf Ihrem Rechner, den öffentlichen hinterlegen Sie auf dem Server. Der Server stellt dann eine Aufgabe, die nur der passende private Schlüssel lösen kann.

Der Fehler sagt, dass kein Schlüssel diese Aufgabe bestanden hat. Das heißt, der Server kennt Ihren Schlüssel nicht oder hat ihn nie gesehen. Die Ursache liegt daher an einer von drei Stellen. Entweder bietet der Client den falschen Schlüssel an, der Server findet den richtigen nicht in seinen Einträgen, oder Dateirechte lassen den Server den Eintrag ignorieren.

Außerdem gibt es keinen Ausweg, wenn der Server die Passwort Anmeldung abgeschaltet hat. Deshalb ist das Wort "publickey" in der Klammer wichtig. Es nennt die einzige Methode, die der Server noch akzeptiert.

Stimmen Benutzername und Serveradresse?

Die häufigste Ursache ist die einfachste. Bei vielen Ubuntu Abbildern ist der Standardbenutzer zum Beispiel ubuntu, andere nutzen root oder admin. Verbinden Sie sich mit dem falschen Benutzer, sucht der Server in dessen Einträgen und findet nichts, auch wenn Ihr Schlüssel stimmt.

• Also lesen Sie den Standardbenutzer in Ihrem Hosting oder Cloud Panel ab.
• Schreiben Sie die volle Form benutzer@host, weil der Client sonst Ihren lokalen Benutzernamen sendet.
• Prüfen Sie bei mehreren Servern mit unserem DNS Abfrage Tool, ob der Name auf den richtigen Rechner zeigt.
• Außerdem stellen Sie einen abweichenden Port mit -p ein. Sonst sprechen Sie womöglich mit einem anderen Dienst.

Diese Kontrolle dauert eine Minute. Allerdings ist jeder spätere Schritt vergeblich, wenn Sie sie überspringen.

Wie sehen Sie mit ssh -v, welchen Schlüssel SSH versucht?

Der ausführliche Modus lässt Sie das Raten beenden und die Fakten sehen. Laut OpenSSH Handbuch schaltet -v die Debug Ausgabe ein, und jedes weitere -v erhöht den Detailgrad. Starten Sie die Verbindung dann so, denn so sehen Sie alles:

ssh -v benutzer@example.com

Suchen Sie in der Ausgabe nach diesen Zeilen:

• Offering public key: zeigt, welche Schlüsseldatei der Client anbietet. Fehlt Ihre erwartete Datei, hat der Client den Schlüssel nie gefunden.
• Authentications that can continue: listet die Methoden, die der Server akzeptiert. Sehen Sie nur publickey, ist die Passwort Anmeldung aus.
• No more authentication methods to try: meldet, dass alle Versuche scheiterten.
• Will attempt key: zeigt die Reihenfolge der geladenen Schlüssel, also erkennen Sie hier Agent Probleme.

So trennen Sie Client Probleme schnell von Server Problemen. Bietet der Client keinen Schlüssel an, liegt der Fehler auf Ihrem Rechner. Bietet er den richtigen an und der Server lehnt trotzdem ab, liegt er auf der Serverseite.

Steht Ihr Public Key in der Datei authorized_keys des Servers?

Der Server liest die erlaubten Schlüssel aus ~/.ssh/authorized_keys im Home Verzeichnis des Benutzers. Laut OpenSSH Handbuch enthält jede Zeile dieser Datei einen Public Key. Eine Zeile kann fehlen, nur halb kopiert sein oder in der Datei eines anderen Benutzers stehen.

Geben Sie zur Kontrolle den Public Key auf Ihrem Rechner aus und vergleichen Sie ihn mit der Zeile auf dem Server:

cat ~/.ssh/id_ed25519.pub
cat ~/.ssh/authorized_keys

• Der Schlüssel muss in einer einzigen Zeile stehen. Hat ein Zeilenumbruch ihn beim Kopieren getrennt, ist er ungültig.
• Zudem darf die Datei nur öffentliche Schlüssel mit der Endung .pub enthalten, niemals den privaten.
• Achten Sie darauf, den Schlüssel im Home Verzeichnis des richtigen Benutzers zu hinterlegen. Ein Schlüssel für root hilft nicht, wenn Sie sich als anderer Benutzer anmelden.
• Am sichersten fügen Sie einen Schlüssel mit ssh-copy-id hinzu, solange Sie noch Zugriff haben.

Erreichen Sie den Server gar nicht mehr, helfen die Konsole oder der Rettungsmodus im Panel Ihres Anbieters. Lesen Sie dazu zuerst die offizielle Anleitung des Anbieters.

Warum erscheint ssh permission denied publickey bei GitHub?

Die Meldung ist bei GitHub dieselbe, aber die Ursachen unterscheiden sich etwas. Die GitHub Docs bitten Sie auf der Seite zur Fehlersuche, drei Dinge zu prüfen. Erstens muss die Remote Adresse SSH nutzen. Zweitens muss der Benutzername git lauten. Drittens muss Ihr Public Key im Konto stehen.

1. Die Remote Adresse muss die SSH Form haben. Mit git remote -v sehen Sie sie. Nutzen Sie eine HTTPS Adresse, spielt Ihr SSH Schlüssel überhaupt keine Rolle.
2. Sieht die Adresse wie git@github.com:konto/repo.git aus, stimmt der Benutzername. Tragen Sie hier Ihren eigenen Namen ein, löst genau das den Fehler aus.
3. Dann fügen Sie den Public Key in den SSH Einstellungen Ihres GitHub Kontos hinzu. Menünamen können sich ändern, also folgen Sie dem aktuellen Pfad auf der offiziellen Hilfeseite.
4. Gehört das Repository einer Organisation, prüfen Sie zudem deren SSH Zugriffsregeln.
5. Haben Sie den Schlüssel schon in einem anderen Konto hinterlegt, akzeptiert GitHub ihn nicht in zwei Konten. Erzeugen Sie dann pro Konto einen eigenen Schlüssel.

Möchten Sie die Grundlagen auffrischen, lesen Sie unsere Git und GitHub Anleitung mit den wichtigsten Befehlen.

Warum sieht der SSH Agent Ihren Schlüssel nicht?

Hat Ihr Schlüssel eine Passphrase oder trägt er keinen Standardnamen, findet der Client ihn womöglich nicht selbst. Der SSH Agent ist ein Hilfsprogramm, das entsperrte Schlüssel im Speicher hält. Daher tippen Sie nicht bei jeder Verbindung die Passphrase ein.

Prüfen Sie zunächst, welche Schlüssel der Agent hält:

ssh-add -l
ssh-add ~/.ssh/id_ed25519

• Der erste Befehl listet die Fingerabdrücke der geladenen Schlüssel. Eine Antwort wie "The agent has no identities" heißt, dass der Agent leer ist.
• Dann fügt der zweite Befehl den Schlüssel dem Agenten hinzu. Fragt er nach einer Passphrase, geben Sie die ein, die Sie beim Erzeugen vergeben haben.
• Hält der Agent zu viele Schlüssel, erreicht der Server sein Versuchslimit, bevor Ihr richtiger Schlüssel an der Reihe ist. Dann müssen Sie einen bestimmten Schlüssel erzwingen, was wir im Abschnitt zur Config erklären.
• Leert sich der Agent bei jedem Schließen des Terminals, lesen Sie die Dokumentation Ihres Betriebssystems zur Schlüsselbund Anbindung.

Dieses Problem sehen Sie also oft nach dem Wechsel auf einen neuen Rechner. Die Schlüsseldatei ist umgezogen, aber der Agent hat noch den leeren Zustand der alten Sitzung.

Warum stören die Rechte von ~/.ssh die Verbindung?

OpenSSH prüft aus Sicherheitsgründen die Dateirechte. Können andere Benutzer Ihren privaten Schlüssel lesen, verweigert der Client seine Nutzung und zeigt eine Warnung wie "UNPROTECTED PRIVATE KEY FILE". Auf dem Server gilt: Ist das Home Verzeichnis oder der Ordner .ssh für andere beschreibbar, stuft sshd den Eintrag womöglich als unsicher ein.

Die Option StrictModes im Handbuch zu sshd_config führt genau diese Prüfung aus. Üblicherweise empfohlen werden diese Werte:

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

Führen Sie dieselben Befehle dann auf dem Server im Home Verzeichnis des Benutzers aus, mit dem Sie sich anmelden. Prüfen Sie die genauen Werte außerdem im OpenSSH Handbuch Ihres Systems.

Wie setzen Sie IdentityFile in ~/.ssh/config?

Besitzen Sie mehrere Schlüssel oder trägt Ihr Schlüssel einen abweichenden Namen, müssen Sie dem Client sagen, welchen er nehmen soll. Das Handbuch zu ssh_config definiert dafür die Optionen IdentityFile und IdentitiesOnly.

Host github.com
  User git
  IdentityFile ~/.ssh/id_ed25519_github
  IdentitiesOnly yes

• Host: legt fest, für welchen Server die Regel gilt.
• User: setzt den Standardbenutzer fest, also tippen Sie ihn nicht jedes Mal.
• IdentityFile: zeigt auf den privaten Schlüssel, den der Client nutzt.
• IdentitiesOnly yes: bietet nur den genannten Schlüssel an und sendet die übrigen Schlüssel aus dem Agenten nicht.

Diese Einstellung hilft daher Entwicklern mit mehreren GitHub Konten. Sie erzeugen zum Beispiel zwei Schlüssel, einen für die Arbeit und einen privaten, und geben jedem einen eigenen Host Namen. Dann bietet der Client nie den Schlüssel des falschen Kontos an.

Wie testen Sie die GitHub Verbindung mit ssh -T?

Sie können die Verbindung mit einem Befehl prüfen, bevor Sie etwas klonen. Die GitHub Docs empfehlen diesen Befehl, um eine SSH Verbindung zu testen:

ssh -T git@github.com

Klappt es, dann antwortet GitHub mit einer Begrüßung, die Ihre Identität bestätigt. Bei der ersten Verbindung bittet ssh Sie, den Fingerabdruck des Servers zu bestätigen. Vergleichen Sie ihn zunächst mit den Werten, die die GitHub Docs veröffentlichen, und bestätigen Sie dann.

Sehen Sie weiterhin "Permission denied (publickey)", erhöhen Sie den Detailgrad mit ssh -vT git@github.com. Prüfen Sie, ob der angebotene Schlüssel dem Schlüssel in Ihrem Konto entspricht. Geht weiter der falsche Schlüssel raus, kehren Sie zum Abschnitt über die Config zurück.

Was ändert sich, wenn die Passwort Anmeldung auf dem Server aus ist?

Gehärtete Server enthalten meist die Zeile PasswordAuthentication no. Laut Handbuch zu sshd_config schaltet diese Option die Passwort Anmeldung ab und lässt nur schlüsselbasierte Methoden zu. Aus Sicherheitssicht ist das richtig. Allerdings sperrt es Sie aus, wenn Ihr Schlüssel nicht funktioniert.

In dieser Lage haben Sie drei sichere Wege:

• Erstens nutzen Sie die Web Konsole oder den Rettungszugang im Hosting oder Cloud Panel und korrigieren den Schlüssel.
• Zweitens melden Sie sich mit einem anderen Administrator Konto an, falls vorhanden, und aktualisieren authorized_keys.
• Sonst wenden Sie sich an den Support Ihres Anbieters. Er führt Sie nach einer Identitätsprüfung durch die Wiederherstellung.

Versuchen Sie niemals, die Regeln mit dem Konto einer anderen Person oder mit Fremden zu umgehen, die "Zugang zurückholen" verkaufen. Diese Wege sind sicherheitlich und rechtlich riskant und schaffen oft ein zweites Problem.

Wie sperren Sie sich nicht selbst vom Server aus?

Ändern Sie einen Schlüssel oder eine sshd Einstellung, besteht das größte Risiko darin, die laufende Sitzung zu schließen und nicht mehr hineinzukommen. Die Regel ist einfach. Schließen Sie die alte Sitzung nicht, bevor Sie die neue Einstellung getestet haben.

1. Zunächst lassen Sie Ihre aktuelle Sitzung offen.
2. Dann tragen Sie die neue Einstellung oder den neuen Schlüssel ein.
3. Dann öffnen Sie ein neues Terminalfenster und bauen Sie mit dem neuen Schlüssel eine zweite Verbindung auf.
4. Funktioniert die neue Verbindung, schließen Sie die alte Sitzung.
5. Scheitert sie, dann machen Sie die Änderung über die alte Sitzung rückgängig.

Außerdem prüfen Sie nach einer Änderung der sshd Konfiguration die Syntax, bevor Sie den Dienst neu starten. Das Handbuch zu sshd definiert dafür einen Testmodus mit dem Schalter -t. So verhindert ein Tippfehler nicht den Start des Dienstes.

Alle Schritte zur Absicherung eines Servers lesen Sie in unserer Anleitung zu Swap Datei und SSH Absicherung unter Linux. Bringen Sie gerade eine neue App live, nutzt auch unsere Anleitung zum Next.js Deployment auf einem VPS dieselbe Verbindungslogik.

Welchen SSH Schlüsseltyp sollten Sie wählen?

Erzeugen Sie einen neuen Schlüssel, ist ed25519 heute eine verbreitete und empfohlene Wahl. Die OpenSSH Dokumentation führt ihn als modernes Signaturverfahren, und die GitHub Docs nutzen ed25519 in ihren Schritten zur Schlüsselerzeugung. Brauchen Sie Kompatibilität mit alten Systemen, können Sie RSA verwenden, prüfen Sie dann aber die aktuelle Empfehlung zur Schlüssellänge in der offiziellen Dokumentation.

ssh-keygen -t ed25519 -C "name@example.com"

• Zunächst erzeugt der Befehl das Schlüsselpaar im Standardordner und fragt nach einer Passphrase.
• Außerdem erschwert eine Passphrase die Nutzung des Schlüssels allein, selbst wenn jemand Ihren Laptop stiehlt.
• Ein Kommentar (-C) wie E-Mail oder Rechnername hilft Ihnen später, Schlüssel zu unterscheiden.
• Kennt ein sehr alter Server ed25519 nicht, denken Sie zuerst über ein Update seiner OpenSSH Version nach.

Welche Ursache passt zu welchem Symptom und welcher Lösung?

Die Tabelle fasst die Diagnose Reihenfolge für ssh permission denied publickey zusammen. Oben steht die wahrscheinlichste Ursache, unten die unwahrscheinlichste.

Warum sollten Sie Ihren privaten Schlüssel nie teilen?

Ein Public Key funktioniert wie ein Türschloss. Sie können ihn an beliebig viele Personen geben. Der private Schlüssel ist dagegen der Schlüssel, der dieses Schloss öffnet. Senden Sie ihn jemandem, kann diese Person in Ihrem Namen auf den Server zugreifen.

• Erstens fügen Sie den Inhalt des privaten Schlüssels nie in Support Chats, Foren oder KI Werkzeuge ein.
• Prüfen Sie beim Teilen von Fehlerausgaben, dass die Zeilen von ssh -v keinen Schlüsselinhalt enthalten. Ein Dateipfad ist unproblematisch, der Dateiinhalt nicht.
• Zweitens: Vermuten Sie ein Leck, erzeugen Sie ein neues Paar und entfernen das alte vom Server und von GitHub.
• Drittens committen Sie Schlüssel nie in ein Repository. Ist es versehentlich passiert, müssen Sie den Schlüssel ersetzen.

Kurz gesagt: Schützen Sie den privaten Schlüssel wie ein Passwort. Nutzen Sie noch keinen Passwortmanager, erzeugt unser kostenloser Passwort Generator einen starken Wert für Ihre Passphrase.

Wie fügt ssh-copy-id einen Schlüssel sicher hinzu?

Einen Public Key von Hand zu kopieren ist eine häufige Fehlerquelle. Haben Sie also noch Zugriff, nutzen Sie das Werkzeug ssh-copy-id. Es gehört zu OpenSSH und trägt den Schlüssel in die richtige Datei mit den richtigen Rechten ein.

ssh-copy-id -i ~/.ssh/id_ed25519.pub benutzer@example.com

• Zunächst: Der Schalter -i sagt, welcher Public Key hinzukommt.
• Außerdem legt das Werkzeug den Ordner .ssh und die Datei authorized_keys an, falls sie fehlen.
• Danach testen Sie die Verbindung in einem neuen Terminal und schließen die alte Sitzung noch nicht.
• Können Sie das Werkzeug nicht nutzen, hängen Sie den Schlüssel als eine Zeile ans Dateiende an. Achten Sie darauf, dass das Zeilenende intakt bleibt.

Damit entfallen Rechte und Zeilenfehler aus Handarbeit. Zudem zeigt das Werkzeug an, wie viele Schlüssel es hinzugefügt hat.

Warum tritt der Fehler auf einem neuen Rechner so oft auf?

Beispielszenario: Ein Entwickler tauscht den Laptop, kopiert die Projekte und sieht den Fehler beim ersten git pull. Der private Schlüssel vom alten Rechner fehlt auf dem neuen. Im GitHub Konto steht also nur der Public Key des alten Geräts.

Sie haben hier zwei Möglichkeiten. Erstens verschieben Sie den alten Schlüssel auf einem sicheren Weg. Zweitens erzeugen Sie auf dem neuen Gerät ein neues Paar und tragen dessen öffentliche Hälfte ins Konto ein. Der zweite Weg ist meist sauberer, denn jedes Gerät besitzt seinen eigenen Schlüssel, und Sie entfernen den Schlüssel eines verlorenen Geräts, ohne andere anzufassen.

1. Erzeugen Sie auf dem neuen Gerät mit ssh-keygen -t ed25519 einen Schlüssel.
2. Tragen Sie den Inhalt der öffentlichen Datei in Ihr GitHub Konto oder in die authorized_keys des Servers ein.
3. Laden Sie den Schlüssel mit ssh-add in den Agenten.
4. Testen Sie mit ssh -T git@github.com.
5. Nutzen Sie das alte Gerät nicht mehr, löschen Sie dessen Schlüssel aus dem Konto.

Warum tritt der Fehler in CI/CD oder beim automatischen Deployment auf?

Automatisierungswerkzeuge verhalten sich wie ein eigener Rechner und erreichen Ihren Schlüssel nicht. Deshalb begegnet Ihnen derselbe Fehler oft in Deployment Pipelines. Meist wurde der Schlüssel nie in die geheimen Variablen der Pipeline eingetragen oder in falscher Form.

• Erstens erzeugen Sie ein eigenes Schlüsselpaar für die Pipeline. Laden Sie Ihren persönlichen Schlüssel nicht hoch.
• Zweitens bewahren Sie die Zeilenumbrüche des privaten Schlüsseltexts. Ein in eine Zeile gepresster Schlüssel ist ungültig.
• Geben Sie der öffentlichen Hälfte nach Möglichkeit nur lesenden Zugriff. Die GitHub Docs beschreiben dafür Deploy Keys pro Repository.
• Bei der ersten Verbindung wartet ssh auf die Bestätigung des Fingerabdrucks, und dieses Warten kann die Pipeline blockieren.

Ist Ihr Release Prozess unübersichtlich geworden, können unsere KI Automatisierung Leistungen Ihre Abläufe vereinfachen.

Was passiert, wenn Sie die Passphrase vergessen?

Die Passphrase verschlüsselt die Datei des privaten Schlüssels. Vergessen Sie sie, können Sie die Datei nicht mehr öffnen, und das ist ein gewolltes Sicherheitsmerkmal. Brute Force Werkzeuge zu probieren kostet nur Zeit und kann als Angriff auf ein System gelten.

Der richtige Weg ist ein neues Schlüsselpaar. Dann tragen Sie den neuen Public Key auf dem Server oder bei GitHub ein und entfernen den alten. Dafür brauchen Sie einen anderen Zugang zum Server, zum Beispiel die Konsole im Panel.

Wie lesen Sie die echte Ursache auf der Serverseite?

Die Ausgabe des Clients sagt nur "abgelehnt", aber nie warum. Den Grund finden Sie im Protokoll des Servers. Erreichen Sie den Server auf anderem Weg, lesen Sie die Anmeldeprotokolle. Bei vielen Linux Distributionen liegen sie in auth.log oder in der Ausgabe von journalctl.

Typischerweise sehen Sie dort Zeilen, die diesen ähneln:

• Eine Zeile, die den Benutzer als unbekannt meldet, das heißt, der Benutzername ist falsch.
• Außerdem eine Zeile, die auf die Rechte der Autorisierungsdatei zeigt, das heißt, StrictModes hat den Eintrag abgelehnt.
• Dann eine Zeile, die den Schlüssel als nicht akzeptiert meldet, das heißt, der Public Key fehlt oder sein Format ist kaputt.
• Schließlich eine Zeile, die das Benutzerkonto als gesperrt meldet, das heißt, Sie müssen das Konto zuerst entsperren.

Der genaue Wortlaut kann je nach Distribution und Version abweichen, verlassen Sie sich also nicht auf einen einzelnen Satz. Wichtig ist, dass das Protokoll den genauen Grund nennt, den der Client verbirgt. Brauchen Sie vorübergehend mehr Details, lesen Sie die Option LogLevel im Handbuch zu sshd_config.

Warum beginnt die Diagnose bei der wahrscheinlichsten Ursache?

Wahlloses Probieren erzeugt zwei Probleme. Es kostet Zeit, und jeder Versuch kann die Einrichtung weiter verändern und die echte Ursache verdecken. Daher machen wir zuerst umkehrbare Prüfungen und ändern erst dann Einstellungen.

Die Prüfung des Benutzernamens ändert nichts. Der Befehl ssh -v liest nur. Ebenso listet ssh-add -l nur auf. Diese drei Schritte zeigen die meisten Ursachen. Rechte ändern oder an sshd Einstellungen arbeiten folgt später, weil diese Schritte Risiken bergen.

Welche Fehler passieren bei diesem Problem am häufigsten?

Dies sind die wiederkehrenden Fehler, die wir in der Praxis sehen. Wenn Sie sie kennen, beschleunigt das die Diagnose stark.

• Erstens legen Sie den privaten Schlüssel auf den Server und den öffentlichen auf den eigenen Rechner. Sie vertauschen die Dateien, und nichts funktioniert.
• Zweitens benennen Sie die Schlüsseldatei um und vergessen, sie in der Config festzulegen.
• Drittens nutzen Sie bei GitHub eine HTTPS Adresse und geben dem SSH Schlüssel die Schuld.
• Außerdem tragen Sie den Schlüssel bei root ein und melden sich als anderer Benutzer an.
• Dann probieren Sie es immer wieder, statt die Ausgabe von ssh -v zu lesen.
• Schließlich schließen Sie die laufende Sitzung zuerst und testen die neue Einstellung danach.

Die meisten dieser Fehler beheben Sie in Minuten, sobald Sie genau hinsehen. Allerdings übersieht man sie in Eile. Daher führt Ruhe mit fester Reihenfolge schneller zum Ziel als Ausprobieren.

Was tun, wenn der Fehler weiter besteht?

Haben Sie die obigen Schritte der Reihe nach befolgt und der Fehler bleibt, schauen Sie auf einige seltene Ursachen. Sie sind selten, und deshalb übersieht man sie.

• Erstens kann der Server PubkeyAuthentication abgeschaltet haben. Das Handbuch zu sshd_config definiert diese Option.
• Zweitens kann AuthorizedKeysFile auf einen abweichenden Pfad zeigen, sodass Ihr Schlüssel in der falschen Datei liegt.
• Drittens kann das Benutzerkonto gesperrt sein, oder seine Shell ist ungültig.
• Zusätzliche Sicherheitsschichten wie SELinux können den Kontext des Home Verzeichnisses verändert haben.
• Können Sie das Serverprotokoll lesen, sehen Sie dort den echten Grund der Ablehnung.

Haben Sie Zugriff auf die Serverprotokolle, ist das der schnellste Weg. Denn sshd schreibt den echten Grund oft auf. Ein Rechteproblem, ein fehlender Schlüssel oder ein gesperrter Benutzer erscheinen als getrennte Meldungen.

Welche Checkliste sorgt für dauerhafte Vorsorge?

Wenige kleine Gewohnheiten halten diesen Fehler fern. Dieselbe Liste können Sie im Team teilen.

• Erstens erzeugen Sie für jedes Gerät einen eigenen Schlüssel und fügen Sie einen aussagekräftigen Kommentar hinzu.
• Zweitens schützen Sie Schlüssel mit einer Passphrase und nutzen Sie den SSH Agenten.
• Legen Sie in ~/.ssh/config für jeden Server Host, User und IdentityFile fest.
• Testen Sie die Anmeldung per Schlüssel in einer zweiten Sitzung, bevor Sie die Passwort Anmeldung abschalten.
• Dann räumen Sie alte und ungenutzte Schlüssel regelmäßig aus authorized_keys und aus Ihrem GitHub Konto auf.
• Entfernen Sie den passenden Schlüssel sofort, wenn ein Mitarbeiter geht oder ein Gerät verloren ist.

Diese Liste macht schon bei einem kleinen Team einen Unterschied. Zu benachbarten Problemen in Softwareprojekten lesen Sie außerdem unseren Ratgeber zum Git Merge Konflikt und unseren Ratgeber zum Python ModuleNotFoundError.

Wann brauchen Sie dafür professionelle Hilfe?

Einen Schlüssel auf einem Server hinzuzufügen dauert wenige Minuten. Bei Dutzenden Servern, mehreren Teammitgliedern und einer Deployment Pipeline wird die Schlüsselverwaltung dagegen eine eigene Aufgabe. Dann zählen die Berechtigungsstruktur, die Schlüsselrotation und Zugriffsprotokolle.

Möchten Sie eine solche Infrastruktur aufbauen oder eine bestehende vereinfachen, können Sie für unsere individuelle Softwareentwicklung ein Angebot anfordern. Zunächst hören wir Ihren Bedarf an, danach senden wir Ihnen einen klaren Umfang schriftlich.

Für einen einmaligen Fehler genügt die Diagnose Reihenfolge dieses Artikels meist. Lösen Sie einen Fall nicht, vergessen Sie beim Teilen der Ausgabe nicht, den Inhalt des privaten Schlüssels und die Serveradresse zu verbergen. Offizielle Quellen sind die Seite der GitHub Docs zur Fehlersuche, das OpenSSH Handbuch zu ssh, das Handbuch zu sshd_config und das Handbuch zu ssh_config.