3 Alternativas ao SSH para Conexões Instáveis
Compare Mosh, Eternal Terminal e autossh para conexões SSH instáveis: UDP, reconexão TCP, requisitos do servidor e uso com tmux.
Mosh, Eternal Terminal e autossh resolvem a mesma falha de três maneiras diferentes: o Mosh sincroniza o estado do terminal via UDP e acompanha você através de mudanças de IP, o Eternal Terminal reconecta a mesma sessão via TCP, e o autossh reinicia o SSH automaticamente, mas inicia uma sessão nova a cada vez.
Se você já assistiu a um deploy congelar no meio do caminho porque seu trem entrou em um túnel, sabe como o resto acontece: o terminal travа, você fica ali na esperança, e um minuto depois está encarando client_loop: send disconnect. Wi-Fi de café, celular em modo roteador e uma VPN instável fazem todos a mesma coisa com uma sessão. A questão não é se você deve substituir o SSH puro para trabalho interativo; é qual dessas três ferramentas se encaixa na sua rede e no seu nível de acesso ao servidor. Este artigo as compara em um único eixo: o que realmente acontece com sua sessão quando o link cai.
Pontos Principais
- O Mosh sincroniza o estado do terminal via UDP, o Eternal Terminal reconecta a mesma sessão via TCP, e o autossh reinicia o SSH com uma sessão nova a cada vez.
- Se o UDP está bloqueado entre você e o servidor é o fator decisivo entre Mosh e Eternal Terminal.
- O autossh é inteiramente client-side e não precisa de nada no servidor além do sshd, mas cada reconexão cai em um novo shell, então ele precisa de tmux ou Zellij para ser útil.
- tmux e Zellij se sobrepõem às três ferramentas; eles mantêm os processos vivos no servidor enquanto essas ferramentas mantêm vivo o seu caminho até o servidor.
O Que Quebra Quando o Link Cai?
Uma sessão SSH vive dentro de uma única conexão TCP vinculada ao endereço IP do seu cliente, então quando a rede cai ou o endereço muda, a conexão morre e leva o shell remoto com ela. O TCP identifica uma conexão pela quádrupla de endereço e porta de origem e de destino; um novo IP de uma nova rede Wi-Fi significa uma nova quádrupla que o servidor nunca conheceu. Uma vez que os keepalives falham ou o socket dá erro, o sshd elimina o shell e todos os processos em primeiro plano dentro dele. As três ferramentas abaixo atacam cada uma um elo diferente dessa cadeia.
Mosh: Sincronização de Estado via UDP
O Que Ele Faz na Falha
O Mosh substitui o modelo de fluxo de bytes por sincronização de estado: cliente e servidor mantêm cada um um snapshot da tela, e o State Synchronization Protocol do Mosh os converge por meio de datagramas UDP criptografados. Como o servidor simplesmente direciona o tráfego para o endereço de origem do último pacote autenticado, o roaming entre mudanças de IP é automático; coloque o laptop em suspensão, troque de rede, e a sessão retoma sem qualquer etapa de reconexão. O eco local preditivo mostra suas teclas imediatamente, em vez de esperar o round trip até o servidor.
O Que Ele Exige
O Mosh exige o binário mosh-server na máquina remota (sem necessidade de privilégios de superusuário e sem daemon de longa duração: ambas as metades rodam com seu usuário e param quando a sessão termina), além de alcançabilidade via UDP. O Mosh autentica por meio de um login SSH normal e, em seguida, por padrão usa uma porta UDP na faixa de 60000 a 61000 (a primeira porta disponível a partir da 60001), que os firewalls precisam permitir. Ele repassa opções para o ssh subjacente:
mosh --ssh="ssh -i ~/.ssh/other_key" user@hostOnde Ele Deixa a Desejar
Se o UDP estiver bloqueado, o Mosh simplesmente não funciona; não há fallback para TCP. O Mosh também mantém sincronizados apenas os caracteres atualmente na tela, então seu scrollback desaparece, e o próprio FAQ do projeto o direciona ao screen ou tmux do lado remoto. A comparação entre as duas ferramentas feita pelo Eternal Terminal acrescenta que o Mosh não consegue operar o control mode do tmux (tmux -CC), o que importa para usuários do iTerm2. A versão mais recente na página de releases do projeto é a 1.4.0, de outubro de 2022.
Eternal Terminal: A Mesma Sessão via TCP
O Que Ele Faz na Falha
O Eternal Terminal retoma a conexão por TCP comum sem derrubar o que você estava fazendo, incluindo uma sessão tmux em execução, de modo que uma queda lhe custa uma pausa em vez do seu trabalho. Como ele nunca sai do TCP, funciona exatamente nas redes que descartam o Mosh: firewalls corporativos que bloqueiam UDP e caminhos que forçam o tráfego por um proxy TCP.
O Que Ele Exige
O Eternal Terminal exige um daemon do lado do servidor. O README do projeto estabelece dois pré-requisitos: o ssh faz o handshake e a criptografia, então ssh user@hostname precisa funcionar antes de o ET funcionar, e o lado servidor escuta na porta TCP 2022, a menos que você a altere. Instale com brew install et no macOS, ou no Ubuntu:
sudo add-apt-repository ppa:jgmath2000/et
sudo apt-get update
sudo apt-get install etVerifique o daemon com systemctl status et.
Onde Ele Deixa a Desejar
Reconexão via TCP significa nenhuma mágica de roaming e nenhum eco local: em um link de alta latência, digitar continua parecendo SSH. E porque ele precisa de um daemon instalado como root e de uma porta aberta, está fora de questão em máquinas onde você não pode instalar software.
autossh: Reinício Automático, Sessão Nova
O Que Ele Faz na Falha
O autossh encapsula o ssh e monitora o processo que iniciou, lançando um substituto sempre que esse processo termina ou fica silencioso. Cada reconexão é uma sessão SSH inteiramente nova, então, sem um multiplexador no servidor, o que você estava executando desaparece quando o link volta.
O Que Ele Exige
O autossh não exige nada no servidor além de um sshd em execução, o que o torna a única opção das três em máquinas onde você não pode instalar software. Instalação no cliente:
sudo apt install autossh # Debian/Ubuntu
sudo dnf install autossh # Fedora/RHEL family (may need EPEL)
brew install autossh # macOSOnde Ele Deixa a Desejar
Ele restaura a conexão, não a sessão. Também depende de o ssh perceber a falha: o man page sugere ServerAliveInterval e ServerAliveCountMax para que o cliente desista rapidamente quando o link estiver morto.
tmux ou Zellij por Cima
tmux e Zellij não substituem nenhuma dessas ferramentas: eles mantêm seus processos vivos no servidor, enquanto Mosh, Eternal Terminal e autossh mantêm vivo o seu caminho até o servidor, e as duas camadas se combinam. O Zellij é um multiplexador de terminal que gerencia sessões, painéis e abas e se sobrepõe a uma conexão remota da mesma forma que o tmux faz.
autossh mais tmux é a configuração mínima viável, porque reanexa uma sessão persistente a cada reinício:
autossh -M 0 -o "ServerAliveInterval 10" -o "ServerAliveCountMax 3" \
-t user@host "tmux new -A -s main"-M 0 desativa a porta de monitoramento do autossh, de forma que ele passa a depender da própria saída do ssh, e tmux new -A -s main anexa (ou cria) a sessão main a cada vez. A combinação ajuda as outras também: o tmux fornece o scrollback que falta ao Mosh, e o Eternal Terminal explicitamente conduz uma sessão tmux através das quedas.
Como Escolher Entre Essas Alternativas ao SSH?
Faça três perguntas nesta ordem. O UDP está bloqueado entre você e o servidor? Se sim, o Mosh está fora; o Eternal Terminal é a escolha resiliente. Você pode instalar algo no servidor? Se não, autossh mais tmux é sua única jogada. Caso contrário, escolha pela sensação de uso: Mosh para roaming e eco instantâneo em links ruins, Eternal Terminal se você precisa de scrollback real ou de tmux -CC.
| Mosh | Eternal Terminal | autossh | |
|---|---|---|---|
| Modelo de recuperação | Sincronização de estado via UDP, faz roaming de IPs | Reconecta a mesma sessão via TCP | Reinicia o ssh, nova sessão |
| Necessidades no servidor | Binário mosh-server, UDP aberto | Daemon como root, porta TCP 2022 | Apenas sshd |
| Principal limitação | Sem UDP, sem sessão | Sem eco local | Sessão perdida sem tmux |
O modo de falha que você não pode tolerar é o que define a ferramenta. Experimente primeiro o Mosh em uma rede aberta, mantenha o Eternal Terminal para as mais restritas, e coloque autossh -M 0 com uma sessão tmux nomeada em um alias de shell hoje mesmo; isso melhora toda máquina na qual você já consegue entrar por ssh.
Perguntas Frequentes
O Mosh funciona através de um jump host ou bastion SSH?
Não. O Mosh não tem tratamento nativo para [túneis SSH ou hosts bastion](https://docs.blink.sh/advanced/advanced-mosh). Um jump host pode conduzir o login SSH inicial, mas o tráfego UDP criptografado precisa alcançar a máquina de destino diretamente depois disso, o que um jump server por si só não oferece. Em redes que só permitem bastion, o autossh funciona sem alterações porque executa o ssh comum, que suporta ProxyJump.
O Mosh é tão seguro quanto o SSH puro?
O login continua ocorrendo via SSH. Depois disso, o Mosh criptografa e autentica cada datagrama UDP com [AES-128 no modo OCB3](https://mosh.org/), um esquema de criptografia autenticada. O SSH é usado apenas para trocar as chaves no início, então uma fragilidade do SSH afetaria essa breve etapa de configuração, e não a sessão Mosh de longa duração. Suas chaves SSH existentes e a verificação de host se aplicam sem alterações.
O autossh pode manter vivos port forwards SSH, e não apenas shells interativos?
Sim, túneis persistentes são um dos usos mais comuns do autossh. Execute-o com -N para que nenhum comando remoto seja executado, -M 0 para desativar a porta de monitoramento, e suas flags habituais de encaminhamento -L ou -R; o próprio exemplo do man page combina -f -M 0 -N com ServerAliveInterval e ServerAliveCountMax. Um túnel não mantém estado de shell, então a limitação da sessão nova não se aplica: o autossh simplesmente reestabelece o encaminhamento.
