Por que as sessões SSH inativas terminam com “Falha na gravação: cano quebrado”?

Question

Eu sei que este é um problema comum com uma solução conhecida. Uma pesquisa rápida na Web exibe muitos resultados que apontam para as opções de configuração ServerAliveInterval (ou menos comumente do lado do servidor ClientAliveInterval ). Definir um desses para algum valor arbitrário, como 15, 60 ou 120, resolverá o problema do cano quebrado.

Minha pergunta é por que ? Por que isso acontece em primeiro lugar? Quem está fechando a tomada?

Eu tenho minhas dúvidas sobre o sistema operacional matando a conexão devido à inatividade, dado o fato de que a opção TCPKeepAlive está habilitada por padrão, o que faz com que as mensagens keepalive do TCP sejam enviadas para detectar a queda de clientes off-line. Portanto, o sistema operacional não verá a conexão como inativa de qualquer maneira.

Nesse caso, é o próprio sshd que está expirando? E se sim, por que o tempo limite não é documentado ou configurável? E se os keepalives no nível do aplicativo forem necessários para manter as conexões SSH abertas, por que eles não estão habilitados por padrão?

Estas perguntas são invariavelmente esquecidas sempre que esta questão aparece em fóruns de discussão. Alguém pode lançar alguma luz sobre isso?

    

Answer 1

O próprio SSH é um protocolo antigo e não foi originalmente projetado para o mundo orientado para dispositivos móveis em que vivemos hoje. Se houver uma interrupção na conexão entre o servidor e o cliente, ele não se recuperará muito bem, portanto, se você estiver em uma conexão duvidosa, não seria uma grande surpresa se houvesse um cano quebrado. Isso também é parcialmente devido ao fato de que o SSH é completamente dependente do TCP, que possui várias limitações nessa área.

De qualquer forma, se você precisar de algo mais robusto para essas conexões, recomendo mosh. É super fácil de configurar e você não deve ter nenhum problema com a desconexão. Na verdade, você pode até mesmo mudar os endereços IP e ele vai pegar de volta onde você estava sem tanto quanto um soluço. Mosh usa o UDP, que é o que permite esse comportamento.

Quanto ao funcionamento, ele usa o SSH para estabelecer uma conexão com o servidor, em que ele executa mosh-server . O programa, em seguida, escuta em uma porta UDP (cerca de 60000 por padrão), para o cliente se conectar com mosh-client . Isso significa que a única configuração que você precisa fazer é um simples redirecionamento de porta.

Espero que isso ajude.

    

Answer 2

Who is closing the socket?

Ninguém está fechando o "socket", ou seja, nem cliente nem servidor. O problema de conexão geralmente é causado por um filtro de pacotes com estado entre as partes da comunicação. Esses filtros de pacotes são usados em firewalls e também nos simples roteadores SoHo, onde são necessários para lidar com os estados para NAT , que é a maneira típica de fornecer acesso à Internet a vários sistemas internos por trás do mesmo endereço IP externo.

Esses filtros de pacotes com estado criam um estado para cada nova conexão e a derrubam no fechamento da conexão. Isso significa pacotes SYN / FIN com conexões TCP como ssh. Esses estados ocupam memória para que um filtro de pacotes possa suportar apenas um número limitado de estados ao mesmo tempo. Portanto, ele removerá esses estados após algum tempo de inatividade (ou seja, nenhum pacote para essa conexão).

Se não houver atividade dentro de uma conexão TCP, nenhum pacote será enviado. Isso também é verdade para o SSH. Após algum tempo de inatividade, o estado no filtro de pacotes será removido. Se qualquer parte da conexão enviar mais pacotes após a inatividade, não haverá estado no filtro de pacotes e um pacote RST será emitido. Isso resulta no "Broken Pipe".

A opção TCPKeepAlive no SSH ativa a opção TCP keepalive, que faz com que a camada TCP envie regularmente pacotes vazios (ou seja, pacote TCP sem carga de dados) em períodos de inatividade. Desta forma, o filtro de pacotes mantém o estado aberto.