Isenção de responsabilidade

Question 1

Você poderia usar mosh:https://mosh.org/

Você pode configurar um servidor 'jump' com uma conexão confiável à Internet que você usa moshpara se conectar e, em seguida, ter sshsessões em cada servidor que você gerencia. A razão pela qual sugiro usar um servidor jump é que você pode não querer instalar moshnos servidores que está gerenciando.

Outra vantagem moshé que ele é baseado em UDP e não em TCP, e sua sessão pode sobreviver a uma mudança de endereço IP, por exemplo, passando de WiFi para uma conexão de internet móvel.

Só para deixar claro, moshnão é um substituto para screen, mas sim ssh. Ainda é uma boa ideia usá screen-lo, já que moshele não oferece uma maneira de se reconectar à sua sessão se o cliente morrer por algum motivo.

Answer

Você poderia usar mosh:https://mosh.org/

Você pode configurar um servidor 'jump' com uma conexão confiável à Internet que você usa moshpara se conectar e, em seguida, ter sshsessões em cada servidor que você gerencia. A razão pela qual sugiro usar um servidor jump é que você pode não querer instalar moshnos servidores que está gerenciando.

Outra vantagem moshé que ele é baseado em UDP e não em TCP, e sua sessão pode sobreviver a uma mudança de endereço IP, por exemplo, passando de WiFi para uma conexão de internet móvel.

Só para deixar claro, moshnão é um substituto para screen, mas sim ssh. Ainda é uma boa ideia usá screen-lo, já que moshele não oferece uma maneira de se reconectar à sua sessão se o cliente morrer por algum motivo.

Question 2

Use as opções do ssh ServerAlivepara detectar quando a conexão falhou.

ServerAliveCountMax
Define o número de mensagens ativas do servidor (veja abaixo) que podem ser enviadas sem que o ssh(1) receba nenhuma mensagem de volta do servidor. Se esse limite for atingido enquanto as mensagens ativas do servidor estiverem sendo enviadas, o ssh se desconectará do servidor, encerrando a sessão. É importante observar que o uso de mensagens de servidor ativo é muito diferente do TCPKeepAlive (abaixo). As mensagens ativas do servidor são enviadas através do canal criptografado e, portanto, não serão falsificáveis. A opção TCP keepalive habilitada por TCPKeepAlive é falsificável. O mecanismo de servidor ativo é valioso quando o cliente ou servidor depende de saber quando uma conexão se tornou inativa.

O valor padrão é 3. Se, por exemplo, ServerAliveInterval (veja abaixo) for definido como 15 e ServerAliveCountMax for deixado no padrão, se o servidor não responder, o ssh será desconectado após aproximadamente 45 segundos.

ServerAliveInterval
Define um intervalo de tempo limite em segundos após o qual, se nenhum dado for recebido do servidor, o ssh(1) enviará uma mensagem através do canal criptografado para solicitar uma resposta do servidor. O padrão é 0, indicando que essas mensagens não serão enviadas ao servidor.

Portanto, se você definir ServerAliveIntervalcomo 5, sshserá desconectado automaticamente se a rede falhar por 15 segundos.

Answer

Use as opções do ssh ServerAlivepara detectar quando a conexão falhou.

ServerAliveCountMax
Define o número de mensagens ativas do servidor (veja abaixo) que podem ser enviadas sem que o ssh(1) receba nenhuma mensagem de volta do servidor. Se esse limite for atingido enquanto as mensagens ativas do servidor estiverem sendo enviadas, o ssh se desconectará do servidor, encerrando a sessão. É importante observar que o uso de mensagens de servidor ativo é muito diferente do TCPKeepAlive (abaixo). As mensagens ativas do servidor são enviadas através do canal criptografado e, portanto, não serão falsificáveis. A opção TCP keepalive habilitada por TCPKeepAlive é falsificável. O mecanismo de servidor ativo é valioso quando o cliente ou servidor depende de saber quando uma conexão se tornou inativa.

O valor padrão é 3. Se, por exemplo, ServerAliveInterval (veja abaixo) for definido como 15 e ServerAliveCountMax for deixado no padrão, se o servidor não responder, o ssh será desconectado após aproximadamente 45 segundos.

