[Ubuntu 9.10] SSH "loopt vast" / timeout

[swtimmer]

Ik heb het volgende probleem.

Voor als ik vanaf thuis de servers op mijn werk wil bereiken moet ik de ssh connectie over een server heen tunnelen. De volgende code werkt perfect op mijn MacBook maar onder ubuntu lijkt het erop dat de port forwarding na een seconde of 30 ermee ophoudt.

Ik gebruik de volgende code op de tunnels op te starten:
ssh -X -f -N -l swtimmer -L 2223:server1:22 -L 2224:server2:22 -L 3128:www-proxy:3128 -L 2225:pigeon:22 gate.werk.nl

Inloggen op de servers doe ik dan respectievelijk door naar de localhost te connecten met de juiste ssh poort.

Via Google vind ik dat mensen het volgende adviseren. Om de optie 'ConnectTimeout 0' in mijn /etc/ssh/ssh_config aan te zetten. Dit ook gedaan, helaas geen succes.

Ieman hier op tweakers die wel weet wat ik zou moeten aanpassen?

[TwOkkie]

Wat doet "ssh-N -l swtimmer gate.werk.nl" na 30 seconden? Met andere woorden, kan het zijn dat gate.werk.nl je er na 30 seconden uit gooit? Door die -f gebeurt dat op de achtergrond, waardoor je in je shell niet zo gauw ziet of ssh gestopt is. Ik neem tenminste aan dat je dit vanuit een terminal opstart, of doe je het vanaf een Alt-F2 commandoregel?

Als je in plaats van die -f een -v neerzet, zie je op je terminal allerlei debug-informatie voorbij komen. Ook dat kan je op weg helpen. Post desnoods de output hier.

Het zou ook kunnen dat je de KeepAlive-opties van ssh nodig hebt, maar dat uit zich meestal in resets na een kwartier, niet na 30 seconden.

[swtimmer]

Hmm erg vreemd. Heb nu de ssh connectie open zonder -f en hij draait al enkele minuten. Hiervoor heb ik echt in een paar minuten meerdere malen vastgehangen. Even afwachten dus, heb nu de debug output open, ik hoop dan daar wat te zien waarom hij er telkens uit klapte.

Het kan trouwens niet echt de server zijn. MacBook draait vanaf zelfde netwerk en heeft al meerdere dagen de ssh connectie stabiel!

[TwOkkie]

Wat nog aan de hand kan zijn is dat 1 van je forwards nog in gebruik was toen je een eerdere ssh wou stoppen. Het kan dan zijn dat de nieuwe "bind: adress allready in use" of zoiets geeft en op die poort dus geen nieuwe forwards kan laten luisteren.

Overigens kan het best zo zijn dat je 'autossh' boeiend vindt:

Package: autossh                                                          
...
Section: universe/net
...
Description: Automatically restart SSH sessions and tunnels
 autossh is a program to start an instance of ssh and monitor it, restarting it
 as necessary should it die or stop passing traffic. The idea is from rstunnel
 (Reliable SSH Tunnel), but implemented in C. Connection monitoring is done
 using a loop of port forwardings. It backs off on the rate of connection
 attempts when experiencing rapid failures such as connection refused.

[swtimmer]

Ah, zal vanavond eens naar autossh kijken. Ik weet trouwens zeker dat de binds niet bezet zijn. Ik kijk van te voren of die leeg zijn en die errors zie ik anders altijd direct bij het aanmaken van de forward.

Wel raar, met de debug mode aan heeft die het ongeveer 25minuten goed gedaan voordat ik hem killde. Daarna weer met -f gedaan en binnen een minuut hing de verbinding. Erg vreemd!

[TwOkkie]

swtimmer schreef op maandag 15 februari 2010 @ 15:49:
Ah, zal vanavond eens naar autossh kijken. Ik weet trouwens zeker dat de binds niet bezet zijn. Ik kijk van te voren of die leeg zijn en die errors zie ik anders altijd direct bij het aanmaken van de forward.

Ah, maar ik kan van hieruit niet zien hoe handig jij bent. ;-)

Wel raar, met de debug mode aan heeft die het ongeveer 25minuten goed gedaan voordat ik hem killde. Daarna weer met -f gedaan en binnen een minuut hing de verbinding. Erg vreemd!

