Gestoppt durch „Permission denied (publickey)“? Diese Anleitung löst Ihr SSH-Problem garantiert

Kennen Sie das Gefühl? Sie möchten sich schnell mit Ihrem Server verbinden, ein Repository klonen oder einen Deploy starten, und dann erscheint diese gefürchtete Meldung: „Permission denied (publickey)“. Ein Frustmoment, der den Workflow abrupt unterbricht und oft zu Kopfzerbrechen führt. Doch keine Sorge! Dieses Problem ist einer der häufigsten Stolpersteine im Umgang mit SSH, aber auch einer der am besten zu lösenden. Mit dieser umfassenden Anleitung werden wir gemeinsam die Ursachen ergründen und Ihr SSH-Problem garantiert beheben.

SSH (Secure Shell) ist das Rückgrat sicherer Fernverbindungen und ein unverzichtbares Werkzeug für Entwickler, Systemadministratoren und jeden, der mit Remote-Servern arbeitet. Es ermöglicht eine verschlüsselte Kommunikation und Authentifizierung über unsichere Netzwerke. Wenn jedoch die Authentifizierung über Public-Key fehlschlägt, ist die Verbindung verwehrt. Lassen Sie uns tief in die Materie eintauchen.

Das Herzstück der Sicherheit: SSH-Schlüsselpaare verstehen

Bevor wir uns den Lösungen widmen, ist es entscheidend zu verstehen, wie die SSH-Schlüsselauthentifizierung funktioniert. Anstatt eines Passworts, das potenziell erraten oder abgefangen werden kann, verwendet SSH ein Kryptografie-Verfahren mit Schlüsselpaaren:

• Ein privater Schlüssel (id_rsa oder ähnliches): Dieser Schlüssel bleibt streng geheim auf Ihrem lokalen Rechner. Er ist vergleichbar mit Ihrem persönlichen Türschlüssel.
• Ein öffentlicher Schlüssel (id_rsa.pub oder ähnliches): Dieser Schlüssel wird auf dem Server abgelegt, zu dem Sie sich verbinden möchten (typischerweise in der Datei ~/.ssh/authorized_keys). Er ist vergleichbar mit einem Schloss, das nur von Ihrem privaten Schlüssel geöffnet werden kann.

Wenn Sie eine SSH-Verbindung herstellen, fordert der Server eine Authentifizierung an. Ihr lokaler SSH-Client verwendet dann Ihren privaten Schlüssel, um eine kryptografische Signatur zu erstellen, die nur zu dem öffentlichen Schlüssel auf dem Server passt. Stimmen die Schlüssel überein und sind alle weiteren Bedingungen erfüllt, wird die Verbindung hergestellt. Die Meldung „Permission denied (publickey)“ bedeutet im Kern, dass dieser Abgleich aus irgendeinem Grund fehlgeschlagen ist.

Häufige Ursachen und bewährte Lösungswege (Schritt für Schritt)

Die Gründe für den Authentifizierungsfehler können vielfältig sein, sind aber meist auf einige Standardprobleme zurückzuführen. Gehen Sie die folgenden Punkte systematisch durch, um die Ursache zu finden und zu beheben.

1. Der falsche private Schlüssel wird verwendet (Client-Seite)

Einer der häufigsten Fehler ist, dass Ihr SSH-Client versucht, sich mit dem falschen privaten Schlüssel zu authentifizieren. Dies passiert oft, wenn Sie mehrere Schlüsselpaare besitzen (z.B. für verschiedene Server oder Dienste wie GitHub/GitLab).

Lösung: Schlüssel explizit angeben oder SSH-Konfiguration nutzen

• Schlüssel explizit angeben: Wenn Ihr privater Schlüssel nicht im Standardpfad (~/.ssh/id_rsa) liegt oder einen anderen Namen hat, müssen Sie ihn mit der Option -i angeben:

  ssh -i /pfad/zu/ihrem/privaten_schluessel user@ihr_server

  Ersetzen Sie /pfad/zu/ihrem/privaten_schluessel durch den tatsächlichen Pfad zu Ihrer Schlüsseldatei (z.B. ~/.ssh/mein_server_key).

• SSH-Konfigurationsdatei (~/.ssh/config): Für eine dauerhafte Lösung und bessere Übersicht können Sie eine Konfigurationsdatei erstellen oder bearbeiten. Dies ist besonders nützlich, wenn Sie viele Server oder Schlüssel verwenden.

  Host mein_server_alias
      HostName ihr_server.example.com
      User ihr_benutzername
      IdentityFile ~/.ssh/mein_server_key
      Port 22 # Optional, falls ein anderer Port verwendet wird

  Speichern Sie dies in ~/.ssh/config. Danach können Sie sich einfach mit ssh mein_server_alias verbinden.

