O garfo SSH mata a conexão

Question

Estou usando um script Linux que tem a tarefa de encaminhar o controle do sistema para o suporte remoto. Nesse script, um dos comandos é um comando de encaminhamento de porta ssh que encaminhará a porta do fluxo de vídeo ao vivo de uma câmera remota. No sistema com a câmera remota, esse sistema é um desconhecido e, portanto, assumido sempre por trás de um firewall e também tem um usuário que não tem o conhecimento de porta encaminhar seu roteador e também adquirir um DNS dinâmico. Para superar isso, o sistema "CLIENT" ou o computador da câmera executa o comando abaixo:

ssh -R 8089:dc-bb7925e7:8085 -p 2250 [email protected] -fNT

que está encaminhando a porta CLIENT para a alimentação da câmera 8085 para o servidor de suporte remoto 8089. O suporte remoto deve poder ir para localhost: 8089 e poder visualizar a transmissão ao vivo. O problema é que isso não funciona. Depois de inserir o sinalizador -f no comando, este comando quebra e encaminha nada.

Independentemente do sinalizador, o problema é que, quando este comando ssh é executado, todos os outros scripts e processos que deveriam estar em execução ficam em espera por causa do TTY, que não permite que o script saia até que a conexão seja finalizada. quebrado. Então eu tentei usar o -f para bifurcar o ssh no plano de fundo. Isso não funciona porque a porta não é encaminhada. Eu não consigo descobrir o porquê.

O que eu preciso é que a porta seja encaminhada e depois esquecida enquanto a conexão permanece aberta. É importante que o suporte remoto tenha controle sobre o ssh enquanto o sistema cliente ainda opera normalmente. O que estou fazendo errado?

Se não usar o -fNT, então isso funciona normalmente, somente todos os outros scripts não são executados.

Este é um sistema Debian.

    

Answer 1

Não acredito que o -f esteja causando o seu problema. Eu não vejo nada de errado em seu comando, dadas as circunstâncias certas, seu comando funcionaria muito bem.

No entanto, se houver alguma middlebox com estado no caminho entre o cliente ssh e o servidor ssh, se a middlebox perder o estado, sua conexão ssh irá morrer ou parar. Isso significa que você precisa tomar cuidado extra, se houver um NAT ou um firewall no caminho.

As mensagens de keepalive podem impedir que a conexão morra devido a um tempo limite. Eles não impedirão que a conexão morra devido a outros motivos, como a reinicialização de uma middlebox, mas, nesses casos, uma manutenção de atividade pode detectar que isso aconteceu e garantir que a conexão morra imediatamente, em vez de travar.

No cliente, você pode usar -o ServerAliveInterval=299 ou algo semelhante para enviar keepalives e garantir que o comando ssh seja encerrado em breve, caso a conexão pare. Envolvendo isso em um script de shell de looping, você pode garantir que ele continuará abrindo uma nova conexão ssh toda vez que a conexão anterior morrer (mas obviamente isso exigiria que o script bifurse em vez do comando ssh).

Se você quisesse manter um encaminhamento de porta aberto com -L vivo, então ServerAliveInterval e respawning o comando ssh seriam suficientes. Mas com -R há outra coisa, que pode dar errado.

Se alguma coisa já estiver escutando na porta no servidor, então -R falhará ao configurar um encaminhamento de porta, mas o comando ssh continuará sendo executado de qualquer maneira. Assim, um loop destinado a reaparecer o comando ssh não seria bom nesse caso.

A correção para isso é passar -o ExitOnForwardFailure=yes para o comando ssh. Obviamente, se você acabou de iniciar o ssh em um loop com essa combinação de sinalizadores, ele poderia tentar várias vezes seguidas vincular a mesma porta ocupada. Então, um sono entre tentativas sucessivas seria uma boa ideia. Cada vez que o comando ssh morre, seu script deve simplesmente dormir por alguns segundos antes de tentar novamente.

Eu ficaria surpreso se já não existissem vários scripts que fazem tudo o que descrevi acima.

O que eu mencionei até agora não abrange tudo o que você precisa.

Se a conexão parar e o cliente perceber e tentar reaparecer o comando ssh, o servidor talvez ainda não tenha percebido, portanto, a porta ainda pode estar ocupada no lado do servidor. Caso alguém tenha configurado um firewall de forma estúpida, esse problema pode persistir indefinidamente com o script no cliente tentando repetidamente vincular a uma porta, que permanece bloqueada.

Como é improvável que todos consigam consertar suas configurações de firewall, é melhor evitar esse problema com um ajuste em sshd_config , a configuração ClientAliveInterval pode ser usada para fazer com que o servidor envie mensagens de manutenção de atividade para o cliente e feche a conexão se ela não receber uma resposta.

A combinação de todos os itens acima deve ser suficiente para manter o encaminhamento de porta ativo o tempo todo (supondo que haja conectividade de rede entre o cliente e o servidor).