Maar het ssh-proces draait nog wel op dat moment? En het is een bestaande connectie die vast loopt? Dat is inderdaad vreemd... Hoe vast loopt die precies? Zie je aan beide kanten nog wel een connectie met netstat?

[swtimmer]

Met ps ax | grep ssh zie ik lokaal de verbinding nog wel staat. Dus ik moet hem dan eerst killen voordat ik een nieuwe connectie kan aanmaken (anders krijg ik binds issues).

Hij draait nu met -v en dan blijft het dus doen. Ben even bezig met wat dingen dus kan niet switchen. Ik zal later nog eens naar -f gaan en dan kijken of ik op de server zelf nog wel actief verkeer zie!

Met vastlopen bedoel ik dan ook dat ik dus nog wel lokaal de ssh zie lopen maar dat ik geen nieuwe verbinding eroverheen kan openen. Ook al bestaande verbindingen bevriezen een soort (krijg geen timeouts oid) gewoon dat het terminal vastvriest.

[TwOkkie]

Je kan ook eens met 'netstat -tnlp' kijken welke verbindingen ssh nog open heeft staan en of deze nog luistert op je geforwarde poorten. Mogelijk is ssh "stervende" en bestaat hij alleen nog in afwachting van die laatste verbinding die er nog overheen loopt.

Maar vreemd is het allemaal wel. Waarom zou -f een ander resultaat geven dan zonder -f. Bestaat er onder ubuntu een script dat user-processen killed als ze niet meer aan een terminal gekoppeld zijn? Dat is vziw het enige verschil dat die -f uit maakt. Een 'nohup ssh ...' zou hetzelfde effect moeten geven.

[swtimmer]

Ja ik snap het ook niet helemaal. Maar al meer dan een jaar gebruik van deze manier van port forwarding op mijn MacBook. Sinds afgelopen weekend Ubuntu op een machine gezet om thuis een wat vastere werk plek te hebben (lees hangen op bed / bank met MacBook is niet goed voor je rug).

Een jaar of geleden deed ik trouwens het zelfde op mijn Debian machine (alleen toen naar een andere uni/cluster). Daarvan heb ik zeg maar bovenstaande forwards aan over gehouden. Het lijkt daarom iets intern in Ubuntu te zijn, maar wat :-)


/edit

Hij hangt nu ook met de -v optie, heeft wat langer geduurt, de laatste debug info die ik zie;

debug1: Connection to port 3128 forwarding to www-proxy.ebi.ac.uk port 3128 requested.
debug1: channel 12: new [direct-tcpip]
debug1: Connection to port 3128 forwarding to www-proxy.ebi.ac.uk port 3128 requested.
debug1: channel 14: new [direct-tcpip]
debug1: Connection to port 3128 forwarding to www-proxy.ebi.ac.uk port 3128 requested.
debug1: channel 16: new [direct-tcpip]
debug1: Connection to port 3128 forwarding to www-proxy.ebi.ac.uk port 3128 requested.
debug1: channel 17: new [direct-tcpip]
debug1: Connection to port 3128 forwarding to www-proxy.ebi.ac.uk port 3128 requested.
debug1: channel 18: new [direct-tcpip]
debug1: Connection to port 3128 forwarding to www-proxy.ebi.ac.uk port 3128 requested.
debug1: channel 19: new [direct-tcpip]
debug1: Connection to port 3128 forwarding to www-proxy.ebi.ac.uk port 3128 requested.
debug1: channel 23: new [direct-tcpip]
debug1: Connection to port 2225 forwarding to pigeon.ebi.ac.uk port 22 requested.
debug1: channel 24: new [direct-tcpip]

In de netstat zie ik het volgende

tcp 0 0 127.0.0.1:2223 0.0.0.0:* LISTEN 7238/ssh
tcp 0 0 127.0.0.1:2224 0.0.0.0:* LISTEN 7238/ssh
tcp 0 0 127.0.0.1:2225 0.0.0.0:* LISTEN 7238/ssh

Wat ik nu heb geprobeerd, maar wat niet lukt, is een nieuwe ssh verbinding (zonder forward) op te zetten naar de gate server. Helaas krijg ik daar nu ook geen connectie op. Op de laptop werkt het allemaal nog wel gewoon. Dus de server is up en mijn verbinding daarheen doet het ook gewoon.

