Perché il prompt “password” impiega un'eternità quando SSH nel mio server Ubuntu 9.05?

27

Risposta: In effetti, stava eseguendo una risoluzione DNS inversa. Sulla base dei suggerimenti di seguito e di questo articolo , ho aggiunto "UseDNS no" al mio sshd_config, riavviato ssh e ora il prompt della password viene visualizzato immediatamente.

Quando inserisco SSH nel mio server, mi viene dato il prompt standard "login as:", seguito dal prompt "user @ host's password:". Per qualsiasi motivo, il secondo richiede sempre un po 'di tempo per essere visualizzato. Il mio server non è sotto carico e in genere esegue comandi abbastanza velocemente.

Ora, stiamo parlando solo 10 secondi circa tra il momento in cui premo Invio per il nome utente e quando viene visualizzato il secondo prompt, ma quando lo fai molto diventa fastidioso. Ho il sospetto che Ubuntu stia cercando il mio account utente, ma ha <5 account sull'intera installazione.

L'aggiornamento @Josh / var / log / messages contiene questa gemma:

Oct 28 16:54:59 Athena sudo: pam_sm_authenticate: Called
Oct 28 16:54:59 Athena sudo: pam_sm_authenticate: username = [msmith]
Oct 28 16:54:59 Athena sudo: Warning: Using default salt value (undefined in ~/.ecryptfsrc)
Oct 28 16:55:01 Athena sudo: Passphrase key already in keyring; rc = [1]
Oct 28 16:55:02 Athena sudo: Passphrase key already in keyring; rc = [1]
Oct 28 16:55:02 Athena sudo: There is already a key in the user session keyring for the given passphrase.

Dove msmith è il mio nome utente. Cosa significa tutto questo?

— rcampbell
fonte

Sai (o vuoi imparare) come usare sniffer di pacchetti come Wireshark o tcpdump? Ciò può dirti se il server sta effettivamente utilizzando tutto quel tempo da solo o sta effettivamente comunicando con il client.

— Arjan,

17

È possibile che stia eseguendo una ricerca DNS inversa sul tuo IP? Puoi controllare i risultati online se il client utilizza un indirizzo IP pubblico o utilizzare qualcosa di simile al seguente dal tuo server:

dig -x CLIENT_IP_ADDRESS

C'è qualcosa dentro /var/log/messages?

— Josh
fonte

Ho un avviso nel registro: Avviso: utilizzo del valore salt predefinito (non definito in ~ / .ecryptfsrc). Ho pubblicato l'intera sezione alla domanda per la tua analisi.

— rcampbell,

@ rrc7cz, quindi che dire di quel DNS inverso? Il tuo indirizzo IP si risolve in qualcosa? (Dubito che sarà di aiuto, poiché molto spesso ci vorranno alcune strette di mano per decidere se deve essere visualizzato un prompt per il nome utente. Un test rapido che utilizza Wireshark sul mio Mac mostra che SSH viene avviato molto prima che venga richiesto il nome utente. Ma forse alcuni client richiedono quel nome utente prima ancora di provare a connettersi ...?)

— Arjan,

3

Ho avuto questo problema di ricerca DNS inversa rallentando le mie connessioni ssh in un paio di installazioni ... Se trovi questo è il caso commenta la riga "UseDNS yes" in / etc / ssh / sshd_config e riavvia sshd.

— John Barrett,

@john, ricordi se questo ha rallentato dopo aver digitato il nome utente?

— Arjan,

1

"UseDNS no" mi ha aiutato anche! Voti positivi per domande e risposte!

— Grizly,

14

Probabilmente la risoluzione DNS inversa (server che sta cercando di ottenere il nome del client dato IP) sta impiegando tempo. Puoi verificare se / etc / ssh / sshd_config ha impostato "VerifyReverseMapping yes"? Impostalo su "VerifyReverseMapping no" e controlla se aiuta.

Modifica: sembra che VerifyReverseMapping sia ora obsoleto e useDNS sia la nuova configurazione in sshd_config .

— secureBadshah
fonte

Può essere vero, ma ha senso che venga mostrato subito il prompt del nome utente, dopo di che ci vogliono 10 secondi per richiedere la password?

— Arjan,

Il client è in grado di risolvere il nome del server e inviare una richiesta, per questo motivo viene immediatamente visualizzato il prompt dell'utente. Ma poi il server tenta di ottenere il nome del client (risoluzione DNS inversa). Questo può scadere se la dose iniziale non esiste. L'impostazione "VerifyReverseMapping" in sshd-config controlla questo controllo.

— secureBadshah,

1

Questa è stata la ragione della lentezza nel mio caso, quindi in alcuni casi ha senso almeno. Tieni presente che l'impostazione predefinita è yes, quindi non limitarti a cercare se useDNSè impostato :)

— Nanne

8

Nel file sshd_config impostare GSSAPIAuthentication = no

https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/84899

3

Puoi sempre accedere con il nome utente per iniziare con:

ssh user@server

ha qualche effetto?

Se stai usando PuTTY, è configurabile in Connessione -> Dati come nome utente di accesso automatico.

— John T
fonte

1

Anche se questo ovviamente non accelera il tempo necessario per visualizzare la richiesta della password, accelera sicuramente il processo di accesso generale. Grazie

— rcampbell,

3

Se non hai nomi di dominio adeguati per tutto, crea qualcosa e inseriscilo /etc/hosts. Vedi se va più veloce ... non preoccuparti di .comusare semplicemente "bob, carol, ted, alice" o qualunque cosa tu voglia ...

Se il problema è timeout del risolutore, questo risolverà il problema.

— DigitalRoss
fonte

1

Ricorda che il client eseguirà anche il controllo del DNS inverso, che può richiedere 30 secondi o più per il timeout se la mappatura DNS inverso non esiste con determinate configurazioni di risoluzione.

In uno /etc/ssh/ssh_configo in ~/.ssh/configset CheckHostIP noper disabilitare questa ricerca sul lato client.

Vedi man 5 ssh_configper ulteriori dettagli.

— tylerl
fonte

1

Ho trovato una soluzione alternativa a questo problema: - http://www.patrickmin.com/linux/tip.php?name=ssh_pause

Stavo riscontrando lo stesso problema accedendo a una macchina build Linux usando Putty sotto Windows. L'aggiunta dell'indirizzo IP della mia finestra di Windows a / etc / hosts sulla macchina linux ha risolto il problema.

— Rob Belcham
fonte

3

Benvenuto in Super User: generalmente preferiamo che tu includa dettagli e non solo link. Potresti MODIFICARE la tua risposta per aggiungere ulteriori informazioni dal link?

— Simon Sheehan,

1

Per la cronaca, ho riscontrato lo stesso problema in cui ssh sarebbe veloce da casa al mio server di casa (usandolo principalmente per git), ma ci sarebbero voluti circa 10-20 secondi al lavoro per ottenere una richiesta di password.

Ho dovuto spegnere UseDNS noe riavviare sshd sudo systemctl restart sshd.service. Quindi funziona da tutte le posizioni.

So che alla domanda viene data risposta e accettata, ma volevo aggiungere le informazioni poiché ho dovuto "attivamente" impostarlo su no per impedirle di smettere di usare dns.

— qrikko
fonte

0

Verifica se nslcd (daemon LDAP) è in esecuzione:

ps -ef | grep nslcd

Può causare questo problema.

Se è in esecuzione, arrestalo e rimuovilo dall'elenco dei servizi

service nslcd stop
chkconfig nslcd off

— Anu V Das
fonte