Längere Zeit hat mich heute folgendes ssh-Problem (eigentlich Routing-Problem) beschäftigt: Ich habe vorübergehend einen Server mit öffentlicher IP in meinem LAN. Jetzt wollte ich diese Maschine testen bevor sie wieder ins RZ zurück kommt, habe meinem Arbeitsrechner die IP des Gateways dieser Maschine gegeben und wollte mich von meinem Arbeitsrechner aus dort einloggen ... und bekam einen Timeout. Im Detail. Ich habe schlicht versucht eine ganz normale ssh-Verbindung aufzubauen:
ssh -v x.x.195.14
[...]
debug1: SSH2_MSG_KEXINIT sent
[längere Zeit vergeht]
Read from socket failed: Connection reset by peer
Erreichbar war der Server x.x.195.14 via ping und ssh hat ja zunächst auch keine Probleme - der Protokoll-String wird ausgetauscht, etc. Nun gut, versuchen wir es auf dem Server lokal:
ssh -v localhost
Aber gleiches Ergebnis: die Verbindung bekommt einen Timeout. Klar, dann muss er openssh-Server defekt oder falsch konfiguriert sein oder sonstwas!?! Nein, auch ein purge/install brachten keine Besserung. (Hey, zum Glück läuft auf dem Server kein Gentoo, sonst hätte mich das neuinstallieren deutlich mehr Nerven gekostet ;-)
Es musste also an etwas anderem liegen. Einiges Suchen im Internet erklärte mir mehr oder weniger im Nebensatz, dass auch ein Routing-Problemen für sowas verantwortlich sein kann. Und ein spontaner Test mit
ifconfig eth0 192.168.100.14
brachte das gewünschte Ergebnis. Woran lag es nun? An der IP selbst nicht, aber am Routing-Eintrag. Ein
route del default gw x.x.195.1
brachte meine Systeme wieder in einen akzeptabelen Zustand. Ob die grundlegende Ursache ein Reverse-Lookup- oder wirklich ein Routing-Problem war (wo immer es genau aufgetreten ist) muss ich noch rausfinden. Aber das Problem ist erstmal gelöst ...
