Come velocizzare il mio login ssh troppo lento?


42

La corsa ssh user@hostnamedura circa 30 secondi. Ecco lo scenario:

  • questa è una VM sulla LAN locale
  • Le macchine Windows e Mac ottengono l'accesso immediato
  • sto usando Debian e potrei riprodurlo con una macchina Ubuntu
  • qualcuno che utilizza Ubuntu afferma che anche l'accesso alla mia macchina (LAN locale) è istantaneo
  • l'utilizzo dell'indirizzo IP dell'hostname richiede circa la metà del tempo (~ 15s)

[ aggiorna ]

Utilizzando ssh -vvv user@hostname, ecco dove ti aspetta di più:

debug3: authmethod_lookup gssapi-with-mic
debug3: remaining preferred: publickey,keyboard-interactive,password
debug3: authmethod_is_enabled gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic

E poi aspetta un po 'qui:

debug1: Unspecified GSS failure.  Minor code may provide more information
Credentials cache file '/tmp/krb5cc_1000' not found

debug1: Unspecified GSS failure.  Minor code may provide more information
Credentials cache file '/tmp/krb5cc_1000' not found

1
usi l'autenticazione con password o pubkey? e se password, il file id_dsao è id_rsanel tuo ~/.ssh? forse la tua installazione di ssh prova prima l'autenticazione sbagliata e il tuo server non nega ma semplicemente ignora quella richiesta risultante in quel timeout di 30 anni
Tobias Kienzler

@tobias Uso la password e non ho "~/.ssh"file. Questa è una directory e contiene solo "known_hosts"file.
Tshepang,

5
Sembra che tu abbia un timeout DNS di 15 secondi. Forse il server sta effettuando una ricerca DNS; se è possibile, assicurarsi di avere UseDNS noin sshd_configsul server. In ogni caso, corri ssh -vvv user@hostnameper vedere dove si trova il login.
Gilles 'SO- smetti di essere malvagio' il

@gil Grazie. Ho aggiornato la domanda. Chiederò all'amministratore di verificare l' impostazione UseDNS .
Tshepang,

3
@Tshepang: Oh, stai usando l'autenticazione Kerberos (GSSAPI). Non ne ho familiarità. Se è configurato male, forse sta causando il ritardo. Questo è qualcosa che puoi chiedere al tuo amministratore. Il DNS potrebbe essere un'aringa rossa; è la causa più comune in natura, ma forse il tuo problema è diverso.
Gilles 'SO- smetti di essere malvagio' il

Risposte:


32

Modifica il tuo " / etc / ssh / ssh_config " e commenta queste righe:

GSSAPIAuthentication yes
GSSAPIDelegateCredentials no

3
+1 bella risposta! (1) È normale che la connessione login ssh impieghi 7 volte a far lampeggiare il cursore? (2) Perché funziona commentando GSSAPIAuthentication yese GSSAPIDelegateCredentials no? @Tshepang
Tim

@Tim (1) è troppo lungo ... a seconda della connessione, non mi aspetto che duri più di 2 secondi; (2) Non ne ho idea, solo che funziona
tshepang,

1
Il valore predefinito per l'autenticazione GSSAPIA nella maggior parte delle versioni di OpenSSH è "no", ma alcune distribuzioni lo impostano su "sì" nei file sshd_config e ssh_config. Se non è necessario / utilizzato, rallenta l'handshake di connessione / autenticazione.
martedì

Se è in uso l'autenticazione LDAP / AD, la disabilitazione di GSSAPI non farà sì che venga utilizzato un semplice bind, potenzialmente inviando password in rete in chiaro?
Shannon,

Verificare che tutti i nameserver siano ancora presenti in /etc/resolv.conf. In caso contrario, eliminali. Questo ha risolto il mio problema.
tecnocrate,

30

Ho riscontrato questo problema e risolto disattivando la risoluzione DNS inversa in SSH.

Quindi sshd_configsul server cambia questo:

 #UseDNS yes

a questa:

UseDNS no

1
Ho apportato la modifica (anche se non avevo un'opzione UseDNS commentata ), ripristinato il mio server SSH e ancora lo stesso problema.
Tshepang,

2
@Hh, strano. L'unico problema di velocità che abbia mai avuto con SSH era dovuto a questo.
Earlz,

1
Ero scettico mentre utilizzo per accedere utilizzando l'indirizzo IP (LAN di casa), ma questa soluzione ha risolto il mio problema. Per l'amor di Google, anche se si stava verificando subito dopo, il ritardo non aveva nulla a che fare con il messaggio "key: /home/mylogin/.ssh/id_ecdsa ((nil))" (durante l'esecuzione ssh -vvv).
Skippy le Grand Gourou,

7

Hai verificato la tua configurazione DNS?

Prova l'impostazione mdns offin /etc/host.conf.

Questo disabilita la risoluzione mdns e mi ha aiutato molto.

MODIFICARE:

Sembra che Gentoo lo stia gestendo in modo un po 'diverso. Per disabilitare le ricerche DNS multicast, è necessario modificare il file /etc/nsswitch.conf.
Dovrebbe esserci qualcosa del tipo:

hosts:          files mdns

Modificalo in:

hosts:          files dns

+1 buona idea. @Tshepang ssh si connette più velocemente quando si utilizza direttamente l'IP dell'hostname?
Tobias Kienzler,

@tobias richiede la metà del tempo
tshepang,

Mi /etc/host.conf: line 2: bad command spegne mdns '' quando corro ssh user@hostname.
Tshepang,

Sembra che questa sia un'impostazione obsoleta, poiché glibc 2.3.x (2006): forum.gentoo.org/viewtopic-t-476558-highlight-mdns.html . Cosa stai usando (SO, versione glic)?
Tshepang,

1
Stai dicendo che impiega solo la metà del tempo quando usi l'indirizzo IP. Ciò significa che hai un problema con la risoluzione del tuo nome (IP => FQDN o FQDN => IP). Quindi prima dai un'occhiata alla tua configurazione DNS e poi prova a scoprire se hai un problema con ssh o no.
Christian,

3

L'aggiunta del nome host a /etc/hostspuò talvolta risolvere questo problema.


Funziona con un solo nome host, ma la soluzione di Earlz è più generica (e risolve lo stesso problema).
Skippy le Grand Gourou,

1

Controlla anche se nscdè installato e in esecuzione.

Non avere una cache DNS può aumentare il tempo necessario per risolvere il record PTR (supponendo che il client SSH stia eseguendo una ricerca inversa DNS per l'indirizzo IP del server)


0

Ho lo stesso problema in ambiente Windows 2008 R2 ma "useDNS no" non funziona.

Provo ad aggiungere al file hosts l'IP e l'host del server di connessione ed è più veloce di 30 secondi. Il che mi fa pensare che la risoluzione potrebbe essere in DNS.

Provo ad aggiungere server DNS ma questo non lo risolve.

Il mio server ha due suffissi DNS. 1 per il dominio aziendale a cui appartiene il server (domain.com) e l'altro per la sua interfaccia esterna che si collega a una rete privata (domain.net).

L'ordine del suffisso DNS è prima domain.net e poi domain.com

I miei client SFTP / SSH sono nel dominio aziendale. A proposito, i clienti problematici provengono dal dominio aziendale.

Quello che funziona per me è che prima realizzo domain.com e poi domain.net

Il ritardo di connessione 2m30s prima era diventato solo 3-4s.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.