[Debian] Reverse shell middels autossh valt soms weg

[schnitzelcore]

Dit is een netwerkprobleem, maar ik denk dat de oplossing te vinden is met wat (meer) kennis (dan ik heb) van initscripts. Daarom (en omdat de term autossh nul resultaten levert in de search en ik bij networking dus zeer waarschijnlijk niet meer expertise hieromtrent ga vinden) zet ik mijn vraag hier.
Ik heb een machine, Theo, die achter een NAT router zit. Deze router is van een sukkel (ik kan het niet anders zeggen) die geen poort kan forwarden voor me. Om de machine toch bereikbaar te laten zijn laat ik Theo met autossh een reverse shell verbinding maken naar een wel bereikbare machine (Linda). De boel is zo opgezet dat deze verbinding opgezet kan worden zonder dat er een wachtwoord hoeft te worden ingevoerd.

code:

autossh -M 0 -oServerAliveInterval=15 -oSetupTimeOut=15 -q -f -NR 3333:localhost:22 mijnlogin@linda

Ik log vervolgens zelf in op Linda en doe dan:

code:

ssh localhost -p 3333

Ik kan dus via Linda inloggen op Theo. Ok. Als de reverse shell verbinding wegvalt zorgt autossh dat deze weer herstelt wordt. Als ik Linda reboot gebeurt dit idd ook.
Het probleem is alleen dat het netwerk waar Linda aan hangt (met dank aan de firma Casema) met grote regelmaat 'problemen' heeft. Na zo'n storing wil de reverse shell ondanks autossh weleens onbereikbaar worden. Ik heb diverse instellingen van autossh geprobeerd (met name met en zonder monitor-poort), dit bood geen soelaas.
Wanneer de verbinding is weggevallen en ik reboot Linda is deze hierna meteen terug. Dit is alleen niet een ideale oplossing: Linda staat altijd aan en dat is niet voor niets zo. Ik heb dingen geprobeerd als:

code:

ifdown eth0; sleep 30; ifup eth0
/etc/init.d/ssh stop; sleep 30; /etc/init.d/ssh start

Hiermee krijg ik mijn autossh verbinding echter niet terug! Ook valt me op dat zelfs de ssh daemon stoppen niet genoeg is om de verbinding die ik dan zelf naar Linda heb weg te laten vallen. Wat ik niet helemaal begrijp, maar dat terzijde.
Ook is er na een storing op Linda geen ssh proces te zien dat ik kan killen om autossh te forceren opnieuw te verbinden. Wanneer de verbinding er wel is en ik kill het juiste proces zie ik dat er meteen een nieuwe verbinding wordt gemaakt.

Kent iemand een manier 'short of' rebooten die ik kan gebruiken om alle ssh clients te schoppen (ook die zich in limbo bevinden) zodat autossh opnieuw verbinding maakt?

[deadinspace]

schnitzelcore schreef op dinsdag 05 februari 2008 @ 04:10:
De boel is zo opgezet dat deze verbinding opgezet kan worden zonder dat er een wachtwoord hoeft te worden ingevoerd.

Hoe? Door middel van Theo's public key in ~/.ssh/authorized_keys op Linda?

code:

autossh -M 0 -oServerAliveInterval=15 -oSetupTimeOut=15 -q -f -NR 3333:localhost:22 mijnlogin@linda

Je laat autossh backgrounden en geeft -q mee aan ssh. Maar misschien heeft (auto)ssh juist wat zinnigs te melden op het moment dat het misgaat. Je zou dus eens kunnen proberen ssh juist op verbose te zetten en de output op te vangen.

Als de reverse shell verbinding wegvalt zorgt autossh dat deze weer herstelt wordt. Als ik Linda reboot gebeurt dit idd ook.
Het probleem is alleen dat het netwerk waar Linda aan hangt (met dank aan de firma Casema) met grote regelmaat 'problemen' heeft. Na zo'n storing wil de reverse shell ondanks autossh weleens onbereikbaar worden.

Zou het kunnen dat Linda na zo'n storing via DHCP een ander IP-adres krijgt van Casema? Zo ja, hoe laat je Theo ssh'en naar Linda? Naar een hostname die geupdate wordt?