2. Der öffentliche Schlüssel fehlt oder ist falsch auf dem Server (Server-Seite)

Ihr privater Schlüssel ist nutzlos, wenn der passende öffentliche Schlüssel nicht auf dem Zielserver vorhanden ist oder falsch konfiguriert wurde. Dies ist die **häufigste Ursache** für „Permission denied (publickey)”.

Lösung: Öffentlichen Schlüssel auf den Server kopieren oder prüfen

• Mit ssh-copy-id kopieren (bevorzugt): Dies ist der einfachste und sicherste Weg, einen öffentlichen Schlüssel hinzuzufügen. Es kopiert den Schlüssel nicht nur, sondern setzt auch die korrekten Berechtigungen.

  ssh-copy-id -i ~/.ssh/ihr_schluessel.pub user@ihr_server

  Sie werden dabei möglicherweise nach dem Passwort des Benutzers auf dem Zielserver gefragt (falls die Passwort-Authentifizierung noch aktiviert ist) oder nach dem Passphrase Ihres privaten Schlüssels.

• Manueller Kopiervorgang: Falls ssh-copy-id nicht verfügbar ist oder Sie es vorziehen, können Sie den Schlüssel manuell kopieren. Sie benötigen hierfür zunächst eine alternative Anmeldemöglichkeit (z.B. Passwort-Authentifizierung, wenn diese noch funktioniert).
  1. Verbinden Sie sich mit dem Server (z.B. via Passwort).
  2. Stellen Sie sicher, dass das Verzeichnis ~/.ssh/ existiert:

     mkdir -p ~/.ssh

  3. Fügen Sie den Inhalt Ihres öffentlichen Schlüssels (~/.ssh/ihr_schluessel.pub von Ihrem lokalen Rechner) zur Datei ~/.ssh/authorized_keys auf dem Server hinzu. Achten Sie darauf, keine Zeilenumbrüche einzufügen; jeder Schlüssel muss in einer einzigen Zeile stehen:

     echo "Ihr_öffentlicher_Schlüssel_hier" >> ~/.ssh/authorized_keys

     Oder einfacher, von Ihrem lokalen Rechner aus (wenn Sie Zugriff haben):

     cat ~/.ssh/ihr_schluessel.pub | ssh user@ihr_server "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

  4. Überprüfen Sie den Inhalt der authorized_keys-Datei auf dem Server:

     cat ~/.ssh/authorized_keys

     Stellen Sie sicher, dass Ihr Schlüssel korrekt und vollständig eingetragen ist.

3. Falsche Berechtigungen auf Client-Seite

SSH ist sehr wählerisch, was die Dateiberechtigungen Ihrer Schlüsseldateien betrifft. Sind sie zu offen, verweigert der Client die Nutzung aus Sicherheitsgründen.

Lösung: Berechtigungen korrigieren

• Verzeichnis ~/.ssh/: Muss nur für den Besitzer les- und schreibbar sein.

  chmod 700 ~/.ssh

• Privater Schlüssel (z.B. ~/.ssh/id_rsa): Muss nur für den Besitzer lesbar sein.

  chmod 600 ~/.ssh/id_rsa

• Öffentlicher Schlüssel (z.B. ~/.ssh/id_rsa.pub): Die Berechtigungen sind hier weniger kritisch, aber 644 ist ein guter Standard.

  chmod 644 ~/.ssh/id_rsa.pub

4. Falsche Berechtigungen auf Server-Seite

Auch auf dem Server müssen die Dateiberechtigungen für das SSH-Verzeichnis und die authorized_keys-Datei korrekt sein. Der SSH-Dienst (sshd) verweigert die Nutzung, wenn die Berechtigungen zu lax sind.

Lösung: Berechtigungen auf dem Server korrigieren

Verbinden Sie sich mit dem Server (falls möglich, z.B. per Passwort-Authentifizierung oder durch eine temporäre Aktivierung) und führen Sie die folgenden Befehle aus:

• Home-Verzeichnis des Benutzers: Das Home-Verzeichnis (~, z.B. /home/user) sollte nicht für andere Benutzer schreibbar sein.

  chmod 755 /home/ihr_benutzer

  Manche Systeme (insbesondere ältere SSH-Versionen) bevorzugen sogar 700 für das Home-Verzeichnis, aber 755 ist meistens ausreichend.

• Verzeichnis ~/.ssh/:

  chmod 700 ~/.ssh

• Datei ~/.ssh/authorized_keys:

  chmod 600 ~/.ssh/authorized_keys

5. Der falsche Benutzername wird verwendet

