Seguir:Parece que a rápida série de desconexões que coincide com alguns meses de funcionamento de cada servidor é provavelmente uma coincidência e serviu apenas para revelar o problema real. A razão pela qual não foi possível reconectar é quase certamente devido aos valores AliveInterval (resposta de Kasperd). O uso da opção ExitOnForwardFailure deve permitir que o tempo limite ocorra corretamente antes da reconexão, o que deve resolver o problema na maioria dos casos. A sugestão do MadHatter (o script kill) é provavelmente a melhor maneira de garantir que o túnel possa se reconectar mesmo se todo o resto falhar.
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 me conectar a A através do endereço IP de B. O túnel tem funcionado de forma consistente há cerca de 3 meses, mas falhou repentinamente quatro vezes nas últimas 24 horas. A mesma coisa aconteceu há algum tempo 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_Bpara cada porta X), mas quando é executado, diz Warning: remote port forwarding failed for listen port X.
Entrar no sshd /var/log/secureno servidor mostra estes erros:
bind: Address already in use
error: bind: Address already in use
error: channel_setup_fwd_listener: cannot listen to port: X
A solução requer a reinicialização do VPS. Até então, todas as tentativas de reconectar exibirão a mensagem "falha no encaminhamento de porta remota" e não funcionarão. Chegou agora ao ponto em que o túnel dura apenas cerca de 4 horas antes de parar.
Nada mudou no VPS, e é uma máquina de uso único e de usuário único que serve apenas como ponto final do túnel reverso. Está executando OpenSSH_5.3p1 no CentOS 6.5. Parece que o sshd não está fechando as portas quando a conexão é perdida. Não consigo explicar por que, ou por que isso aconteceria repentinamente agora, 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 a falha do túnel, o que parece ser causado pelo sshd deixar as portas abertas e nunca fechá-las. Esse parece ser o principal problema. Só não tenho certeza do que faria com que ele se comportasse dessa maneira depois de meses se comportando como esperado (ou seja, fechando as portas imediatamente e permitindo que o script se reconectasse).
Responder1
Concordo com MadHatter, que é provável que sejam encaminhamentos de porta de conexões ssh extintas. Mesmo que o seu problema atual seja outro, você pode esperar encontrar essas conexões ssh extintas mais cedo ou mais tarde.
Existem três maneiras pelas quais essas conexões extintas podem acontecer:
- Um dos dois endpoints foi reinicializado enquanto a outra extremidade da conexão estava completamente inativa.
- Um dos dois endpoints fechou a conexão, mas no momento em que a conexão foi encerrada, houve uma interrupção temporária na conexão. A interrupção durou alguns minutos após o fechamento da conexão e, portanto, a outra extremidade nunca soube do fechamento da conexão.
- A conexão ainda está completamente funcional em ambos os pontos finais da conexão ssh, mas alguém colocou um dispositivo com estado em algum lugar entre eles, o que expirou a conexão devido à inatividade. Este dispositivo com estado 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 abordará todos os três. Esse é o uso de mensagens keepalive.
Você deve examinar a ClientAliveIntervalpalavra-chave for sshd_confige o ServerAliveIntervalintervalo de ssh_configor ~/.ssh/config.
Executar o sshcomando em loop pode funcionar bem. É uma boa ideia inserir também um sleep no loop, para que você não acabe inundando o servidor quando a conexão falhar por algum motivo.
Se o cliente se reconectar antes de a conexão terminar no servidor, você poderá acabar em uma situação em que a nova conexão ssh está ativa, mas não tem encaminhamento de porta. Para evitar isso, você precisa usar a ExitOnForwardFailurepalavra-chave do lado do cliente.
Responder2
Para mim, quando um sshtúnel é desconectado, demora um pouco para a conexão ser reiniciada, então o sshprocesso continua bloqueado, deixando-me sem túneis ativos e não sei por quê. Uma solução alternativa é colocar sshem segundo plano -fe gerar novas conexões sem esperar que as conexões antigas sejam redefinidas. O -o ExitOnForwardFailure=yespode ser usado para limitar o número de novos processos. Isso -o ServerAliveInterval=60melhora a confiabilidade de sua conexão atual.
Você pode repetir o sshcomando com frequência, digamos, em um cronou em um loop em seu script, por exemplo, a seguir, executamos o sshcomando a cada 3 minutos:
while (1)
do
ssh -f user@hostname -Rport:host:hostport -N -o ExitOnForwardFailure=yes -o ServerAliveInterval=60
sleep 180
done
Responder3
Você pode encontrar o processo que vincula a porta desse servidor com
sudo netstat -apn|grep -w X
Parece muito provável que seja meio extinto sshd, mas por que fazer suposições quando você pode ter dados? Também é uma boa maneira para um script encontrar um PID para enviar o sinal 9 antes de tentar abrir o túnel novamente.
Responder4
Na minha experiência, o ssh tem o hábito um pouco cansativo de não sair corretamente se 'algo' ainda estiver em execução 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 na verdade não fechará a sessão - até que o processo remoto termine (o que não acontecerá, porque é um loop 'while true'). Pode ser que algo semelhante esteja acontecendo - sua sessão tem um processo 'travado' que está sendo gerado pelo ssh. A porta permanece em uso e, portanto, não pode ser reutilizada pelo seu processo local.