DevOps Wissensdatenbank
DevOps Wissensdatenbank

Diagnose und Behebung von SSH-Authentifizierungsfehlern

Haben Sie Probleme mit SSH-Authentifizierungsfehlern? Dieser umfassende Leitfaden bietet Schritt-für-Schritt-Anleitungen zur Diagnose und Behebung häufiger Probleme. Lernen Sie, den clientseitigen Verbose-Modus (`ssh -vvv`) effektiv zu nutzen, um Verbindungsversuche zu verstehen, und serverseitige Protokolle (`/var/log/auth.log` oder `/var/log/secure`) zur eindeutigen Fehlererkennung zu interpretieren. Wir behandeln häufige Fallstricke wie falsche Berechtigungen, fehlkonfigurierte öffentliche Schlüssel und Servereinstellungen und bieten umsetzbare Lösungen, um Ihren sicheren Fernzugriff schnell und effizient wiederherzustellen.

46 Aufrufe

Diagnose und Behebung von SSH-Authentifizierungsfehlern

Secure Shell (SSH) ist das Fundament der sicheren Fernverwaltung und ermöglicht verschlüsselten Zugriff auf Server und Netzwerkgeräte. Auf Authentifizierungsfehler zu stoßen, ist jedoch eine häufige und oft frustrierende Erfahrung für Systemadministratoren und Entwickler gleichermaßen. Diese Probleme können eine Vielzahl von Ursachen haben, von einfachen Tippfehlern bis hin zu komplexen Berechtigungsproblemen oder Fehlkonfigurationen.

Dieser Artikel dient als umfassender Leitfaden zur effektiven Diagnose und Behebung von SSH-Authentifizierungsfehlern. Wir werden systematische Fehlerbehebungsmethoden untersuchen und dabei die entscheidende Rolle der clientseitigen ausführlichen Ausgabe und der serverseitigen Protokollanalyse hervorheben. Indem Sie verstehen, wie diese Diagnosehinweise interpretiert werden, sind Sie in der Lage, die Grundursache der meisten Authentifizierungsprobleme zu ermitteln und Ihren sicheren Fernzugriff wiederherzustellen.

Verständnis der SSH-Authentifizierungsmethoden

Bevor wir uns mit der Fehlerbehebung befassen, ist es wichtig, die wichtigsten Authentifizierungsmethoden zu verstehen, die SSH verwendet:

  • Passwortauthentifizierung: Der Benutzer gibt ein Passwort ein, das der Server anhand seiner Benutzerdatenbank oder eines externen Authentifizierungsdienstes (wie PAM) überprüft.
  • Schlüsselpaar-Authentifizierung: Diese sicherere Methode verwendet ein Paar kryptografischer Schlüssel: einen privaten Schlüssel, der auf dem Client gespeichert ist, und einen entsprechenden öffentlichen Schlüssel, der auf dem Server gespeichert ist. Bei der Authentifizierung verwendet der Client seinen privaten Schlüssel, um seine Identität nachzuweisen, ohne jemals den privaten Schlüssel über das Netzwerk zu senden.

Bei beiden Methoden können Authentifizierungsfehler auftreten, die Schritte zur Fehlerbehebung unterscheiden sich jedoch häufig.

Erste Prüfungen und häufige Fallstricke

Bevor Sie sich mit ausführlichen Protokollen befassen, ist es ratsam, einige grundlegende Prüfungen durchzuführen, da viele Probleme oft einfache Übersehen sind:

  • Korrekter Benutzername und Hostname: Überprüfen Sie doppelt, ob Sie den richtigen Benutzernamen und den exakten Hostnamen oder die IP-Adresse des Zielservers verwenden.
  • Netzwerkkonnektivität: Können Sie den Server überhaupt erreichen? Verwenden Sie ping, um die grundlegende Netzwerkreichweite zu überprüfen.
    bash ping example.com
  • SSH-Dienststatus: Läuft der SSH-Server (sshd) tatsächlich auf der Zielmaschine? Wenn Sie Konsolenzugriff haben, überprüfen Sie dessen Status.
    bash sudo systemctl status sshd # Für systemd-basierte Systeme (die meisten modernen Linux-Systeme) sudo service sshd status # Für ältere Init-Systeme
  • SSH-Port: Lauscht der SSH-Daemon auf dem Standardport (22) oder einem benutzerdefinierten Port? Wenn es sich um einen benutzerdefinierten Port handelt, müssen Sie diesen mit -p angeben.
  • Firewall-Regeln: Blockieren Firewalls (client- oder serverseitig) Port 22 (oder Ihren benutzerdefinierten SSH-Port)? Überprüfen Sie Server-Firewalls wie ufw, firewalld oder AWS-Sicherheitsgruppen.
    bash sudo ufw status sudo firewall-cmd --list-all

