Dotaz: SSH tunel zustava viset - pri vypadku konektivity

[otasomil]

Dobry den ve spolek. Nejak resim visici tunel skrze SSH ktery obcas (nekdy i nekolikrat tydne) zustane nepruchozi. Na server se pomoci jednoduchyho skriptu pousteneho crontabem ve screenu pripoji RaspberryPi. Skript zde:

#!/bin/bash
while :; do
ssh -o ServerAliveInterval=30 -N -R 5179:raspberry001:8080 user@server.tld -p 15789
sleep 300
done


Crontab zde:


@reboot /bin/sleep 35; /usr/bin/screen -Sdm ssh_tunnel001 /home/pi/httpd/ssh_tunnel.sh

Pokud dojde s vypadku konektivity na nejakou delsi dobu radove minuty tak ssh spadne a po 5 minutach se znova pokusi pripojit jenze pokud je vypadek v radu vterin tak tunel nespadne ale zustane nepruchozi, musim proces s SSH sestrelit aby se zase znova pripojil. Mate nejake tipy co doplnit do parametru -o? Pripadne jak to cele predelat? Na serveru ke kteremu se takto pripojuji nemohu zasahnout do konfigurace takze veskere rady jen pro SSH na strane klienta.

Diky a hodne zdaru vsem preje Otasomil.

---

---

Odpovědi

[NN]

Nepouzivam smycku, ale autossh, nicmene mam podobny problem. Nastesti staci vzdy ustrelit proces na serveru a nechat vzdaleny konec navazat novou session.. a novinka je ze se sice session navaze, ale loopback interface se nevytvori. Podle SSH debug server neobdrzi od klienta pozadavek na port forward:

Sep 21 14:46:27 xxx sshd[20870]: debug1: Entering interactive session for SSH2.
Sep 21 14:46:27 xxx sshd[20870]: debug1: server_init_dispatch_20
Sep 21 14:46:27 xxx sshd[20870]: debug1: server_input_global_request: rtype no-more-sessions@openssh.com want_reply 0
Sep 21 14:47:19 xxx sshd[20855]: debug1: server_input_global_request: rtype keepalive@openssh.com want_reply 1

Misto korektniho:

Sep 20 20:45:17 xxx sshd[14894]: debug1: Entering interactive session for SSH2.
Sep 20 20:45:17 xxx sshd[14894]: debug1: server_init_dispatch_20
Sep 20 20:45:17 xxx sshd[14894]: debug1: server_input_global_request: rtype tcpip-forward want_reply 1
Sep 20 20:45:17 xxx sshd[14894]: debug1: server_input_global_request: tcpip-forward listen localhost port 2006
Sep 20 20:45:17 xxx sshd[14894]: debug1: Local forwarding listening on ::1 port 2006.
Sep 20 20:45:17 xxx sshd[14894]: debug1: channel 0: new [port listener]
Sep 20 20:45:17 xxx sshd[14894]: debug1: Local forwarding listening on 127.0.0.1 port 2006.
Sep 20 20:45:17 xxx sshd[14894]: debug1: channel 1: new [port listener]
Sep 20 20:45:18 xxx sshd[14894]: debug1: server_input_global_request: rtype no-more-sessions@openssh.com want_reply 0
Sep 20 20:45:35 xxx sshd[14781]: debug1: server_input_global_request: rtype keepalive@openssh.com want_reply 1

takz mam ted jeden tunel polomrtvy. Zatim jsem neprisel na to proc Doporucuji LogLevel = DEBUG1 a prostudovat /var/log/auth.log .. duvod vytuhavani session neznam..

[ttt]

Nepomůže ExitOnForwardFailure yes? To by mohlo toho polomrtvého dorazit.

[otasomil]

No prave jaky zadat parametr aby se proces ukoncil a smycka se opakovala. Uz s tim nejaky cas experimentuju. AutoSSH vyzkousim to je zajimave, ma hlidat spojeni a pripadne je restartovat tak uvidim. Tohle je prave beh na dlouhou trat protoze to nejde vyzkouset hned ale nejaky zaver mozno udelat treba po tydnu, mesici provozu.

[otasomil]

No jo to me nenapadlo. jen poustet ssh s parametrem -N. Proste sestrelit spojeni na serveru a pockat az se ve smycce k serveru znova prihlasi . Otazkou zda se proces ukonci i na klientovi. Vyzkousim AutoSSH a ve smycce takze diky za info.

[otasomil]

Tak jsem po vice jak mesici prisel na nasledujici konfiguraci. Nyni vse funguje jak ma a tunel se obnovuje cili nezustava viset jako nepruchozi.

#!/bin/bash
while :; do
sleep 360
autossh -o "ServerAliveInterval 30" -o "ServerAliveCountMax 3" -o "ExitOnForwardFailure yes" -i /home/oton/.ssh/id_rsa -M 0 -N -R 5179:127.0.0.1:8080 uzivatel@server.cz -p 15789
done

[lertimir]

Pro mne je to trochu zvláštní. Mě drží SSH i když zavřu notebook a notebook usne a po probuzení se znovu nahazuje konektivita. Jediné, kdy mě to spadne, když přejdu a změní se IP. (A to je pochopitelné.) Podle toho jak vnímám ssh, tak pokud nespadne klient nebo server a není na žádné straně zadefinováno, aby bylo rozpojeno TCP, když je nějakou dobu v klidu, tak spojení drží. Když si uvědomíme, co je na každé straně, tak na rovině aplikace není známo jestli globálně konektivita je nebo není.

[otasomil]

Diky za info.
Kazdopadne jsem jeste nasadil pouhe ssh viz skript pro vytvoreni SOCKS proxy a uvidim co ukaze cas.

#!/bin/bash
while :; do
ssh -o "ExitOnForwardFailure yes" -N -D9812 uzivatel@server.cz -p 27422
sleep 300
done

To co pisete jak se Vam spojeni obnovi i pri probuzeni notebooku, obnove konektivity... tak to je skoro jako u mosh kde navic nevadi ani zmena IP adresy. Skoda jen ze mosh neumi tunely. No ale mozna to nejde z principu.