Server ist über SSH manchmal nicht erreichbar

Zitat von eripek

Wollte ich auch gerade schreiben. ssh -4 sollte Abhilfe schaffen, wenn es das ist.

Ich darf noch einmal folgende Anregung in den Raum stellen. Funktioniert ssh damit zuverlässiger oder nicht?

Zitat von EduLind

Wenn ich den Server mit meinem iPhone, dass im selben Netzwerk wie mein Macbook ist, erreichen will, funktioniert alles wunderbar.

Ein weiteres Argument für ein IPv4/IPv6 Problem.

Damit meinte ich auch, dass der Service über IPv6 verfügbar ist, und nicht über IPv4. Das iPhone bevorzugt IPv6.

Zitat von EduLind

Hey,

Danke für die Antwort.

Produkt: RS 1000 G9.5 a1 12M OS: Debian 11
In den Logs steht nichts auffälliges. Es sieht alles normal aus über das Screen. SSHD Damon ist active und der vom Webserver auch.

Es steht nichts von Verbindungsversuchen oder so dort.

In welchen Logfiles hast du denn geschaut? Eigentlich sollte beim Einloggen per SSH etwas in die /var/log/auth.log eingetrgen werden. Möglicherweise finden die beiden Rechner ja auch keinen für beide akzeptable "key exchange method". MacBook zu alt oder zu neu? Oder zu sicher eingestellt? Das selbe natürlich auch bei deinen Servereinstellungen. Könnte in etwa so aussehen:

Jul 29 18:27:11 xxxxx sshd[3042275]: Unable to negotiate with 45.95.146.103 port 37656: no matching key exchange method found. Their offer: diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 [preauth]

"Connection refused" bedeutet aber, dass die TCP-Verbindung bereits abgewiesen wurde. Die von tab geschilderten Ursachen können da noch gar nicht zutreffen.

Prinzipiell kann man das nur schrittweise analysieren:

• Überprüfe die Firewall am Server und starte auch mal tcpdump, notfalls über die VNC-Konsole. Kommen die SYN-Pakete des Clients überhaupt am Server an?
• Falls nichts am Server ankommt, überprüfe die Firewall am Client. Auch dort mal tcpdump (oder Wireshark) starten und schauen, was genau raus geht bzw. rein kommt.
• Die letzte Station wäre jeder Router dazwischen, auf den Du Zugriff hast. Dort genau das gleiche überprüfen, sofern möglich.

Hmm, stimmt.

Man könnte auch versuchen mit Androhung purer verbosity, ssh zum reden zu bringen.

ssh -vvv …

Zu TCP-Handshake-Problem. Denkbar sind (asynchrone) (protokollabhängige) MTU , (kaputte) ECN, Routingproblem.

Was sagt denn ein tracepath (/-6) oder tracepath6 oder mtr?

Was sagt ein tcptraceroute?

Im SSH Log am Server sollte ein Hinweis sein, warum er die Verbindung "refused" hat.

Zitat von KB19

"Connection refused" bedeutet aber, dass die TCP-Verbindung bereits abgewiesen wurde. Die von tab geschilderten Ursachen können da noch gar nicht zutreffen.

Prinzipiell kann man das nur schrittweise analysieren:

• Überprüfe die Firewall am Server und starte auch mal tcpdump, notfalls über die VNC-Konsole. Kommen die SYN-Pakete des Clients überhaupt am Server an?
• Falls nichts am Server ankommt, überprüfe die Firewall am Client. Auch dort mal tcpdump (oder Wireshark) starten und schauen, was genau raus geht bzw. rein kommt.
• Die letzte Station wäre jeder Router dazwischen, auf den Du Zugriff hast. Dort genau das gleiche überprüfen, sofern möglich.

ich sehe es so, das der SSH Server erreichbar ist, aber den Verbidungsaufbau ablehnt. Ich würde als erstes mal die Logs checken, ob da ein Hinweis ist. Dann die Firewall bzw. Fail2Ban checken.

Meiner Ansicht nach kommt ein "Connection timed out" - wenn der SSH Server überhaupt nicht erreichbar wäre.

Zitat von uwe

Ja, KB19 - das ist schlicht falsch. Ein "connection refused" ist bereits der SSH Server, das bedeutet - die Verbindung bis zum Server funktioniert. Der Server lässt dich aber nicht.

Extra nochmals getestet: Ein "Connection refused" deutet aber oftmals auf eine ICMP-Antwort vom Typ 3 ("Destination Unreachable") hin oder eine RST-Antwort. Beides kann prinzipiell genauso von jedem anderen Hop dazwischen oder sogar dem eigenen Client gesendet werden, das kann muss aber nicht vom Zielsystem kommen. Genaueres würde ein Paketmitschnitt auf Client und Server verraten, deshalb auch der Tipp mit tcpdump/Wireshark.

Dass es nicht an fail2ban liegt, wurde bereits auf der ersten Seite dieses Threads geklärt. Das schließt zwar die restliche Firewall als Fehlerquelle noch nicht aus, aber die Tatsache, dass es mit anderen Geräten im gleichen Netzwerk funktioniert spricht eher dagegen. (Sofern es kein IPv4/IPv6 Problem ist.)

Zitat von EduLind

Das komische ist, sobald ich mich über eine Verbindung mit einen öffentlichen VPN Dienst verbinde, es keine Probleme mit dem Verbindungsaufbau via SSH zum Server gibt.

Was schon wieder auf ein IPv4/IPv6 Problem hindeutet ... denn über einen VPN Dienst hast du kein IPv6.