Inoltro porta remota SSH non riuscito

Follow-up: sembra che la rapida serie di disconnessioni che coincidono con alcuni mesi di funzionamento di ciascun server sia probabilmente casuale e servita a rivelare il problema reale. Il motivo per cui non è stato possibile riconnettersi è quasi certamente dovuto ai valori AliveInterval (risposta di kasperd). L'uso dell'opzione ExitOnForwardFailure dovrebbe consentire il timeout corretto prima di ricollegarsi, il che dovrebbe risolvere il problema nella maggior parte dei casi. Il suggerimento di MadHatter (il kill script) è probabilmente il modo migliore per assicurarsi che il tunnel possa riconnettersi anche se tutto il resto fallisce.

Ho un server (A) dietro un firewall che avvia un tunnel inverso su più porte verso un piccolo VPS DigitalOcean (B), così posso collegarmi ad A tramite l'indirizzo IP di B. Il tunnel ha funzionato costantemente per circa 3 mesi, ma è improvvisamente fallito quattro volte nelle ultime 24 ore. La stessa cosa è successa un po 'di tempo fa su un altro provider VPS: mesi di funzionamento perfetto, poi improvvisamente molteplici guasti rapidi.

Ho uno script sulla macchina A che esegue automaticamente il comando tunnel ( ssh -R *:X:localhost:X address_of_Bper ogni porta X) ma quando viene eseguito, diceWarning: remote port forwarding failed for listen port X .

Accedere /var/log/securea sshd sul server mostra questi errori:

bind: Address already in use
error: bind: Address already in use
error: channel_setup_fwd_listener: cannot listen to port: X

La risoluzione richiede il riavvio del VPS. Fino ad allora, tutti i tentativi di riconnettersi danno il messaggio "port forwarding remoto fallito" e non funzioneranno. È arrivato al punto in cui il tunnel dura solo circa 4 ore prima di fermarsi.

Non è cambiato nulla sul VPS ed è una macchina monouso e monoutente che funge solo da endpoint del tunnel inverso. Funziona con OpenSSH_5.3p1 su CentOS 6.5. Sembra che sshd non stia chiudendo le porte quando finisce la connessione. Sono in perdita per spiegare perché, o perché sarebbe successo all'improvviso ora dopo mesi di operazioni quasi perfette.

Per chiarire, devo prima capire perché sshd si rifiuta di ascoltare sulle porte dopo il fallimento del tunnel, il che sembra essere causato da sshd che ha lasciato le porte aperte e non le ha mai chiuse. Questo sembra essere il problema principale. Non sono sicuro di cosa potrebbe comportare questo in questo modo dopo mesi di comportamento come mi aspetto (cioè chiudere immediatamente le porte e consentire allo script di riconnettersi).

Concordo con MadHatter che è probabile che si tratti di port forwarding da connessioni ssh defunte. Anche se il tuo attuale problema si rivela essere qualcos'altro, prima o poi puoi aspettarti di imbatterti in connessioni ssh defunte.

Esistono tre modi in cui possono verificarsi connessioni defunte:

• Uno dei due endpoint è stato riavviato mentre l'altra estremità della connessione era completamente inattiva.
• Uno dei due endpoint ha chiuso la connessione, ma nel momento in cui la connessione è stata chiusa, si è verificata un'interruzione temporanea della connessione. L'interruzione è durata alcuni minuti dopo la chiusura della connessione, quindi l'altra estremità non ha mai saputo della connessione chiusa.
• La connessione è ancora completamente funzionale su entrambi gli endpoint della connessione ssh, ma qualcuno ha messo un dispositivo stateful da qualche parte tra loro, che ha scaduto la connessione a causa dell'ozio. Questo dispositivo con stato sarebbe un NAT o un firewall, il firewall che hai già citato è il principale sospettato.

Capire quale dei tre precedenti sta accadendo non è molto importante, perché esiste un metodo che affronterà tutti e tre. Questo è l'uso di messaggi keepalive.

Dovresti cercare la ClientAliveIntervalparola chiave sshd_confige l' ServerAliveIntervalintervallo per ssh_configo ~/.ssh/config.

L'esecuzione del sshcomando in un ciclo può funzionare correttamente. È consigliabile inserire anche una sospensione nel ciclo in modo tale da non finire per inondare il server quando la connessione per qualche motivo non riesce.

Se il client si riconnette prima che la connessione sia terminata sul server, è possibile trovarsi in una situazione in cui la nuova connessione ssh è attiva, ma non ha port forwarding. Per evitarlo, è necessario utilizzare la ExitOnForwardFailureparola chiave sul lato client.

Puoi trovare il processo che sta vincolando la porta su quel server

sudo netstat -apn|grep -w X

Sembra molto probabile che sia il mezzo defunto sshd, ma perché fare ipotesi quando si possono avere dati? È anche un buon modo per uno script di trovare un PID a cui inviare il segnale 9 prima di provare a richiamare nuovamente il tunnel.

Per me quando un sshtunnel si disconnette ci vuole un po 'di tempo per ripristinare la connessione, quindi il sshprocesso continua a bloccarsi lasciandomi senza tunnel attivi e non so perché. Una soluzione alternativa è quella di mettere sshin background -fe generare nuove connessioni senza attendere il ripristino delle vecchie connessioni. La -o ExitOnForwardFailure=yespuò essere utilizzato per limt il numero di nuovi processi. Il -o ServerAliveInterval=60migliora l'affidabilità della connessione corrente.

Puoi ripetere il sshcomando frequentemente, ad esempio, in un cron, o, in un ciclo nel tuo script, ad esempio, nel seguito, eseguiamo il sshcomando ogni 3 minuti:

while (1)
do
    ssh -f user@hostname -Rport:host:hostport -N -o ExitOnForwardFailure=yes -o ServerAliveInterval=60
    sleep 180
done

Nella mia esperienza ssh ha l'abitudine leggermente fastidiosa di non uscire in modo pulito se "qualcosa" è ancora in esecuzione sul sistema remoto. Ad esempio, è iniziato in background. Puoi riprodurlo come segue:

ssh <server>
while true; do  sleep 60; done&
exit

Il tuo ssh si disconnetterà, ma in realtà non chiuderà la sessione - fino a quando il processo remoto non verrà chiuso (cosa che non avverrà, perché è un ciclo 'while true'). Potrebbe succedere qualcosa di simile: la tua sessione ha un processo "bloccato" generato da ssh. La porta rimane in uso e pertanto non può essere riutilizzata dal processo locale.