SSH-Verbindung debuggen: ssh -v und sshd -d

Die Client-Seite: ssh -v

ssh -v user@server

Eine Verbindung durchläuft Phasen in fester Reihenfolge. Suchen Sie die letzte Phase, die in der Ausgabe erscheint, dann wissen Sie, wo das Problem liegt.

1. Konfiguration lesen

debug1: OpenSSH_10.3p1, LibreSSL 3.3.6
debug1: Reading configuration data /Users/you/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config

Das zeigt die Client-Version und die verwendeten Konfigurationsdateien. Zeilen, die einen Host-Block nennen, verraten, welche Blöcke gepasst haben.

2. Verbinden

debug1: Connecting to server [203.0.113.10] port 22.
debug1: Connection established.

Prüfen Sie, ob Adresse und Port Ihren Erwartungen entsprechen. Erreichen Sie nie Connection established, liegt das Problem im Netzwerk oder am Dienst, nicht an Ihrer Anmeldung:

ssh: connect to host 203.0.113.10 port 22: Connection refused

Siehe Connection refused, Connection timed out und Could not resolve hostname.

3. Schlüssel erkennen und den Server kennenlernen

debug1: identity file /Users/you/.ssh/id_ed25519 type 2
debug1: Local version string SSH-2.0-OpenSSH_10.3
debug1: Remote protocol version 2.0, remote software version OpenSSH_10.0p2 Debian-7+deb13u4
debug1: Authenticating to server:22 as 'user'

Prüfen Sie den Benutzernamen in der letzten Zeile. Ein falscher Benutzer wird leicht übersehen und reicht aus, damit die Anmeldung scheitert. identity file ... type -1 bedeutet, dass die Datei nicht gefunden wurde, was bei Schlüsseltypen, die Sie nicht haben, normal ist.

4. Algorithmen aushandeln

debug1: kex: algorithm: mlkem768x25519-sha256
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none

Gibt es keine Übereinstimmung, bricht es hier mit einer Unable to negotiate-Meldung ab. Siehe No matching key exchange.

5. Identität des Servers prüfen

debug1: Server host key: ssh-ed25519 SHA256:c+CTM4jkNvBP8UG87Uh12f2SwOsRapfKmGCO8Yv6tc4
debug1: Host 'server' is known and matches the ED25519 host key.
debug1: Found key in /Users/you/.ssh/known_hosts:1

Passt der Schlüssel nicht, bricht es hier ab. Siehe Host key changed.

6. Anmelden

Hier liegen die meisten Probleme. So sieht ein Fehlschlag aus:

debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Will attempt key: /Users/you/.ssh/id_ed25519 ED25519 SHA256:5WGoVhFgmqkQ/7SmXA0cfMDG6u2weqiLGzzf+uY8hCg explicit
debug1: Offering public key: /Users/you/.ssh/id_ed25519 ED25519 SHA256:5WGoVhFgmqkQ/7SmXA0cfMDG6u2weqiLGzzf+uY8hCg explicit
debug1: Authentications that can continue: publickey,password
debug1: No more authentication methods to try.
user@server: Permission denied (publickey,password).

Und so ein Erfolg:

debug1: Offering public key: /Users/you/.ssh/id_ed25519 ED25519 SHA256:NxFS05Q+k1zf9LgrjGPL94UJfFS6B/89THkWACOEJgg explicit
debug1: Server accepts key: /Users/you/.ssh/id_ed25519 ED25519 SHA256:NxFS05Q+k1zf9LgrjGPL94UJfFS6B/89THkWACOEJgg explicit
Authenticated to server ([203.0.113.10]:22) using "publickey".

Was Sie sehen	Was es bedeutet
Keine Zeile `Offering public key`	Der Client hat keinen Schlüssel zum Ausprobieren gefunden. Prüfen Sie den Pfad oder nutzen Sie `-i`.
Ein anderer Schlüssel als gewollt wird angeboten	Setzen Sie `IdentityFile` und `IdentitiesOnly yes` für diesen Host.
`Offering` ohne `Server accepts key`	Der Server hat diesen Schlüssel nicht akzeptiert. Der Grund steht in seinem Log. Siehe unten.
`Server accepts key`, danach ein Fehler	Der Server mag den Schlüssel, aber der Client konnte nicht signieren, zum Beispiel wegen einer falschen Passphrase.
Bei `Authentications that can continue` fehlt, was Sie wollten	Der Server hat diese Methode abgeschaltet.

Die Lösungen finden Sie unter Permission denied (publickey).

7. Nach der Anmeldung

debug1: Entering interactive session.
debug1: Sending command: true
debug1: Exit status 0

Funktioniert die Anmeldung und die Sitzung schließt sich sofort danach, schauen Sie auf die Shell, die Startdateien oder einen erzwungenen Befehl auf dem Server, nicht auf SSH selbst.

-v, -vv und -vvv

Bei einer einzelnen fehlgeschlagenen Anmeldung gab unser Test mit -v 49 Zeilen aus, mit -vv 95 und mit -vvv 133.

