Ein besonders interessanter Fehler: Ein Server war per HTTP erreichbar, aber SSH auf Port 22 lief zeitweise in Timeouts. Wichtig war die Unterscheidung: Permission denied ist nicht dasselbe wie Timeout.Wenn SSH mit „Permission denied“ antwortet, ist der Dienst erreichbar und die Authentifizierung scheitert. Wenn aber schon TCP/22 timeouts liefert, liegt das Problem vorher: Netzwerkpfad, Firewall, VLAN, SSHD-Annahme, halboffene Verbindungen oder Rate-Limits.
In diesem Fall zeigte sich: Viele kurze Agent-SSH-Verbindungen können eigene alte Sessions hinterlassen oder SSHD kurzfristig belasten. Eine interaktive SSH-Session des Benutzers kann dabei weiter funktionieren, während neue Kurzverbindungen hängen.
Sinnvolle Prüfungen sind `sshd -T`, Prozesse mit `ps`, offene Port-22-Verbindungen mit `ss -tanp` und SSH-Journal-Logs. Wenn möglich, hilft während eines Timeouts tcpdump direkt auf dem Zielsystem.
Fazit: Bei SSH-Problemen immer die Schichten trennen: TCP-Erreichbarkeit, SSHD-Annahme, Authentifizierung und sudo/Rechte. Ein Timeout ist kein Benutzerproblem.