Tips? Moet ik wat opzoeken op de remote server via mijn laptop?


/edit2

Ook nu in de debug info:

Read from remote host stargate.ebi.ac.uk: Connection timed out
Transferred: sent 37488, received 259112 bytes, in 12538.9 seconds
Bytes per second: sent 3.0, received 20.7
debug1: Exit status -1

[ Voor 68% gewijzigd door swtimmer op 15-02-2010 19:22 ]

[swtimmer]

Helaas is dit probleem nog steeds. Nu is er 1 ding vreemd aan.

Als ik de SSH laat lopen over een VPN richting mijn werk dan is er geen probleem, dan blijft de verbinding zoals nu de hele dag up. Zonder VPN ligt het eraan hoelang die meegaat.

Hierdoor lijkt het alsof het een soort van binnen het netwerk zit dat mijn SSH verbindingen worden gestopt na een bepaalde tijd/hoeveelheid traffic.

In mijn SSH config heb ik al dit opgenomen:

Host *
ServerAliveCountMax 4
ServerAliveInterval 15

Helaas heeft dat ook geen effect....

De VPN is oplossing, maar niet ideaal. Aangezien de VPN van mijn werk in Duitsland staat en de server waarheen ik probeer te connecten hier gewoon om de hoek in de UK staat vertraagt het mijn internet plezier nogal. Daarnaast vind ik ook een nadeel dat al mijn prive verkeer nu ook via de VPN getunneld wordt, niet dat ik gekke dingen doe maar ik vind persoonlijk het zelf onnodig.

Iemand een tip? Helaas kan ik zelf niet aan de router aanpassen (shared verbinding binnen een huis) of aan de SSH installatie op de server.

[ajvdvegt]

swtimmer schreef op vrijdag 26 maart 2010 @ 21:17:
... Daarnaast vind ik ook een nadeel dat al mijn prive verkeer nu ook via de VPN getunneld wordt, ...

Als je een VPN hebt hoeft niet al je verkeer daar overheen te gaan hoor. Bij ons gaat alleen verkeer voor het interne netwerk over de VPN, de rest gaat direct naar m'n eigen router (Wij gebruiken OpenVPN, er zijn irritante Cisco 'oplossingen' die alles over je VPN dwingen idd).

En een vreemde vraag misschien, maar kan je geen hulp vragen aan systeembeheer? Misschien dat er in de log files aan de server kant iets nuttigs staat?

Of probeer anders eens dropbear (ook apt-gettable), een kleine SSH client/server die eigenlijk voor embedded systemen is bedoeld maar die ook prima werkt op je PC. Het ondersteunt ook port forwarding. Misschien geeft die een andere/duidelijkere foutmelding?

[swtimmer]

ajvdvegt schreef op zondag 28 maart 2010 @ 13:57:
[...]

Als je een VPN hebt hoeft niet al je verkeer daar overheen te gaan hoor. Bij ons gaat alleen verkeer voor het interne netwerk over de VPN, de rest gaat direct naar m'n eigen router (Wij gebruiken OpenVPN, er zijn irritante Cisco 'oplossingen' die alles over je VPN dwingen idd).

En een vreemde vraag misschien, maar kan je geen hulp vragen aan systeembeheer? Misschien dat er in de log files aan de server kant iets nuttigs staat?

Of probeer anders eens dropbear (ook apt-gettable), een kleine SSH client/server die eigenlijk voor embedded systemen is bedoeld maar die ook prima werkt op je PC. Het ondersteunt ook port forwarding. Misschien geeft die een andere/duidelijkere foutmelding?

Tuurlijk kan ik systeem beheer om hulp vragen. Maar het is vrij duidelijk dat het aan mijn machine/verbinding ligt. Heb dit probleem nooit eerder gehad.

De VPN oplossing van mijn werk is van cisco. Ik ging ervanuit dat dan al het verkeer daarover heen zou gaan, maar dit kan ik dus misschien fine tunen per protocol?

[ajvdvegt]

Wat ik van Cisco ken, is dat de server beheerder de client configuratie pusht zodra je de verbinding opzet. 'Onze' beheerder wilde de instelling niet voor ons wijzigen (alle verkeer moest persé over het VPN), zodat alleen een virtuele machine uitkomst bood. Dat is in de meeste gevallen geen handige oplossing.