ServerAliveInterval
Define um intervalo de tempo limite em segundos após o qual, se nenhum dado for recebido do servidor, o ssh(1) enviará uma mensagem através do canal criptografado para solicitar uma resposta do servidor. O padrão é 0, indicando que essas mensagens não serão enviadas ao servidor.

Portanto, se você definir ServerAliveIntervalcomo 5, sshserá desconectado automaticamente se a rede falhar por 15 segundos.

Question 3

eu tenho usadotmuxhá alguns anos e na minha experiência, ele se reconecta automaticamente. Pelo menos quando a conexão falha apenas por um período relativamente breve. Observe que eu realmente usobyobucom tmux como back-end. Não sei se essa robustez é uma característica tmuxou byobumesmo da combinação dos dois, mas sugiro que você experimente os dois.

Eu me conecto da minha instalação local do Arch a vários servidores Ubuntu remotos por meio de uma VPN. Eu testei agora desconectando meu cabo de rede enquanto estava conectado ao controle remoto. A sessão travou, mas assim que meu cabo foi conectado novamente, ela foi retomada sem problemas.

Porém, quando testei reiniciando meu roteador, a conexão não retornou. Presumo que tenha algo a ver com o tempo que a rede ficou inativa, mas parece reconectar se ficar inativa por apenas alguns segundos.

Caso seja relevante, faço tudo isso usandoterminatorcomo meu emulador de terminal.

Todos os três estão disponíveis nos repositórios do Ubuntu:

sudo apt-get install tmux terminator byobu

No entanto, não tenho certeza de que tmuxseja byobumelhor lidar com desconexões de ssh. Só sei que, pela minha experiência, eles geralmente voltam de pequenas perdas de conexão. Isso pode estar relacionado a outros aspectos da minha configuração.

Answer

eu tenho usadotmuxhá alguns anos e na minha experiência, ele se reconecta automaticamente. Pelo menos quando a conexão falha apenas por um período relativamente breve. Observe que eu realmente usobyobucom tmux como back-end. Não sei se essa robustez é uma característica tmuxou byobumesmo da combinação dos dois, mas sugiro que você experimente os dois.

Eu me conecto da minha instalação local do Arch a vários servidores Ubuntu remotos por meio de uma VPN. Eu testei agora desconectando meu cabo de rede enquanto estava conectado ao controle remoto. A sessão travou, mas assim que meu cabo foi conectado novamente, ela foi retomada sem problemas.

Porém, quando testei reiniciando meu roteador, a conexão não retornou. Presumo que tenha algo a ver com o tempo que a rede ficou inativa, mas parece reconectar se ficar inativa por apenas alguns segundos.

Caso seja relevante, faço tudo isso usandoterminatorcomo meu emulador de terminal.

Todos os três estão disponíveis nos repositórios do Ubuntu:

sudo apt-get install tmux terminator byobu

No entanto, não tenho certeza de que tmuxseja byobumelhor lidar com desconexões de ssh. Só sei que, pela minha experiência, eles geralmente voltam de pequenas perdas de conexão. Isso pode estar relacionado a outros aspectos da minha configuração.

Question 4

Isenção de responsabilidade

Se a sua conexão SSH não sobreviver a breves interrupções na rede, então háalgo maisacontecendo, isso não permite que ssho TCP faça suas coisas normais.

Veja abaixo para obter detalhes. De qualquer forma:

A solução sem dependências mais rápida e suja

Crie um script de shell como este:

#!/bin/sh -

# Tune these numbers depending on how aggressively
# you want your SSH session to get reconnected.
timeout_options='-o ServerAliveInterval=4 -o ServerAliveCountMax=2'

# 255 is the status OpenSSH uses to signal SSH errors, which
# means we want to connect. All other exit statuses suggest
# an intentional exit.
status=255

# Keep opening the SSH connection and immediately dropping into
# `screen` until an intentional exit happens.
while [ "$status" = 255 ]
do
    ssh $timeout_options -t "$@" screen -dR
    status=$?
    # You can add a `sleep` command here or a counter or whatever
    # you might need as far as rate/retry limiting.
done
exit "$status"

Isso apenas executará um loop simples e estúpido que continua tentando se conectar sshe anexar a screen. Passe o host ou qualquer outra coisa que você normalmente passaria para sua sshinvocação como argumentos de linha de comando.