Vergewissern Sie sich, dass Sie versuchen, sich als der richtige Benutzer auf dem Server anzumelden. Jeder Benutzer hat sein eigenes ~/.ssh/authorized_keys-Verzeichnis.

Lösung: Korrekten Benutzernamen verwenden

• Standard-Benutzernamen sind oft root, admin, ubuntu, ec2-user, etc.
• Geben Sie den Benutzernamen explizit an:

  ssh ihr_benutzername@ihr_server

6. SSH-Agent läuft nicht oder Schlüssel nicht hinzugefügt

Der ssh-agent ist ein Programm, das private Schlüssel im Arbeitsspeicher speichert, sodass Sie Ihr Passphrase nur einmal eingeben müssen, selbst wenn Sie sich mit mehreren Servern verbinden. Wenn der Agent nicht läuft oder Ihr Schlüssel nicht hinzugefügt wurde, können Authentifizierungen fehlschlagen.

Lösung: SSH-Agent starten und Schlüssel hinzufügen

• Agent starten (falls nicht automatisch geschehen):

  eval "$(ssh-agent -s)"

• Schlüssel zum Agent hinzufügen:

  ssh-add ~/.ssh/ihr_schluessel

  Wenn Ihr privater Schlüssel eine Passphrase hat, werden Sie jetzt danach gefragt.

• Überprüfen, welche Schlüssel geladen sind:

  ssh-add -l

7. SSH-Server-Konfiguration (sshd_config)

Manchmal sind die Einstellungen des SSH-Dienstes auf dem Server (sshd) so konfiguriert, dass die Public-Key-Authentifizierung blockiert wird oder andere Restriktionen greifen.

Lösung: sshd_config prüfen und anpassen

Verbinden Sie sich mit dem Server (möglicherweise benötigen Sie dafür noch temporär die Passwort-Authentifizierung) und prüfen Sie die Datei /etc/ssh/sshd_config:

• Öffnen Sie die Datei mit einem Editor:

  sudo nano /etc/ssh/sshd_config

• Suchen Sie nach folgenden Zeilen und stellen Sie sicher, dass sie korrekt konfiguriert sind:
  • PubkeyAuthentication yes (Muss auf yes stehen.)
  • AuthorizedKeysFile .ssh/authorized_keys (Stellt sicher, dass der richtige Pfad zur Schlüsseldatei verwendet wird. Manchmal ist hier ein absoluter Pfad angegeben.)
  • PasswordAuthentication no (Dies ist eine bewährte Sicherheitspraxis, kann aber beim Debugging vorübergehend auf yes gesetzt werden, um sich per Passwort anzumelden und das Problem zu beheben. Danach unbedingt wieder auf no setzen!)
  • AllowUsers, DenyUsers, AllowGroups, DenyGroups: Stellen Sie sicher, dass Ihr Benutzer nicht explizit ausgeschlossen ist oder in einer ausgeschlossenen Gruppe ist.
  • StrictModes yes (Dies ist der Standardwert und stellt sicher, dass SSH die Dateiberechtigungen prüft. Sollte auf yes bleiben.)
• Nach Änderungen in der sshd_config müssen Sie den SSH-Dienst neu starten:

  sudo systemctl restart sshd

  oder bei älteren Systemen:

  sudo service sshd restart

8. SELinux oder AppArmor (Linux-spezifisch)

Auf Systemen wie CentOS/RHEL (SELinux) oder Ubuntu (AppArmor) können erweiterte Sicherheitsfunktionen den Zugriff auf die authorized_keys-Datei blockieren, selbst wenn die Dateiberechtigungen scheinbar korrekt sind.

Lösung: Systemprotokolle prüfen

• Prüfen Sie die Audit-Logs auf SELinux-Verweigerungen:

  sudo ausearch -c sshd | grep AVC

• Prüfen Sie die Kernel-Logs für AppArmor-Meldungen:

  sudo dmesg | grep AppArmor

• Wenn Sie hier Meldungen finden, müssen Sie die entsprechenden SELinux-Kontexte anpassen oder AppArmor-Regeln bearbeiten. Dies ist ein fortgeschrittenes Thema. Für Testzwecke können Sie SELinux temporär in den Permissive-Modus versetzen (sudo setenforce 0) oder AppArmor für SSH deaktivieren. Dies sollte jedoch keine Dauerlösung sein.

9. Firewall-Einstellungen

Obwohl es seltener die direkte Ursache für „Permission denied (publickey)” ist (was eher ein Authentifizierungsproblem ist als ein Verbindungsproblem), kann eine Firewall die gesamte SSH-Verbindung blockieren.

Lösung: Firewall prüfen

