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. Authentifizierungsfehler sind jedoch eine häufige und oft frustrierende Erfahrung für Systemadministratoren und Entwickler. 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 uns mit systematischen Fehlerbehebungsmethoden befassen und dabei die entscheidende Rolle der detaillierten Client-Ausgabe und der Server-Log-Analyse hervorheben. Wenn Sie verstehen, wie diese diagnostischen Hinweise zu interpretieren sind, sind Sie in der Lage, die Ursache der meisten Authentifizierungsprobleme zu identifizieren und Ihren sicheren Fernzugriff wiederherzustellen.

Grundlegendes zu SSH-Authentifizierungsmethoden

Bevor wir mit der Fehlerbehebung beginnen, ist es wichtig, die primären Authentifizierungsmethoden zu verstehen, die SSH verwendet:

• Passwort-Authentifizierung: Der Benutzer gibt ein Passwort ein, das der Server anhand seiner Benutzerdatenbank oder eines externen Authentifizierungsdienstes (wie PAM) überprüft.
• Public-Key-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 den privaten Schlüssel jemals über das Netzwerk zu senden.

Authentifizierungsfehler können bei beiden Methoden auftreten, aber die Schritte zur Fehlerbehebung unterscheiden sich oft.

Erste Überprüfungen und häufige Fallstricke

Bevor wir uns in detaillierte Logs stürzen, ist es ratsam, einige grundlegende Überprüfungen durchzuführen, da viele Probleme oft einfache Versehen sind:

• Richtiger Benutzername und Hostname: Überprüfen Sie, ob Sie den richtigen Benutzernamen und den genauen Hostnamen oder die IP-Adresse des Zielservers verwenden.
• Netzwerkkonnektivität: Können Sie den Server überhaupt erreichen? Verwenden Sie nc -vz host 22 oder ssh -vvv, um die SSH-Erreichbarkeit zu testen. ping kann helfen, aber viele Server blockieren ICMP, selbst wenn SSH funktioniert.

  ping example.com
  

• SSH-Dienststatus: Läuft der SSH-Server (sshd) tatsächlich auf dem Zielrechner? Wenn Sie Konsolenzugriff haben, überprüfen Sie seinen Status.

  sudo systemctl status sshd # Für systemd-basierte Systeme (die meisten modernen Linux)
  sudo service sshd status    # Für ältere init-Systeme
  

• SSH-Port: Hört der SSH-Daemon auf dem Standardport (22) oder einem benutzerdefinierten Port? Wenn es ein benutzerdefinierter Port ist, müssen Sie ihn mit -p angeben.
• Firewall-Regeln: Gibt es Firewalls (client- oder serverseitig), die Port 22 (oder Ihren benutzerdefinierten SSH-Port) blockieren? Überprüfen Sie Server-Firewalls wie ufw, firewalld oder AWS-Sicherheitsgruppen.

  sudo ufw status
  sudo firewall-cmd --list-all
  

Client-seitige Diagnose: Nutzung des ausführlichen Modus

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

Verwendung von ausführlichen Flags

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

Beispielbefehl:

ssh -vvv benutzername@ihre_server_ip

Interpretation der ausführlichen Ausgabe

Wenn Sie ssh im ausführlichen Modus ausführen, achten Sie auf Schlüsselzeilen, die anzeigen, wo der Authentifizierungsprozess fehlschlägt:

• debug1: Authentications that can continue:: Diese Zeile teilt Ihnen mit, welche Authentifizierungsmethoden der Server akzeptieren möchte. Wenn Ihre gewünschte Methode (z. B. publickey) nicht aufgeführt ist, verhindert die Serverkonfiguration diese.

  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 für die Authentifizierung zu verwenden. Wenn Sie eine Public-Key-Authentifizierung erwarten, diese Zeile aber 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 eine erfolgreiche Public-Key-Authentifizierung aus Sicht des Clients anzeigen. Wenn Sie dies nicht sehen, wurde der Schlüssel wahrscheinlich vom Server abgelehnt.
• debug1: No more authentication methods to try.: Dies erscheint oft kurz vor einem Permission denied-Fehler und bedeutet, dass der Client alle verfügbaren Authentifizierungsmethoden ohne Erfolg ausgeschöpft 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 sofort eine Passwortaufforderung folgt, bedeutet dies oft, dass der Server den öffentlichen Schlüssel abgelehnt hat.

