O encaminhamento de porta remota SSH falhou

Question

Follow-Up: It looks like the rapid series of disconnects coinciding with a few months of running each server is probably coincidental and just served to reveal the actual problem. The reason it failed to reconnect is almost certainly due to the AliveInterval values (kasperd's answer). Using the ExitOnForwardFailure option should allow the timeout to occur properly before reconnecting, which should solve the problem in most cases. MadHatter's suggestion (the kill script) is probably the best way to make sure that the tunnel can reconnect even if everything else fails.

Eu tenho um servidor (A) atrás de um firewall que inicia um túnel reverso em várias portas para um pequeno VPS DigitalOcean (B) para que eu possa conectar ao endereço IP do A via B. O túnel tem funcionado consistentemente por cerca de 3 meses, mas falhou repentinamente quatro vezes nas últimas 24 horas. A mesma coisa aconteceu um tempo atrás em outro provedor de VPS - meses de operação perfeita, e de repente várias falhas rápidas.

Eu tenho um script na máquina A que executa automaticamente o comando de túnel ( ssh -R *:X:localhost:X address_of_B para cada porta X), mas quando ele é executado, diz Warning: remote port forwarding failed for listen port X .

Entrar no sshd /var/log/secure no servidor mostra esses erros:

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

Resolver requer a reinicialização do VPS. Até lá, todas as tentativas de reconexão geram a mensagem "encaminhamento de porta remota falhou" e não funcionarão. É agora a ponto de o túnel durar cerca de 4 horas antes de parar.

Nada mudou no VPS e é uma máquina de usuário único, de uso único, que serve apenas como o ponto final do túnel reverso. Ele está executando o OpenSSH_5.3p1 no CentOS 6.5. Parece que o sshd não está fechando as portas quando a conexão é perdida. Não sei explicar por que, ou por que isso aconteceria de repente depois de meses de operação quase perfeita.

Para esclarecer, primeiro preciso descobrir por que o sshd se recusa a escutar as portas após o túnel falhar, o que parece ser causado pelo sshd deixando as portas abertas e nunca as fechando. Esse parece ser o principal problema. Eu apenas não tenho certeza do que poderia fazer com que ele se comporte dessa maneira depois de meses se comportando como eu esperava (ou seja, fechando as portas imediatamente e permitindo que o script se reconecte).

    

Answer 1

Concordo com MadHatter, que é provável que sejam encaminhamentos de porta de conexões ssh extintas. Mesmo que o seu problema atual seja outra coisa, você pode esperar entrar em tais conexões ssh mais cedo ou mais tarde.

Existem três maneiras pelas quais essas conexões desativadas podem acontecer:

• Um dos dois pontos de extremidade foi reinicializado enquanto a outra extremidade da conexão estava completamente inativa.
• Um dos dois pontos de extremidade fechou a conexão, mas no momento em que a conexão foi fechada, houve uma interrupção temporária na conexão. A interrupção durou alguns minutos depois que a conexão foi fechada e, portanto, a outra extremidade nunca aprendeu sobre a conexão fechada.
• A conexão ainda é completamente funcional em ambos os pontos de extremidade da conexão ssh, mas alguém colocou um dispositivo com monitoração de estado em algum lugar entre eles, o que atingiu o tempo limite da conexão devido à ociosidade. Este dispositivo stateful seria um NAT ou um firewall, o firewall que você já mencionou é o principal suspeito.

Descobrir qual dos três acima está acontecendo não é muito importante, porque existe um método, que irá abordar todos os três. Esse é o uso de mensagens keepalive.

Você deve pesquisar a palavra-chave ClientAliveInterval para sshd_config e o ServerAliveInterval interval para ssh_config ou ~/.ssh/config .

A execução do comando ssh em um loop pode funcionar bem. É uma boa idéia inserir um sleep no loop, de modo que você não acabe inundando o servidor quando a conexão falhar por algum motivo.

Se o cliente se reconectar antes que a conexão tenha terminado no servidor, você poderá acabar em uma situação em que a nova conexão ssh esteja ativa, mas não tenha nenhum encaminhamento de porta. Para evitar isso, você precisa usar a palavra-chave ExitOnForwardFailure no lado do cliente.

    

Answer 2

Você pode encontrar o processo que vincula a porta nesse servidor com

sudo netstat -apn|grep -w X

Parece muito provável que seja o sshd , mas por que fazer suposições quando você pode ter dados? Também é uma boa maneira de um script encontrar um PID para enviar sinal 9 antes de tentar trazer o túnel novamente.

    

Answer 3

Para mim, quando um túnel ssh é desconectado, leva um tempo para a conexão ser redefinida, de modo que o processo ssh continue bloqueando, deixando-me sem túneis ativos e não sei por quê. Uma solução alternativa é colocar ssh no segundo plano com -f e gerar novas conexões sem esperar que as conexões antigas sejam redefinidas. O -o ExitOnForwardFailure=yes pode ser usado para limitar o número de novos processos. O -o ServerAliveInterval=60 melhora a confiabilidade da sua conexão atual.

Você pode repetir o comando ssh com frequência, digamos, em cron ou, em um loop no seu script, por exemplo, a seguir, executamos o comando ssh a cada 3 minutos:

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

    

Answer 4

Na minha experiência, o ssh tem um hábito um pouco cansativo de não sair corretamente se 'alguma coisa' ainda estiver rodando no sistema remoto. Por exemplo. começou em segundo plano. Você pode reproduzir isso por:

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

Seu ssh será desconectado, mas não fechará a sessão - até que o processo remoto saia (o que não acontecerá, porque é um loop 'while true'). Pode ser algo semelhante está acontecendo - sua sessão tem um processo 'preso' que está sendo gerado pelo ssh. A porta permanece em uso e, portanto, não pode ser reutilizada pelo seu processo local.