Como manter confiável um túnel SSH aberto?

Eu uso um túnel SSH do trabalho para percorrer vários firewalls idóticos (tudo bem com meu chefe :)). O problema é que, depois de um tempo, a conexão ssh geralmente trava e o túnel está quebrado.

Se pelo menos eu pudesse monitorar o túnel automaticamente, poderia reiniciar o túnel quando ele travar, mas nem imaginei uma maneira de fazer isso.

Pontos de bônus para quem pode me dizer como impedir que minha conexão ssh seja interrompida, é claro!

Parece que você precisa de autossh . Isso irá monitorar um túnel ssh e reiniciá-lo conforme necessário. Nós o usamos há alguns anos e parece funcionar bem.

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

Mais detalhes sobre o parâmetro -M aqui

Todos os firewalls com monitoração de estado esquecem uma conexão depois de não ver um pacote para essa conexão por algum tempo (para impedir que as tabelas de estado fiquem cheias de conexões nas quais ambas as extremidades morrem sem fechar a conexão). A maioria das implementações de TCP enviará um pacote keepalive após um longo tempo sem ouvir do outro lado (duas horas é um valor comum). Se, no entanto, houver um firewall stateful que se esqueça da conexão antes que os pacotes keepalive possam ser enviados, uma conexão de longa duração, porém inativa, morrerá.

Se for esse o caso, a solução é impedir que a conexão fique inativa. O OpenSSH possui uma opção chamada ServerAliveInterval que pode ser usada para impedir que a conexão fique ociosa por muito tempo (como bônus, ele detectará quando o par morreu mais cedo, mesmo que a conexão esteja ociosa).

Em sua própria máquina mac ou linux, configure seu ssh para manter o servidor ssh ativo a cada 3 minutos. Abra um terminal e acesse seu .ssh invisível em sua casa:

cd ~/.ssh/ 

crie um arquivo de configuração de 1 linha com:

echo "ServerAliveInterval 180" >> config

você também deve adicionar:

ServerAliveCountMax xxxx (high number)

o padrão é 3, para que ServerAliveInterval 180 pare de enviar após 9 minutos (3 do intervalo de 3 minutos especificado por ServerAliveInterval).

Usei o seguinte script do Bash para gerar novos túneis ssh quando o anterior morre. Usar um script é útil quando você não deseja ou não pode instalar pacotes adicionais ou usar o compilador.

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

Observe que isso requer um arquivo de chave para estabelecer a conexão automaticamente, mas esse também é o caso do autossh.

O Systemd é ideal para isso.

Crie um arquivo de serviço /etc/systemd/system/sshtunnel.servicecontendo:

[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

(Modifique o comando ssh para se adequar)

• isso será executado como usuário, sshtunnelportanto, verifique se ele existe primeiro
• problema systemctl enable sshtunnelpara configurá-lo para iniciar no momento da inicialização
• problema systemctl start sshtunnelpara iniciar imediatamente

Atualização em janeiro de 2018 : algumas distros (por exemplo, Fedora 27) podem usar a política do SELinux para impedir o uso do SSH do systemd init; nesse caso, uma política personalizada precisará ser criada para fornecer as isenções necessárias.

Parece-me que todos vocês estão interpretando mal o ServerAliveCountMax. Pelo que entendi os documentos, é o número de mensagens ativas do servidor que podem ficar sem resposta sem que a conexão seja encerrada. Portanto, em casos como o que estamos discutindo aqui, defini-lo como um valor alto garantirá que uma conexão travada não seja detectada e encerrada!

Simplesmente configurar ServerAliveInterval deve ser suficiente para resolver o problema com um firewall esquecendo a conexão, e deixar ServerAliveCountMax baixo permitirá que o final de origem observe a falha e termine se a conexão falhar de qualquer maneira.

O que você deseja é: 1) que a conexão permaneça aberta permanentemente em circunstâncias normais, 2) que a falha na conexão seja detectada e o lado de origem saia na falha e 3) que o comando ssh seja reemitido toda vez saídas (como você faz isso depende muito da plataforma, o script "while true" sugerido por Jawa é uma maneira, no OS XI realmente configuramos um item launchd).