• Client-Seite: Überprüfen Sie, ob Ihre lokale Firewall ausgehende Verbindungen auf Port 22 (oder Ihren benutzerdefinierten SSH-Port) zulässt.
• Server-Seite: Überprüfen Sie, ob die Server-Firewall (z.B. ufw, firewalld, AWS Security Groups) eingehende Verbindungen auf Port 22 (oder Ihren benutzerdefinierten SSH-Port) zulässt.

  sudo ufw status

  sudo firewall-cmd --list-all

10. Beschädigter Schlüssel oder unbekanntes Schlüsselformat

Sehr selten kann ein Schlüssel beschädigt sein oder in einem Format vorliegen, das vom Server nicht erkannt wird. Oder es wird ein älteres, unsicheres Format verwendet.

Lösung: Schlüssel neu generieren

• Generieren Sie ein neues SSH-Schlüsselpaar:

  ssh-keygen -t rsa -b 4096

  Folgen Sie den Anweisungen und vergeben Sie eine sichere Passphrase.

• Kopieren Sie den neu erstellten öffentlichen Schlüssel auf den Server (siehe Punkt 2).

Fortgeschrittenes Debugging mit SSH

Wenn alle Stricke reißen, kann die verbose Ausgabe des SSH-Clients Ihnen wertvolle Hinweise geben. Verwenden Sie die Option -v, -vv oder -vvv, um detailliertere Informationen über den Verbindungsprozess zu erhalten:

ssh -vvv user@ihr_server

Beachten Sie die Zeilen, die auf „Authentications that can continue:“ oder ähnliche Meldungen hinweisen. Diese geben an, welche Authentifizierungsmethoden der Server akzeptiert und welche davon fehlschlagen. Auch Zeilen wie „debug1: read_private_key: private key file has bad permissions“ oder „debug1: identity file /path/to/key type -1 is not a public key“ sind sehr aufschlussreich.

Zusätzlich können die Server-Logs auf dem Zielsystem weitere Details liefern. Schauen Sie sich die Authentifizierungslogs an:

• Debian/Ubuntu: sudo tail -f /var/log/auth.log
• CentOS/RHEL: sudo tail -f /var/log/secure
• Systemd-basierte Systeme (modern): sudo journalctl -u sshd -f

Suchen Sie nach Fehlern, die mit „Authentication refused: bad ownership or modes“ oder ähnlichem beginnen. Dies kann Ihnen genau sagen, wo auf dem Server die Dateiberechtigungen falsch sind.

Best Practices für SSH-Sicherheit

Nachdem Sie Ihr Problem behoben haben, ist es sinnvoll, einige bewährte Methoden zu implementieren, um zukünftige Probleme zu vermeiden und Ihre Server sicherer zu machen:

• Verwenden Sie Passphrases: Schützen Sie Ihre privaten Schlüssel immer mit einer starken Passphrase.
• Deaktivieren Sie Root-Login: Melden Sie sich niemals direkt als Root an. Melden Sie sich als normaler Benutzer an und verwenden Sie sudo für administrative Aufgaben.
• Deaktivieren Sie Passwort-Authentifizierung: Sobald die Schlüsselauthentifizierung funktioniert, deaktivieren Sie die Passwort-Authentifizierung in sshd_config, um Brute-Force-Angriffe zu verhindern.
• Ändern Sie den Standard-SSH-Port: Wenn möglich, ändern Sie den Standard-SSH-Port von 22 auf einen ungenutzten Port über 1024. Dies reduziert das Rauschen von automatisierten Angriffsversuchen.
• Halten Sie Ihre Schlüssel sicher: Geben Sie Ihre privaten Schlüssel niemals weiter. Bewahren Sie sie an einem sicheren Ort auf.
• Regelmäßige Aktualisierungen: Halten Sie Ihr Betriebssystem und alle SSH-Komponenten auf dem neuesten Stand.

Fazit

Die Fehlermeldung „Permission denied (publickey)“ ist zwar ärgerlich, aber in den meisten Fällen auf eine der hier beschriebenen Ursachen zurückzuführen und relativ einfach zu beheben. Der Schlüssel zur Lösung liegt in einer systematischen Fehlersuche: Beginnen Sie mit den gängigsten Problemen (falscher Schlüssel, fehlender Schlüssel auf dem Server, falsche Berechtigungen) und arbeiten Sie sich dann zu den komplexeren Szenarien vor. Mit den Debugging-Tools wie ssh -vvv und den Server-Logs haben Sie mächtige Helfer an Ihrer Seite.

Wir hoffen, diese detaillierte Anleitung hat Ihnen geholfen, Ihr SSH-Problem zu lösen und Ihr Verständnis für SSH-Schlüsselauthentifizierung zu vertiefen. Sichere Verbindungen und fröhliches Schaffen!