Als na zo'n storing die ssh tunnel niet meer werkt, hoe lang wacht je dan tot je besloten hebt dat het niet meer werkt en je Linda reboot? 5 minuten? Een dag?

Ik heb dingen geprobeerd als:

code:

ifdown eth0; sleep 30; ifup eth0
/etc/init.d/ssh stop; sleep 30; /etc/init.d/ssh start

Hiermee krijg ik mijn autossh verbinding echter niet terug! Ook valt me op dat zelfs de ssh daemon stoppen niet genoeg is om de verbinding die ik dan zelf naar Linda heb weg te laten vallen. Wat ik niet helemaal begrijp, maar dat terzijde.

Dat laatste komt omdat established ssh connecties een eigen sshd process hebben. Als je /etc/init.d/ssh stop doet, dan wordt alleen het sshd master process (die nieuwe connecties ontvangt) afgesloten, sshd processen voor bestaande connecties blijven open (Dat is wel zo handig trouwens als je bijvoorbeeld sshd herstart na de config aangepast te hebben).

Je kan met ps auxf kijken welke sshd voor de verbinding vanaf Theo is, en die handmatig de nek omdraaien met kill. Maar...

Ook is er na een storing op Linda geen ssh proces te zien dat ik kan killen om autossh te forceren opnieuw te verbinden.

Die is er blijkbaar al niet meer.

Kun je na zo'n storing iets van verbindingen naar Theo ontdekken met bijvoorbeeld

# netstat -nlp

? (voor het beste effect als root draaien)

[Verwijderd]

Wat ik altijd merk is dat als ik een machine waarnaartoe ik SSH reboot, is dat de sessie blijft 'hangen' tot de sshd op de remote machine weer in de lucht komt. Op dat moment krijgt deze de TCP/22 pakketjes binnen voor de oude sessie en stuurt een TCP reset terug. Zou het mogelijk kunnen zijn dat omdat je TCP/IP stack deze oude verbinding nog laat staan, er geen reset gestuurd wordt? (Sowieso zal het restarten van je sshd oude verbindingen niet opruimen, die blijven gewoon staan). Check eens met 'netstat -an' of er nog een oude verbinding staat... Als dat zo is, zou je door je ssh daemon down te brengen en dan te wachten tot deze verbinding volledige uitgetimed is (dat kan wel een half uur duren!). Als dat het probleem verhelpt, kun je daarna gaan kijken naar een methode om dit te versnellen. Check ook eens met ps -ef of er nog een oude child van de oude ssh verbinding staat...

[schnitzelcore]

@deadinspace:

- Authorisatie gebeurt inderdaad via public key.
- Output opvangen is een goed idee. Wanneer ik hier resultaten van heb zal ik het melden. De storingen komen soms dagelijks voor, maar soms ook weer dagen achter elkaar niet.
- Linda heeft een dyndns hostname, die ik idd gebruik. Het ip van Linda is tot nu toe echter altijd hetzelfde gebleven.
- Wanneer ik de reverse shell probeer te gebruiken en het lukt niet heb ik tot nu toe denk ik maximaal een uur gewacht. Ik heb nog een machine die altijd aan staat en aan hetzelfde netwerk hangt. Dit netwerk is een 100Mb net op een studentencampus, dat helaas dus beheerd wordt door Casema. Die andere machine draait oa emule. Ik kan in de logs zien wanneer er een storing is geweest.
De storingen de laatste tijd worden nl meestal veroorzaakt door een virus dat ARP spoofing gebruikt om de besmette machine als gateway te laten fungeren. Wanneer je dit met je gemiddelde studentenlaptopje probeert te doen op een snel netwerk met een paar duizend aansluitingen gaat dat natuurlijk vrij snel mis. De logs van bv emule of mijn quake server laten duidelijk zien wanneer dit gebeurt.
Lang verhaal kort: ook uren na zo'n storing is de autossh verbinding niet hersteld.
- Ook netstat zal ik proberen na de volgende storing. Bedankt voor de uitleg en de tips!

@jeroenr:
- Volgens mij zie ik als de reverse shell onbereikbaar is geworden geen enkel proces meer dat daar bij hoort...