Come mantenere affidabile un tunnel SSH aperto?

Uso un tunnel SSH dal lavoro per aggirare vari firewall idotici (va bene con il mio capo :)). Il problema è che dopo un po 'la connessione ssh si blocca e il tunnel si interrompe.

Se potessi almeno monitorare automaticamente il tunnel, potrei riavviare il tunnel quando si blocca, ma non ho nemmeno immaginato un modo per farlo.

Punti bonus per chi può dirmi come impedire che la mia connessione SSH si blocchi, ovviamente!

Sembra che tu abbia bisogno di autossh . Questo monitorerà un tunnel ssh e lo riavvierà secondo necessità. Lo usiamo da un paio d'anni e sembra funzionare bene.

autossh -M 20000 -f -N your_public_server -R 1234:localhost:22 -C

Maggiori dettagli sul parametro -M qui

Tutti i firewall con stato dimenticano una connessione dopo non aver visto un pacchetto per quella connessione per un certo periodo di tempo (per evitare che le tabelle di stato si riempiano di connessioni in cui entrambe le estremità sono morte senza chiudere la connessione). La maggior parte delle implementazioni TCP invierà un pacchetto keepalive dopo molto tempo senza sentire dall'altra parte (2 ore sono un valore comune). Se, tuttavia, esiste un firewall con stato che dimentica la connessione prima che i pacchetti keepalive possano essere inviati, una connessione di lunga durata ma inattiva morirà.

In tal caso, la soluzione è impedire che la connessione diventi inattiva. OpenSSH ha un'opzione chiamata ServerAliveInterval che può essere utilizzata per evitare che la connessione rimanga inattiva per troppo tempo (come bonus, rileverà quando il peer è morto prima anche se la connessione è inattiva).

Sul tuo Mac o Linux, configura il tuo SSH per mantenere in vita il server SSH ogni 3 minuti. Apri un terminale e porta il tuo invisibile .ssh a casa tua:

cd ~/.ssh/ 

quindi crea un file di configurazione a 1 riga con:

echo "ServerAliveInterval 180" >> config

dovresti anche aggiungere:

ServerAliveCountMax xxxx (high number)

il valore predefinito è 3, quindi ServerAliveInterval 180 interromperà l'invio dopo 9 minuti (3 dell'intervallo di 3 minuti specificato da ServerAliveInterval).

Ho usato il seguente script Bash per continuare a generare nuovi tunnel ssh quando il precedente muore. L'uso di uno script è utile quando non si desidera o non è possibile installare pacchetti aggiuntivi o utilizzare il compilatore.

while true
do
  ssh <ssh_options> [user@]hostname
  sleep 15
done

Si noti che ciò richiede un file di chiavi per stabilire automaticamente la connessione, ma è anche il caso dell'autossh.

Systemd è ideale per questo.

Creare un file di servizio /etc/systemd/system/sshtunnel.servicecontenente:

[Unit]
Description=SSH Tunnel
After=network.target

[Service]
Restart=always
RestartSec=20
User=sshtunnel
ExecStart=/bin/ssh -NT -o ServerAliveInterval=60 -L 5900:localhost:5900 user@otherserver

[Install]
WantedBy=multi-user.target

(Modifica il comando ssh per adattarlo)

• questo verrà eseguito come utente, sshtunnelquindi assicurati che l'utente esista per primo
• problema systemctl enable sshtunnelper impostarlo per l'avvio all'avvio
• problema systemctl start sshtunnelper iniziare immediatamente

Aggiornamento gennaio 2018 : alcune distro (ad esempio Fedora 27) possono utilizzare la politica SELinux per impedire l'uso di SSH da systemd init, nel qual caso sarà necessario creare una politica personalizzata per fornire le esenzioni necessarie.

Mi sembra sicuramente che tu stia interpretando male ServerAliveCountMax. A quanto ho capito, è il numero di messaggi attivi del server che possono rimanere senza risposta senza che la connessione venga interrotta. Quindi, in casi come quello di cui stiamo discutendo qui, impostarlo su un valore elevato garantirà semplicemente che una connessione sospesa non venga rilevata e terminata!

La semplice impostazione di ServerAliveInterval dovrebbe essere sufficiente per risolvere il problema con un firewall che dimentica la connessione e lasciare ServerAliveCountMax basso consentirà all'estremità di origine di notare l'errore e terminare se la connessione non riesce comunque.

Ciò che si desidera è 1) che la connessione rimanga aperta in modo permanente in circostanze normali, 2) che la connessione non venga rilevata e che il lato di origine venga chiuso in caso di errore e 3) che il comando ssh venga emesso nuovamente ogni volta che esce (il modo in cui lo fai dipende molto dalla piattaforma, lo script "while true" suggerito da Jawa è un modo, su OS XI in realtà imposta un oggetto launchd).

Utilizzare sempre l' ServerAliveIntervalopzione SSH nel caso in cui i problemi del tunnel siano generati da sessioni NAT scadute.

Usa sempre un metodo di rigenerazione nel caso in cui la connettività scenda completamente, hai almeno tre opzioni qui:

• programma autossh
• bash script ( while true do ssh ...; sleep 5; done) non rimuove il comando sleep, sshpotrebbe fallire rapidamente e rigenererai troppi processi