A reconexão é baseada apenas no fato de o SSH relatar um erro com a conexão, o que significa que ele não tem inteligência para detectar erros não-SSH como "você literalmente não tem o WiFI ligado" ou algo assim, mas isso provavelmente não importa para você.

Presumo que você tenha ssh-agentuma chave SSH sem senha que permitirá que as reconexões funcionem sem informações adicionais suas.

Haverá uma pequena condição de corrida em que, se você acertar ^Capenas a fração de segundo imperceptível para o ser humano durante uma reconexão, poderá acabar matando o script em vez de passá-lo ^Cpara o terminal do cliente, portanto, se você suspeitar de uma conexão travada não amasse ^Ccom muito zelo.

Solução de software adicional mais simples

Você pode experimentar o programaautossh, que deve estar disponível no repositório de pacotes do Ubuntu.

Se você precisar compilar a partir do código-fonte ou auditá-lo, é um único programa C que compila sem nenhuma biblioteca adicional como dependências, parece ter mais inteligência sobre como verificar a vivacidade da conexão do que meu hack acima,eele também vem com um rscreencomando de script conveniente que é anexado automaticamente ao arquivo screen.

Detalhes

Como `ssh`normalmente se recupera

Só para verificar, porque não gosto de falar as coisas sem me controlar, fiz um pequeno teste antes de responder:

Entrei no meu WiFi com um dispositivo Linux, fiz uma conexão SSH com outro dispositivo na minha LAN, verifiquei que tinha uma sshconexão funcionando com o outro lado (poderia executar comandos, etc.) e depois no clientedesconectou o WiFi(fazendo com que a interface fosse desconfigurada: não há mais endereços IP), digitei mais caracteres na sessão ssh (sem resposta, é claro) e depois reconectei ao meu WiFi - a reconexão realmente falhou pelo menos uma vez devido a problemas sinal e outros fatores, e finalmente reconectei: esperei cerca de cinco segundos para a sshsessão se recuperar, nada aconteceu, então apertei mais uma tecla, e a sshsessão imediatamente ganhou vida novamente, com todas as teclas que eu havia digitado durante a desconexão aparecendo em a linha de comando.

Veja, sshapenas escreve/lê no soquete de rede TCP até que o sistema operacional diga que algo deu errado e o TCP está realmentemuitotolerante a quedas prolongadas de conexão.

Deixada por conta própria com as configurações padrão do kernel, a pilha TCP no Linux tolerará alegremente que a conexão fique completamente silenciosa por muitos minutos antes de declarar a conexão inativa e relatar um erro para ssh- quando ela finalmente desistir, estaremos conversando no estádio de aproximadamente 30 minutos, ou pelo menos certamente tempo suficiente para durar mais que soluços de conexão que duram um segundo ou um minuto.

Nos bastidores, a pilha TCP do Linux tenta gradualmente as mensagens com atrasos cada vez maiores, o que significa que, quando sua conexão voltar, você poderá observar um atraso adicional antes que sua sshsessão pareça "viva" novamente.

Por que isso às vezes quebra

Muitas vezes, algo está causando ativamente o fechamento da conexão após algunssignificativamente mais curtoperíodo de inatividade maior que o valor que a pilha TCP irá tolerar e, em seguida, deixar de relatar esse estado de conexão ao seu sshcliente.

Os prováveis candidatos incluem:

Firewalls ou roteadores NAT, que precisam usar memória para lembrar cada conexão TCP ativa - como uma otimização e alguma mitigação contra ataques DOS, às vezes eles apenasesquecersua conexão e entãoignorar silenciosamentepacotes consequentes para ele, porque os pacotes no meio de uma conexão quando você não se lembra da conexão existente parecem inválidos.
Firewalls/roteadores com melhor comportamento injetarão um pacote TCP RST, que normalmente se manifesta como uma connection reset by peermensagem de erro, mas o pacote de redefinição é um disparo e esquecimento, portanto, se a conexão com o seu cliente ainda estiver com problemas naquele momento e descartar o redefinir o pacote também, seu cliente pensará que a conexão ainda está ativa.
O servidorem sipode ter uma política de firewall para descartar silenciosamente pacotes inesperados, o que interromperia as tentativas de retomada da conexão do cliente sempre que o servidor achar que a conexão foi fechada, mas o cliente não: seu cliente continua tentando continuar a conexão, mas o servidor está apenas ignorando porque não há nenhuma conexão ativa à qual esses pacotes pertençam no estado do firewall do servidor.