Serverseitige Diagnose: Untersuchung der SSH-Server-Logs

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

Auffinden der SSH-Server-Logs

Der Speicherort der SSH-Server-Logs 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): Sie können auch journalctl verwenden.

Anzeigen und Filtern von Server-Logs

Verwenden Sie Tools wie tail oder journalctl, um Logs 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 (robusteste Methode zum Anzeigen aktueller Logs)
sudo journalctl -u sshd -f

# Zum Anzeigen aller sshd-Logs von Anfang an (nützlich, wenn der Fehler früher aufgetreten ist)
sudo journalctl -u sshd

Häufige Server-Log-Einträge und ihre Bedeutung

Achten Sie auf Nachrichten im Zusammenhang mit sshd, wenn Sie versuchen, eine Verbindung herzustellen. Hier sind einige häufige Einträge, die auf Authentifizierungsfehler hinweisen:

• Failed password for user from IP port ssh2: Zeigt an, dass ein Passwort-Authentifizierungsversuch fehlgeschlagen ist. Dies kann auf ein falsches Passwort zurückzuführen sein oder darauf, dass der Benutzer nicht berechtigt ist, sich über ein Passwort anzumelden.
• Authentication refused: bad ownership or modes for directory /home/user/.ssh: Dies ist ein sehr häufiger Public-Key-Authentifizierungsfehler. 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 Public-Key-Fehler, 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 freizügigen Dateimodi 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 AllowUsers-Direktive in /etc/ssh/sshd_config nicht über SSH anmelden.
• User username from IP not allowed because listed in DenyUsers: Der Benutzer wird durch DenyUsers explizit vom SSH-Zugriff ausgeschlossen.
• input_userauth_request: invalid user username: Der angegebene Benutzername existiert auf dem Server nicht.
• Failed publickey for user oder wiederholt angebotene Schlüssel, gefolgt von einem Passwort: Der vom Client präsentierte öffentliche Schlüssel stimmte mit keinem akzeptierten Schlüssel für diesen Benutzer überein, oder der Server lehnte den Schlüssel aufgrund von Berechtigungen oder Richtlinien ab.
• 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 Szenarien von Authentifizierungsfehlern und Lösungen

Lassen Sie uns häufige Fehler und ihre spezifischen Abhilfemaßnahmen kategorisieren.

1. Fehler bei der Passwort-Authentifizierung

• Falsches Passwort: Das einfachste Problem. Überprüfen Sie Ihr Passwort noch einmal. Achten Sie auf Tastaturlayouts, Feststelltaste oder Num-Taste.
• Benutzer nicht berechtigt: Die Datei sshd_config (/etc/ssh/sshd_config) könnte die Anmeldung für bestimmte Benutzer einschränken.
  • PermitRootLogin no: Verhindert die Root-Anmeldung (aus Sicherheitsgründen sehr empfehlenswert).
  • AllowUsers benutzername1 benutzername2: Nur angegebene Benutzer können sich anmelden.
  • DenyUsers benutzername: Angegebene Benutzer können sich nicht anmelden.
  • AllowGroups gruppenname: Nur Benutzer in angegebenen Gruppen können 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 Passwort-Authentifizierung verhindern. Überprüfen Sie /var/log/auth.log auf PAM-spezifische Fehler. Dies ist bei grundlegenden SSH-Setups weniger üblich.

2. Fehler bei der Public-Key-Authentifizierung

Die Public-Key-Authentifizierung 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 sollte nicht weltweit beschreibbar sein (chmod 755 ~ ist normalerweise sicher).
  • ~/.ssh: Muss 700 sein (rwx nur für den Besitzer).

    chmod 700 ~/.ssh
    

  • ~/.ssh/authorized_keys: Muss 600 sein (rw nur für den Besitzer).

    chmod 600 ~/.ssh/authorized_keys
    

  • Der Besitzer dieser Dateien und Verzeichnisse muss der Benutzer sein, der sich anzumelden versucht.

    sudo chown -R benutzername:benutzername ~/.ssh
    