-vv ergänzt die vollständigen Algorithmenlisten beider Seiten, unter local client KEXINIT proposal und peer server KEXINIT proposal. Nutzen Sie es bei Algorithmus-Problemen.
-vvv ergänzt Details auf niedriger Ebene wie debug3: send packet: type 20. Es hilft selten, außer Sie melden einen Bug.

Um die Ausgabe in einer Datei zu behalten oder nur das Wesentliche zu sehen:

ssh -v -E debug.log user@server
ssh -v user@server 2>&1 | grep -E 'Connecting|Offering|accepts|Authenticat|denied'

Die echten Einstellungen sehen: ssh -G

ssh -G server | grep -E '^(user|hostname|port|identityfile|proxyjump) '

Das gibt aus, was der Client nach dem Lesen seiner gesamten Konfiguration verwenden würde, ohne sich zu verbinden. Damit klären sich die meisten Streitfragen, welcher Host-Block gilt. Mit dieser Konfiguration:

Host web*
    User deploy
    Port 2200
    HostName 203.0.113.10
Host *
    User other
    Port 22

liefert ssh -G web1 Folgendes, weil der erste gefundene Wert gewinnt:

user deploy
hostname 203.0.113.10
port 2200

Mehr dazu steht in der Anleitung zur SSH-Konfigurationsdatei.

Ohne Terminal testen: ssh -T

-T fordert kein Terminal an. Das hilft, ein Problem mit der Anmeldung von einem Problem mit der Sitzung zu unterscheiden:

ssh -T user@server 'tty; echo TERM=$TERM'

not a tty
TERM=dumb

Dienste ohne Shell, etwa Git-Hosting, werden normalerweise so getestet: ssh -T git@github.com.

Die Server-Seite

Aus Sicherheitsgründen hört der Client nur Permission denied. Der Grund steht im Log des Servers, lesen Sie also zuerst dieses, wenn Sie anderweitig hineinkommen. Siehe Anmeldeversuche prüfen.

sshd -d auf einem anderen Port

Das startet einen zweiten Server, der eine Verbindung bearbeitet, alles ausgibt und sich beendet. Ihr normaler sshd läuft weiter:

sudo /usr/sbin/sshd -d -p 2200

Dann von Ihrem Rechner aus:

ssh -p 2200 user@server

Eine Firewall muss diesen Port eventuell erlauben. Der vollständige Pfad ist Pflicht: Ohne ihn erscheint sshd requires execution with an absolute path. Hier der wichtige Teil der Ausgabe, wenn authorized_keys den falschen Modus hatte:

debug1: userauth-request for user user service ssh-connection method publickey [preauth]
debug1: trying public key file /home/user/.ssh/authorized_keys
Authentication refused: bad ownership or modes for file /home/user/.ssh/authorized_keys
Failed publickey for user from 203.0.113.10 port 60932 ssh2: ED25519 SHA256:NxFS05Q+k1zf9LgrjGPL94UJfFS6B/89THkWACOEJgg

Und wenn es funktioniert:

debug1: trying public key file /home/user/.ssh/authorized_keys
debug1: /home/user/.ssh/authorized_keys:1: matching key found: ED25519 SHA256:NxFS05Q+k1zf9LgrjGPL94UJfFS6B/89THkWACOEJgg
Accepted key ED25519 SHA256:NxFS05Q+k1zf9LgrjGPL94UJfFS6B/89THkWACOEJgg found at /home/user/.ssh/authorized_keys:1

Für mehr Details nutzen Sie -dd oder -ddd. Beenden Sie ihn mit Strg+C, falls sich niemand verbindet. Taucht Ihre Verbindung in dieser Ausgabe nie auf, hält etwas vor dem Server sie auf, etwa eine Firewall.

sshd -T: die verwendeten Einstellungen

sudo sshd -T | grep -iE '^(port|passwordauthentication|pubkeyauthentication|authorizedkeysfile|permitrootlogin|maxauthtries) '

Das liest die Konfigurationsdateien so wie der Server, einschließlich eingebundener Dateien, und gibt die Ergebnisse aus. Es zeigt die Einstellungen so, wie die Dateien sie definieren, ein noch nicht neu geladener Server nutzt also eventuell ältere Werte. Um die Wirkung von Match-Blöcken zu sehen, beschreiben Sie eine Verbindung:

sudo sshd -T -C user=user,host=client.example.com,addr=203.0.113.10 | grep -i passwordauthentication

Mit sudo sshd -t prüfen Sie nur die Syntax. Wenn alles in Ordnung ist, gibt es nichts aus.

Fragen

Ist es sicher, die Ausgabe von ssh -v zu teilen?

Sie enthält weder Ihre Passwörter noch private Schlüssel, zeigt aber Benutzernamen, Hostnamen, Adressen, Schlüsselpfade und Fingerprints. Lesen Sie sie durch, bevor Sie sie irgendwo öffentlich posten.

Sollte ich immer -vvv verwenden?

Nein. Beginnen Sie mit -v. Das beantwortet die meisten Fragen, die weiteren Stufen liefern meist nur Protokolldetails.

Quellen

Mehr zu Fehlermeldungen

Alle Anleitungen