Clientseitige Diagnose: Nutzung des ausführlichen Modus

Der SSH-Client bietet ausführliche Modi (-v, -vv, -vvv), die detaillierte Debugging-Ausgaben über den Verbindungsprozess und Authentifizierungsversuche liefern. Diese Ausgabe ist von unschätzbarem Wert, um zu verstehen, warum der Client glaubt, dass die Authentifizierung fehlschlägt.

Verwendung ausführlicher Flags

  • -v: Ausführliche Ausgabe.
  • -vv: Ausführlichere Ausgabe.
  • -vvv: Noch ausführlichere Ausgabe (oft am nützlichsten bei Authentifizierungsproblemen).

Beispielbefehl:

ssh -vvv username@your_server_ip

Interpretation der ausführlichen Ausgabe

Wenn Sie ssh im ausführlichen Modus ausführen, suchen Sie nach wichtigen Zeilen, die angeben, wo der Authentifizierungsprozess fehlschlägt:

  • debug1: Authentications that can continue:: Diese Zeile gibt an, welche Authentifizierungsmethoden der Server akzeptieren möchte. Wenn Ihre gewünschte Methode (z. B. publickey) nicht aufgeführt ist, verhindert die Serverkonfiguration dies.
    debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
  • debug1: Offering public key:: Dies zeigt an, dass Ihr Client versucht, einen bestimmten öffentlichen Schlüssel zur Authentifizierung zu verwenden. Wenn Sie eine öffentliche Schlüsselauthentifizierung erwarten, aber dies nicht sehen, findet oder bietet Ihr Client den Schlüssel nicht an.
    debug1: Offering public key: /home/user/.ssh/id_rsa RSA SHA256:...
  • debug3: send_pubkey_test: ... trying private key: /home/user/.ssh/id_rsa: Dies bestätigt, dass der Client versucht, einen bestimmten privaten Schlüssel zu verwenden.
  • debug1: Server accepts key: ...: Dies würde aus Client-Sicht eine erfolgreiche öffentliche Schlüsselauthentifizierung bedeuten. Wenn Sie dies nicht sehen, wurde der Schlüssel wahrscheinlich vom Server abgelehnt.
  • debug1: No more authentication methods to try.: Dies erscheint oft direkt vor einer Permission denied-Fehlermeldung und bedeutet, dass der Client alle verfügbaren Authentifizierungsmethoden ohne Erfolg durchlaufen hat.
  • debug1: Permission denied (publickey,password).: Dies ist der endgültige clientseitige Fehler, der die Ablehnung aller Versuche durch den Server zusammenfasst.

Tipp: Achten Sie genau auf die Reihenfolge der angebotenen und akzeptierten Authentifizierungsmethoden. Wenn publickey angeboten wird, aber dann sofort eine Passwortabfrage folgt, bedeutet dies oft, dass der Server den öffentlichen Schlüssel abgelehnt hat.

Serverseitige Diagnose: Überprüfung der SSH-Serverprotokolle

Während die clientseitige ausführliche Ausgabe zeigt, was der Client versucht zu tun, liefern Serverprotokolle definitive Informationen darüber, warum der Server den Authentifizierungsversuch abgelehnt hat. Dies ist oft der wichtigste Schritt bei der Ursachenanalyse.

Lokalisierung von SSH-Serverprotokollen