• Falscher Inhalt von authorized_keys: Der öffentliche Schlüssel in ~/.ssh/authorized_keys könnte beschädigt sein, zusätzliche Zeichen enthalten oder ein falsches Format haben. Jeder Schlüssel sollte in einer einzigen Zeile stehen. Eine schnelle Möglichkeit, das richtige Format sicherzustellen, ist die Verwendung von ssh-copy-id vom Client aus.

  ssh-copy-id -i ~/.ssh/id_rsa.pub benutzername@ihre_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 keinen Schlüssel an: Der private Schlüssel befindet sich möglicherweise nicht am Standardspeicherort (~/.ssh/id_rsa), ist nicht in ssh-agent geladen, oder Sie haben ihn nicht mit -i angegeben.
  • Lösung: Stellen Sie sicher, dass sich Ihr privater Schlüssel als id_rsa (oder id_ed25519 usw.) in ~/.ssh befindet und die Berechtigung 600 hat. Wenn nicht, geben Sie ihn an:

    ssh -i /pfad/zu/ihrem/privaten_schluessel benutzername@ihre_server_ip
    

  • Wenn Sie ssh-agent verwenden, stellen Sie sicher, dass Ihr Schlüssel hinzugefügt ist:

    eval "$(ssh-agent -s)"
    ssh-add ~/.ssh/ihr_privater_schluessel
    

• sshd_config verbietet Public-Key-Auth: Der SSH-Daemon des Servers könnte so konfiguriert sein, dass er die Public-Key-Authentifizierung verbietet.
  • Überprüfen Sie PubkeyAuthentication yes in /etc/ssh/sshd_config.
  • Überprüfen Sie AuthorizedKeysFile .ssh/authorized_keys, um sicherzustellen, dass es 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 manchmal den Zugriff von SSH auf Benutzer-Home-Verzeichnisse oder .ssh-Dateien blockieren, selbst wenn die Dateiberechtigungen korrekt sind. Überprüfen Sie Audit-Logs (/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 es sich nicht streng um "Authentifizierungsfehler" handelt, treten diese oft vor Authentifizierungsversuchen auf und verhindern, dass diese überhaupt beginnen.

• Firewall blockiert: Überprüfen Sie Firewalls sowohl auf dem Client (z. B. lokale OS-Firewall) als auch auf dem Server (z. B. ufw, firewalld, Cloud-Sicherheitsgruppen, Netzwerk-ACLs). Stellen Sie sicher, dass Port 22 (oder der benutzerdefinierte Port) geöffnet ist.
• SSH-Server läuft nicht: 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

• Überprüfen Sie sshd_config: Überprüfen Sie immer /etc/ssh/sshd_config auf dem Server auf nicht standardmäßige Einstellungen, die stören könnten. Starten Sie nach Änderungen immer den SSH-Daemon neu: sudo systemctl restart sshd (oder sudo service sshd restart).
• Testen Sie mit einem neuen Benutzer/Schlüssel: Erstellen Sie nach Möglichkeit einen neuen Benutzer und ein neues Paar aus öffentlichem und privatem Schlüssel. Versuchen Sie, sich mit diesem neuen Setup zu authentifizieren. Wenn es funktioniert, liegt das Problem an der Konfiguration des ursprünglichen Benutzers.
• Isolieren Sie das Problem: Versuchen Sie, von einem anderen Client-Rechner aus eine Verbindung herzustellen. Wenn es funktioniert, liegt das Problem clientseitig vor. Wenn es von mehreren Clients aus fehlschlägt, liegt das Problem serverseitig vor.
• Erhöhen Sie den LogLevel (serverseitig): Für tiefgehendes Debugging können Sie vorübergehend LogLevel DEBUG in /etc/ssh/sshd_config setzen und sshd neu starten. Denken Sie daran, diese Einstellung nach der Fehlerbehebung rückgängig zu machen, da Debug-Logs sehr ausführlich sein und Speicherplatz verbrauchen können.

Fazit

Verwenden Sie ssh -vvv, um zu sehen, was Ihr Client anbietet, und überprüfen Sie dann die Server-Logs, um zu erfahren, warum sshd es abgelehnt hat. Die meisten Public-Key-Fehler lassen sich auf den falschen Schlüssel, einen fehlenden Eintrag in authorized_keys, strenge Dateiberechtigungen oder eine sshd_config-Regel zurückführen, die den Benutzer oder die Methode blockiert.