iptablesComo você está executando o Linux, verifique cuidadosamente o / do seu servidor ip6tables(ou nftse estiver usando o material novo) para saber exatamente o que você está permitindo ou descartando. É muito comum permitirnovo/estabelecido/relacionadopacotes na porta TCP SSH, masnão"inválidos" - se você descartar silenciosamente tudo o que não é permitido, essa configuração comum pode causar esse tipo de congelamento após breves problemas de conexão.
O próprio servidor SSH pode ser configurado para fechar a conexão após um período de inatividade, usando uma das opções OpenSSH para pacotes de manutenção de atividade do cliente TCP ou SSH. Por si só, isso não causará travamentos indefinidos, mas poderá colocá-lo em um dos estados descritos acima.
É possível que você simplesmente não esteja dando tempo suficiente para "desligar" sozinho depois de chegar ao estado em que sua sshsessão é interrompida.

Answer

Isenção de responsabilidade

Se a sua conexão SSH não sobreviver a breves interrupções na rede, então háalgo maisacontecendo, isso não permite que ssho TCP faça suas coisas normais.

Veja abaixo para obter detalhes. De qualquer forma:

A solução sem dependências mais rápida e suja

Crie um script de shell como este:

#!/bin/sh -

# Tune these numbers depending on how aggressively
# you want your SSH session to get reconnected.
timeout_options='-o ServerAliveInterval=4 -o ServerAliveCountMax=2'

# 255 is the status OpenSSH uses to signal SSH errors, which
# means we want to connect. All other exit statuses suggest
# an intentional exit.
status=255

# Keep opening the SSH connection and immediately dropping into
# `screen` until an intentional exit happens.
while [ "$status" = 255 ]
do
    ssh $timeout_options -t "$@" screen -dR
    status=$?
    # You can add a `sleep` command here or a counter or whatever
    # you might need as far as rate/retry limiting.
done
exit "$status"

Isso apenas executará um loop simples e estúpido que continua tentando se conectar sshe anexar a screen. Passe o host ou qualquer outra coisa que você normalmente passaria para sua sshinvocação como argumentos de linha de comando.

A reconexão é baseada apenas no fato de o SSH relatar um erro com a conexão, o que significa que ele não tem inteligência para detectar erros não-SSH como "você literalmente não tem o WiFI ligado" ou algo assim, mas isso provavelmente não importa para você.

Presumo que você tenha ssh-agentuma chave SSH sem senha que permitirá que as reconexões funcionem sem informações adicionais suas.

Haverá uma pequena condição de corrida em que, se você acertar ^Capenas a fração de segundo imperceptível para o ser humano durante uma reconexão, poderá acabar matando o script em vez de passá-lo ^Cpara o terminal do cliente, portanto, se você suspeitar de uma conexão travada não amasse ^Ccom muito zelo.

Solução de software adicional mais simples

Você pode experimentar o programaautossh, que deve estar disponível no repositório de pacotes do Ubuntu.

Se você precisar compilar a partir do código-fonte ou auditá-lo, é um único programa C que compila sem nenhuma biblioteca adicional como dependências, parece ter mais inteligência sobre como verificar a vivacidade da conexão do que meu hack acima,eele também vem com um rscreencomando de script conveniente que é anexado automaticamente ao arquivo screen.

Detalhes

Como `ssh`normalmente se recupera

Só para verificar, porque não gosto de falar as coisas sem me controlar, fiz um pequeno teste antes de responder:

Entrei no meu WiFi com um dispositivo Linux, fiz uma conexão SSH com outro dispositivo na minha LAN, verifiquei que tinha uma sshconexão funcionando com o outro lado (poderia executar comandos, etc.) e depois no clientedesconectou o WiFi(fazendo com que a interface fosse desconfigurada: não há mais endereços IP), digitei mais caracteres na sessão ssh (sem resposta, é claro) e depois reconectei ao meu WiFi - a reconexão realmente falhou pelo menos uma vez devido a problemas sinal e outros fatores, e finalmente reconectei: esperei cerca de cinco segundos para a sshsessão se recuperar, nada aconteceu, então apertei mais uma tecla, e a sshsessão imediatamente ganhou vida novamente, com todas as teclas que eu havia digitado durante a desconexão aparecendo em a linha de comando.

