Por que minha conexão SSH está lenta? Cinco correções imediatas para problemas de latência

SSH lento não é um único problema. Às vezes, o atraso acontece antes mesmo de você obter um prompt. Às vezes, o login é rápido, mas cada tecla parece pegajosa. Às vezes, o SSH é culpado por um script de inicialização de shell lento, uma consulta DNS bloqueada ou um caminho de rede descartando pacotes entre seu laptop e uma região de nuvem do outro lado do mundo.

Antes de alterar configurações, execute um teste simples:

time ssh -vvv [email protected] exit

A saída de time informa se a conexão completa está lenta. A saída de -vvv informa onde o cliente está gastando tempo. Procure por tentativas repetidas de chave, mensagens GSSAPI, pausas relacionadas a DNS ou uma longa lacuna antes do início da autenticação. Se ssh usuario@host exit for rápido, mas um login interativo for lento, o problema provavelmente está nos arquivos de inicialização do shell remoto, e não no SSH em si.

Existem três padrões comuns:

1. Lento antes da autenticação: Geralmente DNS, GSSAPI, consulta de chave do host ou um backend de autenticação lento.
2. Lento após a autenticação, mas antes do prompt: Geralmente .bashrc, .profile, .zshrc, diretórios home montados em rede ou plugins de shell.
3. Lento ao digitar ou usar ferramentas de tela cheia: Geralmente latência real de rede, perda de pacotes, endpoints sobrecarregados, sobrecarga de compressão ou renderização de terminal.

As correções abaixo estão ordenadas pela frequência com que resolvem reclamações reais de latência SSH.

1. Desabilite consultas DNS reversas no servidor

DNS reverso é uma causa clássica de logins SSH lentos em redes internas. O servidor aceita sua conexão TCP e, em seguida, tenta resolver o endereço IP do cliente conectado de volta para um nome de host. Se o DNS reverso estiver ausente, mal configurado ou manipulado por um resolvedor lento, o login pode pausar por vários segundos.

Esta é uma configuração do lado do servidor. Adicione ou atualize esta linha em /etc/ssh/sshd_config:

UseDNS no

Em seguida, teste e recarregue o SSH:

sudo sshd -t
sudo systemctl reload sshd

Algumas distribuições usam ssh como nome do serviço:

sudo systemctl reload ssh

Mantenha sua sessão atual aberta enquanto testa um novo login. Se o novo login for rápido, você encontrou o atraso. Se nada mudar, deixe a configuração em vigor se for adequada ao seu ambiente, mas continue solucionando problemas.

2. Desabilite GSSAPI quando você não usa Kerberos

GSSAPI é útil em ambientes baseados em Kerberos. Fora desses ambientes, pode adicionar uma tentativa de autenticação desnecessária. O sintoma geralmente é uma pausa durante a configuração da conexão antes que a autenticação por chave pública continue.

Defina isso em seu ~/.ssh/config local:

Host *
    GSSAPIAuthentication no

Se você só vê o atraso com um servidor, limite a configuração a esse host:

Host admin-legado
    HostName admin-legado.exemplo.com
    User admin
    GSSAPIAuthentication no

Execute ssh -vvv admin-legado e compare antes e depois. Você deve ver o cliente pular GSSAPI e ir diretamente para autenticação por chave pública ou senha.

3. Pare de oferecer as chaves erradas

Se seu agente SSH contém um monte de chaves, seu cliente pode oferecer várias identidades antes de chegar àquela que o servidor aceita. Isso é mais lento do que o necessário, e alguns servidores rejeitam o login após muitas tentativas falhas.

A saída detalhada torna isso óbvio:

debug1: Offering public key: /Users/me/.ssh/id_personal
debug1: Authentications that can continue: publickey
debug1: Offering public key: /Users/me/.ssh/id_old_vendor
debug1: Authentications that can continue: publickey
debug1: Offering public key: /Users/me/.ssh/id_prod

Fixe a identidade correta:

Host prod-api
    HostName 203.0.113.20
    User deploy
    IdentityFile ~/.ssh/id_ed25519_prod
    IdentitiesOnly yes

IdentitiesOnly yes é importante. Sem ele, o cliente ainda pode oferecer chaves do agente antes ou junto com o arquivo configurado.

Você também pode verificar o que o agente carregou:

ssh-add -l

Se a lista estiver bagunçada, remova chaves antigas do agente e adicione apenas o que você precisa para o trabalho atual:

ssh-add -D
ssh-add ~/.ssh/id_ed25519_prod

4. Use compressão apenas onde ela ajuda

Compressão não é um interruptor de velocidade universal. Pode ajudar quando o link tem largura de banda limitada e os dados são compressíveis, como logs de texto longo em uma VPN lenta. Pode prejudicar em redes rápidas porque ambos os lados gastam CPU comprimindo e descomprimindo dados que teriam atravessado o fio rapidamente de qualquer forma.

Use-a de forma restrita:

Host bastiao-distante
    HostName bastiao.exemplo.net
    User ops
    Compression yes

Não habilite globalmente a menos que você tenha medido que ajuda suas conexões diárias. Para SSH normal de nuvem para laptop, o padrão geralmente é melhor.

Se a digitação estiver lenta, a compressão raramente é a primeira correção. Teste o caminho de rede:

ping servidor.exemplo.com
mtr servidor.exemplo.com

Se você vir alta latência ou perda de pacotes, a configuração SSH só pode fazer até certo ponto. Passe por um bastião mais próximo, corrija o caminho VPN ou use uma região mais próxima do operador.

5. Reutilize conexões com multiplexação

Se a primeira conexão SSH leva alguns segundos, mas cada nova aba de terminal repete esse custo, a multiplexação de conexão é uma correção limpa. O SSH mantém uma conexão de controle aberta e a reutiliza para sessões posteriores para o mesmo usuário, host e porta.

Adicione isso a ~/.ssh/config:

Host *
    ControlMaster auto
    ControlPath ~/.ssh/controlmasters/%r@%h:%p
    ControlPersist 10m

Crie o diretório do socket:

mkdir -p ~/.ssh/controlmasters
chmod 700 ~/.ssh/controlmasters

A primeira conexão ainda paga o custo normal de handshake e autenticação. A próxima deve parecer quase instantânea.

Se uma conexão multiplexada ficar presa após uma mudança de rede, feche o socket mestre:

ssh -O exit [email protected]

Ou remova o socket correspondente de ~/.ssh/controlmasters.

Verifique a inicialização do shell antes de culpar o SSH

Este é fácil de perder. O SSH pode autenticar rapidamente, mas seus arquivos de inicialização do shell queimam vários segundos antes do prompt aparecer.

Compare estes:

time ssh [email protected] true
time ssh [email protected] 'bash --noprofile --norc -i -c exit'

Em seguida, inspecione .bashrc, .bash_profile, .profile, .zshrc e qualquer coisa que eles carreguem. Lentidões comuns incluem temas de prompt que executam comandos Git em diretórios grandes, conclusões de kubectl ou CLI de nuvem que consultam uma API remota, inicialização de gerenciador de pacotes, diretórios home NFS bloqueados e scripts que chamam serviços internos durante o login.

A correção SSH mais rápida é aquela que corresponde à pausa que você realmente pode ver. Use -vvv, mude uma coisa de cada vez e teste de um segundo terminal enquanto deixa sua sessão atual aberta.