Der Speicherort der SSH-Serverprotokolle variiert je nach Betriebssystem:

  • Debian/Ubuntu und Derivate: /var/log/auth.log
  • RHEL/CentOS/Fedora und Derivate: /var/log/secure
  • Systemd-basierte Systeme (die meisten modernen Linux-Systeme): Sie können auch journalctl verwenden.

Anzeigen und Filtern von Serverprotokollen

Verwenden Sie Tools wie tail oder journalctl, um Protokolle in Echtzeit zu überwachen oder nach SSH-spezifischen Einträgen zu filtern.

Beispielbefehle:

# Für Debian/Ubuntu
sudo tail -f /var/log/auth.log | grep sshd

# Für RHEL/CentOS
sudo tail -f /var/log/secure | grep sshd

# Für systemd-basierte Systeme (der robusteste Weg, aktuelle Protokolle anzuzeigen)
sudo journalctl -u sshd -f

# Um alle sshd-Protokolle von Anfang an anzuzeigen (nützlich, wenn der Fehler früher aufgetreten ist)
sudo journalctl -u sshd

Häufige Serverprotokolleinträge und ihre Bedeutungen

Suchen Sie nach Meldungen im Zusammenhang mit sshd, wenn Sie versuchen, eine Verbindung herzustellen. Hier sind einige gängige Einträge, die auf Authentifizierungsfehler hinweisen:

  • Failed password for user from IP port ssh2: Zeigt an, dass ein Passwortauthentifizierungsversuch fehlgeschlagen ist. Dies kann an einem falschen Passwort liegen oder daran, dass der Benutzer keine passwortbasierte Anmeldung darf.
  • Authentication refused: bad ownership or modes for directory /home/user/.ssh: Dies ist ein sehr häufiger Fehler bei der öffentlichen Schlüsselauthentifizierung. Das .ssh-Verzeichnis auf dem Server hat falsche Berechtigungen.
    • Lösung: chmod 700 /home/user/.ssh
  • Authentication refused: bad ownership or modes for file /home/user/.ssh/authorized_keys: Ein weiterer häufiger Fehler bei der öffentlichen Schlüsselauthentifizierung, der darauf hinweist, dass die Datei authorized_keys falsche Berechtigungen hat.
    • Lösung: chmod 600 /home/user/.ssh/authorized_keys
  • sshd[PID]: error: Permissions 0777 for '/home/user/.ssh/authorized_keys' are too open.: Gibt explizit das Problem mit zu offenen Dateiberechtigungen an. SSH ist aus Sicherheitsgründen sehr streng bei Berechtigungen.
  • User username from IP not allowed because not listed in AllowUsers: Der Benutzer darf sich gemäß der Direktive AllowUsers in /etc/ssh/sshd_config nicht per SSH anmelden.
  • User username from IP not allowed because listed in DenyUsers: Dem Benutzer wird der SSH-Zugriff durch DenyUsers explizit verweigert.
  • input_userauth_request: invalid user username: Der angegebene Benutzername existiert auf dem Server nicht.
  • Publickey authentication refused: authenticate using identity file.: Dies bedeutet normalerweise, dass der vom Client präsentierte öffentliche Schlüssel nicht mit einem Schlüssel in der authorized_keys-Datei des Servers für diesen Benutzer übereinstimmt oder das Schlüsselformat falsch ist.
  • Maximum authentication attempts exceeded for user from IP: Der Client hat zu viele Authentifizierungsmethoden versucht oder zu viele falsche Anmeldeinformationen gesendet. Gesteuert durch MaxAuthTries in sshd_config.
  • Connection closed by authenticating user IP port 22 [preauth]: Dies kann auftreten, wenn keine akzeptable Authentifizierungsmethode gefunden wurde oder wenn der Client die Verbindung nach einem Fehler abrupt schließt.

Häufige Authentifizierungsfehlerszenarien und Lösungen

Lassen Sie uns gängige Fehler und ihre spezifischen Behebungen kategorisieren.