• /etc/inittab, per avere accesso a un box spedito e installato in un altro paese, dietro NAT, senza port forwarding al box, puoi configurarlo per creare un tunnel ssh di nuovo a te:

  tun1:2345:respawn:/usr/bin/ssh -i /path/to/rsaKey -f -N -o "ServerAliveInterval 180" -R 55002:localhost:22 user@publicip 'sleep 365d'
  

• script upstart su Ubuntu, dove /etc/inittabnon è disponibile:

  start on net-device-up IFACE=eth0
  stop on runlevel [01S6]
  respawn
  respawn limit 180 900
  exec ssh -i /path/to/rsaKey -N -o "ServerAliveInterval 180" -R 55002:localhost:22 user@publicip
  post-stop script
      sleep 5
  end script
  

o usa sempre entrambi i metodi.

Ho risolto questo problema con questo:

modificare

~/.ssh/config

E aggiungi

ServerAliveInterval 15
ServerAliveCountMax 4

Secondo la pagina man di ssh_config:

ServerAliveCountMax
         Sets the number of server alive messages (see below) which may be
         sent without ssh(1) receiving any messages back from the server.
         If this threshold is reached while server alive messages are
         being sent, ssh will disconnect from the server, terminating the
         session.  It is important to note that the use of server alive
         messages is very different from TCPKeepAlive (below).  The server
         alive messages are sent through the encrypted channel and there‐
         fore will not be spoofable.  The TCP keepalive option enabled by
         TCPKeepAlive is spoofable.  The server alive mechanism is valu‐
         able when the client or server depend on knowing when a connec‐
         tion has become inactive.

         The default value is 3.  If, for example, ServerAliveInterval
         (see below) is set to 15 and ServerAliveCountMax is left at the
         default, if the server becomes unresponsive, ssh will disconnect
         after approximately 45 seconds.  This option applies to protocol
         version 2 only.

 ServerAliveInterval
         Sets a timeout interval in seconds after which if no data has
         been received from the server, ssh(1) will send a message through
         the encrypted channel to request a response from the server.  The
         default is 0, indicating that these messages will not be sent to
         the server.  This option applies to protocol version 2 only.

ExitOnForwardFailure yesè una buona aggiunta agli altri suggerimenti. Se si connette ma non è in grado di stabilire il port forwarding, è altrettanto inutile per te come se non fosse stato collegato affatto.

Ho avuto la necessità di mantenere un tunnel SSH a lungo termine. La mia soluzione era in esecuzione da un server Linux, ed è solo un piccolo programma C che rigenera ssh usando l'autenticazione basata su chiave.

Non sono sicuro dell'impiccagione, ma ho fatto morire i tunnel a causa dei timeout.

Mi piacerebbe fornire il codice per il respawner, ma al momento non riesco a trovarlo.

mentre ci sono strumenti come autossh che aiuta a riavviare la sessione ssh ... quello che trovo davvero utile è eseguire il comando 'screen'. Ti permette di RIPRENDERE le tue sessioni ssh anche dopo la disconnessione. Particolarmente utile se la connessione non è affidabile come dovrebbe essere.

• http://www.howtogeek.com/howto/ubuntu/keep-your-ssh-session-running-when-you-disconnect/

... non dimenticare di contrassegnare questa è la risposta "corretta" se ti aiuta k! ;-)

Un po 'di un trucco, ma mi piace usare lo schermo per mantenerlo. Al momento ho un forward remoto che funziona da settimane.

Esempio, iniziando localmente:

screen
ssh -R ......

Quando viene applicato l'inoltro remoto e si dispone di una shell sul computer remoto:

screen
Ctrl + a + d

Ora hai un forward forward senza interruzioni. Il trucco è eseguire lo schermo su entrambe le estremità

Recentemente ho avuto questo problema da solo, perché queste soluzioni richiedono di reinserire la password ogni volta che si utilizza un accesso con password Ho usato sshpass in un ciclo insieme a un prompt di testo per evitare di avere la password nel file batch.

Ho pensato di condividere la mia soluzione su questo thead nel caso in cui qualcun altro avesse lo stesso problema:

#!/bin/bash
read -s -p "Password: " pass
while true
do
    sshpass -p "$pass" ssh user@address -p port
    sleep 1
done

Ho avuto problemi simili con il mio precedente ISP. Per me è stato lo stesso con qualsiasi connessione tcp, visitare siti Web o inviare posta.

La soluzione era configurare una connessione VPN su UDP (stavo usando OpenVPN). Questa connessione era più tollerante a qualunque cosa causasse le disconnessioni. Quindi è possibile eseguire qualsiasi servizio tramite questa connessione.

Possono esserci ancora problemi con la connessione, ma dal momento che il tunnel sarà più tollerante, ogni sessione ssh avvertirà un breve blocco anziché essere disconnessa.

Per fare ciò avrai bisogno di un servizio VPN online che puoi configurare sul tuo server.

Poiché autosshnon soddisfa le nostre esigenze (esiste per errore se non può connettersi al server al primo tentativo), abbiamo scritto un'applicazione bash pura: https://github.com/aktos-io/link- con server

Crea un tunnel inverso per la porta sshd (22) del NODE sul server per impostazione predefinita. Se è necessario eseguire altre azioni (come inoltro di porte aggiuntive, invio di posta sulla connessione, ecc ...) è possibile posizionare script on-connecte on-disconnectcartelle.