Veja, sshapenas escreve/lê no soquete de rede TCP até que o sistema operacional diga que algo deu errado e o TCP está realmentemuitotolerante a quedas prolongadas de conexão.

Deixada por conta própria com as configurações padrão do kernel, a pilha TCP no Linux tolerará alegremente que a conexão fique completamente silenciosa por muitos minutos antes de declarar a conexão inativa e relatar um erro para ssh- quando ela finalmente desistir, estaremos conversando no estádio de aproximadamente 30 minutos, ou pelo menos certamente tempo suficiente para durar mais que soluços de conexão que duram um segundo ou um minuto.

Nos bastidores, a pilha TCP do Linux tenta gradualmente as mensagens com atrasos cada vez maiores, o que significa que, quando sua conexão voltar, você poderá observar um atraso adicional antes que sua sshsessão pareça "viva" novamente.

Por que isso às vezes quebra

Muitas vezes, algo está causando ativamente o fechamento da conexão após algunssignificativamente mais curtoperíodo de inatividade maior que o valor que a pilha TCP irá tolerar e, em seguida, deixar de relatar esse estado de conexão ao seu sshcliente.

Os prováveis candidatos incluem:

Firewalls ou roteadores NAT, que precisam usar memória para lembrar cada conexão TCP ativa - como uma otimização e alguma mitigação contra ataques DOS, às vezes eles apenasesquecersua conexão e entãoignorar silenciosamentepacotes consequentes para ele, porque os pacotes no meio de uma conexão quando você não se lembra da conexão existente parecem inválidos.
Firewalls/roteadores com melhor comportamento injetarão um pacote TCP RST, que normalmente se manifesta como uma connection reset by peermensagem de erro, mas o pacote de redefinição é um disparo e esquecimento, portanto, se a conexão com o seu cliente ainda estiver com problemas naquele momento e descartar o redefinir o pacote também, seu cliente pensará que a conexão ainda está ativa.
O servidorem sipode ter uma política de firewall para descartar silenciosamente pacotes inesperados, o que interromperia as tentativas de retomada da conexão do cliente sempre que o servidor achar que a conexão foi fechada, mas o cliente não: seu cliente continua tentando continuar a conexão, mas o servidor está apenas ignorando porque não há nenhuma conexão ativa à qual esses pacotes pertençam no estado do firewall do servidor.

iptablesComo você está executando o Linux, verifique cuidadosamente o / do seu servidor ip6tables(ou nftse estiver usando o material novo) para saber exatamente o que você está permitindo ou descartando. É muito comum permitirnovo/estabelecido/relacionadopacotes na porta TCP SSH, masnão"inválidos" - se você descartar silenciosamente tudo o que não é permitido, essa configuração comum pode causar esse tipo de congelamento após breves problemas de conexão.
O próprio servidor SSH pode ser configurado para fechar a conexão após um período de inatividade, usando uma das opções OpenSSH para pacotes de manutenção de atividade do cliente TCP ou SSH. Por si só, isso não causará travamentos indefinidos, mas poderá colocá-lo em um dos estados descritos acima.
É possível que você simplesmente não esteja dando tempo suficiente para "desligar" sozinho depois de chegar ao estado em que sua sshsessão é interrompida.

Isenção de responsabilidade

Responder1

Responder2

Responder3

Responder4

Isenção de responsabilidade

A solução sem dependências mais rápida e suja

Solução de software adicional mais simples

Detalhes

Como `ssh`normalmente se recupera

Por que isso às vezes quebra

informação relacionada

Responder1

Responder2

Responder3

Responder4

Isenção de responsabilidade

A solução sem dependências mais rápida e suja

Solução de software adicional mais simples

Detalhes

Como sshnormalmente se recupera

Por que isso às vezes quebra

informação relacionada

Como `ssh`normalmente se recupera