Sempre use a ServerAliveIntervalopção SSH caso os problemas do túnel sejam gerados por sessões NAT expiradas.

Sempre use um método de reaparecimento no caso de a conectividade cair completamente, você tem pelo menos três opções aqui:

• programa de autossh
• bash script ( while true do ssh ...; sleep 5; done) não remove o comando sleep, sshpode falhar rapidamente e você reaparecerá muitos processos

• /etc/inittab, para ter acesso a uma caixa enviada e instalada em outro país, atrás do NAT, sem encaminhamento de porta para a caixa, você pode configurá-lo para criar um túnel ssh para você:

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

• script inicial no Ubuntu, onde /etc/inittabnão está disponível:

  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
  

ou sempre use os dois métodos.

Eu resolvi esse problema com isso:

Editar

~/.ssh/config

E adicione

ServerAliveInterval 15
ServerAliveCountMax 4

De acordo com a página de manual do 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é um bom complemento para as outras sugestões. Se ele se conectar, mas não conseguir estabelecer o encaminhamento de porta, é tão inútil para você quanto se não tivesse se conectado.

Eu tive uma necessidade de manter um túnel SSH a longo prazo. Minha solução estava sendo executada em um servidor Linux e é apenas um pequeno programa C que reaparece o ssh usando autenticação baseada em chave.

Não tenho certeza do enforcamento, mas tive túneis morrendo devido a tempos limite.

Gostaria de fornecer o código para o respawner, mas não consigo encontrá-lo agora.

Embora existam ferramentas como o autossh que ajudam a reiniciar a sessão ssh ... o que eu acho realmente útil é executar o comando 'screen'. Ele permite que você CONTINUE suas sessões ssh mesmo depois de desconectar. Especialmente útil se sua conexão não for tão confiável quanto deveria.

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

... não se esqueça de marcar esta é a resposta 'correta' se ela o ajudar! ;-)

Um pouco de hack, mas eu gosto de usar a tela para manter isso. Atualmente, tenho um encaminhamento remoto que está em execução há semanas.

Exemplo, iniciando localmente:

screen
ssh -R ......

Quando o encaminhamento remoto é aplicado e você possui um shell no computador remoto:

screen
Ctrl + a + d

Agora você tem um encaminhamento remoto ininterrupto. O truque é executar a tela nos dois lados

Recentemente, eu mesmo tive esse problema, porque essas soluções exigem que você digite novamente a senha todas as vezes, se você usar um login de senha, usei o sshpass em um loop junto com um prompt de texto para evitar ter a senha no arquivo em lotes.

Pensei em compartilhar minha solução nesse tópico, caso mais alguém tenha o mesmo problema:

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

Eu tive problemas semelhantes com meu ISP anterior. Para mim, era o mesmo com qualquer conexão TCP, visitando sites ou enviando correio.

A solução foi configurar uma conexão VPN por UDP (eu estava usando o OpenVPN). Essa conexão era mais tolerante com o que causou as desconexões. Em seguida, você pode executar qualquer serviço através dessa conexão.

Ainda pode haver problemas com a conexão, mas, como o túnel será mais tolerante, qualquer sessão ssh sofrerá uma pequena interrupção em vez de ser desconectada.

Para fazer isso, você precisará de um serviço VPN online, que pode ser configurado em seu próprio servidor.

Como autosshnão atende às nossas necessidades (existe com erro se não puder se conectar ao servidor na primeira tentativa), escrevemos um aplicativo bash puro: https://github.com/aktos-io/link- com servidor

Ele cria um túnel reverso para a porta sshd do NODE (22) no servidor por padrão. Se você precisar executar outras ações (como encaminhar portas adicionais, enviar e-mails na conexão, etc ...), poderá colocar seus scripts on-connecte on-disconnectpastas.