Perché la Mia Connessione SSH è Lenta? Cinque Soluzioni Immediati per Problemi di Latenza

Una connessione SSH lenta non è un singolo problema. A volte il ritardo si verifica prima ancora di ottenere un prompt. A volte il login è veloce, ma ogni tasto premuto sembra appiccicoso. A volte si incolpa SSH per uno script di avvio della shell lento, una ricerca DNS bloccata o un percorso di rete che perde pacchetti tra il tuo laptop e una regione cloud dall'altra parte del mondo.

Prima di modificare le impostazioni, esegui un semplice test:

time ssh -vvv [email protected] exit

L'output di time ti dice se l'intera connessione è lenta. L'output di -vvv ti dice dove il client sta spendendo tempo. Cerca tentativi di chiave ripetuti, messaggi GSSAPI, pause legate al DNS o un lungo intervallo prima che inizi l'autenticazione. Se ssh user@host exit è veloce ma un login interattivo è lento, il problema è probabilmente nei file di avvio della shell remota piuttosto che in SSH stesso.

Ci sono tre modelli comuni:

1. Lento prima dell'autenticazione: Di solito DNS, GSSAPI, ricerca della chiave host o un backend di autenticazione lento.
2. Lento dopo l'autenticazione ma prima del prompt: Di solito .bashrc, .profile, .zshrc, directory home montate in rete o plugin della shell.
3. Lento durante la digitazione o l'uso di strumenti a schermo intero: Di solito latenza di rete reale, perdita di pacchetti, endpoint sovraccarichi, overhead di compressione o rendering del terminale.

Le correzioni di seguito sono ordinate per frequenza con cui risolvono i reali reclami di latenza SSH.

1. Disabilita le Ricerche DNS Inverse sul Server

Il DNS inverso è una causa classica di login SSH lenti sulle reti interne. Il server accetta la tua connessione TCP, poi cerca di risolvere l'indirizzo IP del client connesso in un nome host. Se il DNS inverso è mancante, mal configurato o gestito da un resolver lento, il login può bloccarsi per diversi secondi.

Questa è un'impostazione lato server. Aggiungi o aggiorna questa riga in /etc/ssh/sshd_config:

UseDNS no

Quindi testa e ricarica SSH:

sudo sshd -t
sudo systemctl reload sshd

Alcune distribuzioni usano ssh come nome del servizio:

sudo systemctl reload ssh

Mantieni aperta la tua sessione esistente mentre testi un nuovo login. Se il nuovo login è veloce, hai trovato il ritardo. Se non cambia nulla, lascia l'impostazione in atto se corrisponde al tuo ambiente, ma continua a fare diagnosi.

2. Disabilita GSSAPI Quando Non Usi Kerberos

GSSAPI è utile in ambienti basati su Kerberos. Al di fuori di questi ambienti, può aggiungere un tentativo di autenticazione inutile. Il sintomo è di solito una pausa durante la configurazione della connessione prima che l'autenticazione a chiave pubblica continui.

Imposta questo nel tuo ~/.ssh/config locale:

Host *
    GSSAPIAuthentication no

Se vedi il ritardo solo con un server, limita l'impostazione a quell'host:

Host legacy-admin
    HostName legacy-admin.example.com
    User admin
    GSSAPIAuthentication no

Esegui ssh -vvv legacy-admin e confronta prima e dopo. Dovresti vedere il client saltare GSSAPI e passare direttamente all'autenticazione a chiave pubblica o password.

3. Smetti di Offrire le Chiavi Sbagliate

Se il tuo agente SSH contiene un mucchio di chiavi, il tuo client potrebbe offrire diverse identità prima di raggiungere quella che il server accetta. Questo è più lento del necessario e alcuni server rifiutano il login dopo troppi tentativi falliti.

L'output verboso rende questo ovvio:

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

Fissa l'identità corretta:

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

IdentitiesOnly yes è importante. Senza di esso, il client potrebbe comunque offrire chiavi dell'agente prima o insieme al file configurato.

Puoi anche controllare cosa ha caricato l'agente:

ssh-add -l

Se l'elenco è disordinato, rimuovi le vecchie chiavi dall'agente e aggiungi solo quelle necessarie per il lavoro corrente:

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

4. Usa la Compressione Solo Dove Aiuta

La compressione non è un interruttore universale di velocità. Può aiutare quando il collegamento è limitato in larghezza di banda e i dati sono comprimibili, come lunghi log di testo su una VPN lenta. Può danneggiare su reti veloci perché entrambe le parti spendono CPU per comprimere e decomprimere dati che sarebbero passati rapidamente attraverso il cavo comunque.

Usala in modo mirato:

Host distant-bastion
    HostName bastion.example.net
    User ops
    Compression yes

Non abilitarla globalmente a meno che tu non abbia misurato che aiuta le tue connessioni quotidiane. Per la normale SSH da cloud a laptop, l'impostazione predefinita è spesso migliore.

Se la digitazione è lenta, la compressione è raramente la prima correzione. Testa il percorso di rete:

ping server.example.com
mtr server.example.com

Se vedi alta latenza o perdita di pacchetti, la configurazione SSH può fare solo fino a un certo punto. Passa attraverso un bastione più vicino, correggi il percorso VPN o usa una regione più vicina all'operatore.

5. Riutilizza le Connessioni con il Multiplexing

Se la prima connessione SSH richiede un paio di secondi ma ogni nuova scheda del terminale ripete quel costo, il multiplexing delle connessioni è una soluzione pulita. SSH mantiene una connessione di controllo aperta e la riutilizza per sessioni successive allo stesso utente, host e porta.

Aggiungi questo a ~/.ssh/config:

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

Crea la directory del socket:

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

La prima connessione paga ancora il normale costo di handshake e autenticazione. La successiva dovrebbe sembrare quasi istantanea.

Se una connessione multiplexata si blocca dopo un cambiamento di rete, chiudi il socket master:

ssh -O exit [email protected]

Oppure rimuovi il socket corrispondente da ~/.ssh/controlmasters.

Controlla l'Avvio della Shell Prima di Incolpare SSH

Questo è facile da trascurare. SSH potrebbe autenticarsi rapidamente, poi i tuoi file di avvio della shell bruciano diversi secondi prima che appaia il prompt.

Confronta questi:

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

Poi ispeziona .bashrc, .bash_profile, .profile, .zshrc e tutto ciò che includono. I rallentamenti comuni includono temi del prompt che eseguono comandi Git in grandi directory, completamenti kubectl o CLI cloud che interrogano un'API remota, inizializzazione del gestore di pacchetti, directory home NFS bloccate e script che chiamano servizi interni durante il login.

La correzione SSH più veloce è quella che corrisponde alla pausa che puoi effettivamente vedere. Usa -vvv, cambia una cosa alla volta e testa da un secondo terminale lasciando aperta la sessione corrente.