ssh, scp o sftp su un nodo che non appare nel file DNS o /etc/hosts è lento a stabilire una connessione iniziale. Dopo aver stabilito la connessione, la velocità è quella prevista. Ci sono due casi da considerare, vedi sotto. Si noti che nella maggior parte degli ambienti questo problema non si verifica poiché gli IP saranno in /etc/hosts o DNS.
Il tempo viene impiegato per risolvere l'indirizzo IP del nome host di destinazione/origine o per trovare il nome host per l'indirizzo IP di destinazione/origine e/o per eseguire l'autenticazione in base agli stessi dati. Ci sono due diversi sintomi dettagliati quando usiamo -vvv con ssh che costituiscono due casi diversi.
Caso 1
# ssh -vvv 10.10.10.205 ... ... debug1: Next authentication method: gssapi-with-mic debug3: Trying to reverse map address 10.10.10.205. debug1: Unspecified GSS failure. Minor code may provide more information No credentials cache found
Nei sistemi CentOS/RHEL, il demone SSH è configurato per utilizzare Generic Security Services Application Program Interface (GSSAPI) autenticazione per impostazione predefinita. Il GSSAPI per impostazione predefinita esegue una ricerca (tramite DNS o altri mezzi basati su /etc/resolv.conf) per l'IP richiesto. Si noti che la ricerca avviene anche se si utilizzano indirizzi IP. Ciò è necessario per un'autenticazione sicura/affidabile.
Se controlli la pagina man di configurazione SSH:
# man ssh_config
...
GSSAPIAuthentication
Specifies whether user authentication based on GSSAPI is allowed. The default is no
... Se l'IP/host non appare in /etc/hosts o nel database DNS, la query di ricerca scade, mentre riprova, alla fine si arrende e continua ad aprire la connessione. Il tempo trascorso durante la ricerca (50 secondi o più), finché non viene visualizzata la richiesta della password. Questo stallo si verifica solo agli host che si trovano sulla LAN locale e non nel file DNS o /etc/hosts. Si noti che il metodo di autenticazione è GSSAPI.
Caso 2
# ssh -vvv 10.10.10.12 . . . debug1: Offering public key: /root/.ssh/id_dsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply --stalls for 8 seconds--
Qui, l'host remoto sta tentando di eseguire una ricerca DNS sull'IP del nodo client. Potrebbe trattarsi di un'installazione di una macchina fisica o virtuale nuova di zecca che non è aggiornata in /etc/hosts o DNS e quindi si blocca fino al timeout della query DNS. Anche in questo caso, la ricerca DNS/host viene eseguita (basata su /etc/resolv.conf su client/server).
La soluzione
La soluzione supportata e corretta a questo problema è che le ricerche nome host/IP abbiano esito positivo. Per farlo, puoi:
- Controlla la tua configurazione in /etc/resolv.conf per la risoluzione dei nomi e la configurazione del server DNS.
- Se non definito, definire l'host/IP appena introdotto da includere nel server DNS
- Se è un problema o non è degno di fare definizioni DNS (molto probabilmente l'assegnazione è temporanea, ad esempio un sistema di test, una macchina virtuale temporanea ecc.) assicurati che la coppia nome host/indirizzo IP sia inclusa nell'origine e nella destinazione file /etc/hosts degli ambienti (questo è molto più pratico)
Soluzioni alternative
Senza un DNS / host adeguato (o /etc/resolv.conf config per quella materia), le connessioni SSH dovrebbero essere inizialmente lente. È così che dovrebbe essere in OEL. In alternativa, la situazione di attesa può essere risolta da alcune modifiche alla configurazione.
Per Caso 1 l'autenticazione GSSAPI potrebbe essere stata disabilitata. Sebbene ciò sia possibile, è fortemente sconsigliato in quanto l'uso di GSSAPI è una delle funzionalità di sicurezza fondamentali fornite da SSH. SSH non solo consente la sicurezza dei contenuti della comunicazione, ma può anche assicurarsi che l'obiettivo sia quello previsto. Questo perché GSSAPIAuthentication è impostato su yes in OEL (sebbene la pagina man indichi che è "No" per impostazione predefinita, ma è l'impostazione predefinita dei pacchetti ssh principali, non la distribuzione specifica). Tuttavia, è possibile disabilitarlo, se sei perfettamente sicuro di essere su una rete chiusa e consapevole di sapere cosa stai facendo:
Configurazione temporanea – solo per vedere se funziona sulla riga di comando:
# ssh -o "GSSAPIAuthentication no" 10.10.10.205
La richiesta della password dovrebbe apparire immediatamente se il caso 1 è il tuo caso. Per impostarlo in modo permanente (nonostante qualsiasi altra raccomandazione) puoi modificare GSSAPIAuthentication su no in uno di questi modi sul client:
1. Aggiungi la riga sottostante al file di configurazione ssh della directory home dell'utente (~/.ssh/config ):
GSSAPIAuthentication no
2. Aggiungilo al file di configurazione SSH del sistema sul client. cioè – /etc/ssh/ssh_config e lato server. Modifica il file di configurazione lato server (cioè il sistema a cui ti stai connettendo, in questo caso è 10.10.10.205) – /etc/ssh/sshd_config e riavvia sshd:
# service sshd restart
questo può essere fatto mentre ci sono già connessioni SSH stabilite.
Per il caso 2, se in qualche modo non puoi/non vuoi modificare la configurazione DNS oi file /etc/hosts (nonostante qualsiasi raccomandazione in caso contrario), puoi aggirare la situazione disabilitando le ricerche DNS eseguite per il protocollo SSH. Puoi farlo impostando
UseDNS no
nel file di configurazione SSH del server – /etc/ssh/sshd_config
e riavvia sshd sul server
# service sshd restart
questo può essere fatto mentre le connessioni sono attive.