1. Passwortauthentifizierungsfehler

  • Falsches Passwort: Das einfachste Problem. Überprüfen Sie Ihr Passwort doppelt. Achten Sie auf Tastaturlayouts, Feststelltaste oder Num-Lock.
  • Benutzer nicht gestattet: Die Datei sshd_config (/etc/ssh/sshd_config) kann die Anmeldung für bestimmte Benutzer einschränken.
    • PermitRootLogin no: Verhindert die Anmeldung als Root (dringend empfohlen aus Sicherheitsgründen).
    • AllowUsers username1 username2: Nur die angegebenen Benutzer dürfen sich anmelden.
    • DenyUsers username: Angegebene Benutzer dürfen sich nicht anmelden.
    • AllowGroups groupname: Nur Benutzer in angegebenen Gruppen dürfen sich anmelden.
    • Lösung: Passen Sie die sshd_config-Direktiven an und starten Sie sshd neu.
  • PAM-Probleme: Wenn der Server Pluggable Authentication Modules (PAM) verwendet, können Probleme mit der PAM-Konfiguration die Passwortauthentifizierung verhindern. Überprüfen Sie /var/log/auth.log auf PAM-spezifische Fehler. Dies ist für einfache SSH-Setups weniger üblich.

2. Fehler bei der öffentlichen Schlüsselauthentifizierung

Die öffentliche Schlüsselauthentifizierung ist oft sicherer, aber anfälliger für konfigurationsbedingte Fehler.

  • Falsche Datei-/Verzeichnisberechtigungen (Serverseitig): Dies ist bei weitem die häufigste Ursache. SSH erfordert aus Sicherheitsgründen strenge Berechtigungen für ~/.ssh und ~/.ssh/authorized_keys.
    • ~: Das Home-Verzeichnis des Benutzers darf nicht für alle schreibbar sein (chmod 755 ~ ist normalerweise sicher).
    • ~/.ssh: Muss 700 sein (nur Lese-/Schreib-/Ausführberechtigungen für den Besitzer).
      bash chmod 700 ~/.ssh
    • ~/.ssh/authorized_keys: Muss 600 sein (nur Lese-/Schreibberechtigungen für den Besitzer).
      bash chmod 600 ~/.ssh/authorized_keys
    • Der Besitzer dieser Dateien und Verzeichnisse muss der Benutzer sein, der versucht, sich anzumelden.
      bash sudo chown -R username:username ~/.ssh
  • Falscher Inhalt von authorized_keys: Der öffentliche Schlüssel in ~/.ssh/authorized_keys kann beschädigt sein, zusätzliche Zeichen enthalten oder ein falsches Format haben. Jeder Schlüssel sollte sich in einer einzigen Zeile befinden. Eine schnelle Möglichkeit, das richtige Format sicherzustellen, ist die Verwendung von ssh-copy-id vom Client.
    bash ssh-copy-id -i ~/.ssh/id_rsa.pub username@your_server_ip
    Um den Fingerabdruck Ihres öffentlichen Schlüssels auf der Client-Seite zu überprüfen, verwenden Sie: ssh-keygen -l -f ~/.ssh/id_rsa.pub
  • Client bietet Schlüssel nicht an: Der private Schlüssel befindet sich möglicherweise nicht am Standardspeicherort (~/.ssh/id_rsa), ist nicht im ssh-agent geladen oder Sie haben ihn nicht mit -i angegeben.
    • Lösung: Stellen Sie sicher, dass Ihr privater Schlüssel id_rsa (oder id_ed25519 usw.) in ~/.ssh ist und Berechtigungen von 600 hat. Wenn nicht, geben Sie ihn an:
      bash ssh -i /path/to/your/private_key username@your_server_ip
    • Wenn Sie ssh-agent verwenden, stellen Sie sicher, dass Ihr Schlüssel hinzugefügt wurde:
      bash eval "$(ssh-agent -s)" ssh-add ~/.ssh/your_private_key
  • sshd_config verbietet öffentliche Schlüssel-Authentifizierung: Der SSH-Daemon des Servers ist möglicherweise so konfiguriert, dass die öffentliche Schlüsselauthentifizierung nicht zulässig ist.
    • Überprüfen Sie PubkeyAuthentication yes in /etc/ssh/sshd_config.
    • Überprüfen Sie AuthorizedKeysFile .ssh/authorized_keys, um sicherzustellen, dass sie auf die richtige Datei verweist. Der Standardwert ist normalerweise in Ordnung.
    • Lösung: Setzen Sie PubkeyAuthentication yes und starten Sie sshd neu.
  • SELinux/AppArmor-Interferenz: Auf Systemen mit SELinux oder AppArmor können diese Sicherheitsmodule SSH manchmal daran hindern, auf Benutzer-Home-Verzeichnisse oder .ssh-Dateien zuzugreifen, selbst wenn die Dateiberechtigungen korrekt sind. Überprüfen Sie die Audit-Protokolle (/var/log/audit/audit.log oder sudo ausearch -m AVC -ts recent) auf Hinweise. Dies ist ein fortgeschrittenes Szenario.

3. Verbindung verweigert oder Zeitüberschreitung

Obwohl dies keine reinen "Authentifizierungs"-Fehler sind, gehen sie oft Authentifizierungsversuchen voraus und verhindern, dass diese überhaupt beginnen.

  • Firewall blockiert: Überprüfen Sie Firewalls sowohl auf dem Client (z. B. lokale Betriebssystem-Firewall) als auch auf dem Server (z. B. ufw, firewalld, Cloud-Sicherheitsgruppen, Netzwerk-ACLs). Stellen Sie sicher, dass Port 22 (oder ein benutzerdefinierter Port) geöffnet ist.
  • SSH-Server nicht gestartet: Der sshd-Dienst ist möglicherweise nicht aktiv oder abgestürzt.
  • Falscher Port/IP: Versuch, eine Verbindung zum falschen Port oder zur falschen IP-Adresse herzustellen.

Allgemeine Debugging-Tipps

  • sshd_config prüfen: Überprüfen Sie immer /etc/ssh/sshd_config auf dem Server auf nicht standardmäßige Einstellungen, die stören könnten. Nach Änderungen immer den SSH-Daemon neu starten: sudo systemctl restart sshd (oder sudo service sshd restart).
  • Mit neuem Benutzer/Schlüssel testen: Erstellen Sie, wenn möglich, einen neuen Benutzer und ein neues Paar aus öffentlichem und privatem Schlüssel. Versuchen Sie, sich mit dieser neuen Einrichtung zu authentifizieren. Wenn es funktioniert, ist das Problem spezifisch für die Konfiguration des ursprünglichen Benutzers.
  • Problem isolieren: Versuchen Sie, von einem anderen Client-Computer aus eine Verbindung herzustellen. Wenn es funktioniert, ist das Problem client-spezifisch. Wenn es von mehreren Clients aus fehlschlägt, ist das Problem server-spezifisch.
  • LogLevel erhöhen (Serverseitig): Für tiefgreifende Fehlerbehebung können Sie LogLevel DEBUG vorübergehend in /etc/ssh/sshd_config einstellen und sshd neu starten. Denken Sie daran, diese Einstellung nach der Fehlerbehebung zurückzusetzen, da Debug-Protokolle sehr ausführlich sein und Festplattenspeicher verbrauchen können.

Schlussfolgerung

Die Diagnose von SSH-Authentifizierungsfehlern erfordert einen systematischen Ansatz, der clientseitige ausführliche Ausgaben mit serverseitiger Protokollanalyse kombiniert. Indem Sie sorgfältig die Hinweise von ssh -vvv und den Protokollen des SSH-Daemons (auth.log oder secure) untersuchen, können Sie den genauen Fehlerpunkt ermitteln, sei es ein falsches Passwort, ein falsch konfigurierter öffentlicher Schlüssel, strenge Dateiberechtigungen oder eine serverseitige Einstellung.

Denken Sie daran, mit den einfachen Überprüfungen zu beginnen, dann zur clientseitigen ausführlichen Ausgabe überzugehen und schließlich die definitiven Erkenntnisse aus den Serverprotokollen zu nutzen. Mit diesen Techniken sind Sie gut gerüstet, um selbst die komplexesten SSH-Authentifizierungsprobleme zu lösen und den sicheren Zugriff auf Ihre entfernten Systeme aufrechtzuerhalten.