2010-07-22 07:02:00 +0000 2010-07-22 07:02:00 +0000
103
103

Perché il mio login SSH è lento?

Sto vedendo dei ritardi nei login SSH. In particolare, ci sono 2 punti in cui vedo una gamma di ritardi da istantanei a multi-secondi.

  1. Tra l'emissione del comando ssh e l'ottenimento del prompt di login e
  2. tra l'inserimento della passphrase e il caricamento della shell

Ora, in particolare sto guardando solo i dettagli di ssh qui. Ovviamente la latenza di rete, la velocità dell'hardware e dei sistemi operativi coinvolti, complessi script di login, ecc. possono causare ritardi. Per il contesto, io faccio ssh su una vasta moltitudine di distribuzioni linux e su alcuni host Solaris usando principalmente Ubuntu, CentOS e MacOS X come sistemi client. Quasi sempre, la configurazione del server ssh è invariata dalle impostazioni predefinite del sistema operativo.

A quali configurazioni del server ssh dovrei essere interessato? Ci sono parametri OS/kernel che possono essere sintonizzati? Trucchi per la shell di accesso? Etc?

Risposte (22)

130
130
130
2010-07-22 08:38:59 +0000

Prova ad impostare UseDNS su no in /etc/sshd_config o /etc/ssh/sshd_config.

39
39
39
2010-09-22 17:42:34 +0000

Quando ho eseguito ssh -vvv su un server con una prestazione lenta simile ho visto un blocco qui:

debug1: Next authentication method: gssapi-with-mic

Modificando /etc/ssh/ssh_config e commentando quel metodo di autenticazione ho riportato le prestazioni di login alla normalità. Ecco cosa ho nel mio /etc/ssh/ssh_config sul server:

GSSAPIAuthentication no

Puoi impostarlo globalmente sul server, così non accetta GSSAPI per autenticarsi. Basta aggiungere GSSAPIAuthentication no a /etc/ssh/sshd_config sul server e riavviare il servizio.

21
21
21
2015-08-14 00:50:20 +0000

Per me, il colpevole era la risoluzione IPv6, che andava a tempo. L'ho scoperto facendo ssh -v, che ha mostrato quale passo era sospeso.

La soluzione è ssh con l'opzione -4:

ssh -4 me@myserver.com

16
16
16
2015-05-21 09:41:03 +0000

Con systemd, il login può bloccarsi sulla comunicazione dbus con logind dopo alcuni aggiornamenti, quindi è necessario riavviare logind

systemctl restart systemd-logind

Ha visto che su debian 8, arch linx, e su una lista suse

9
9
9
2010-07-22 08:28:05 +0000

Puoi sempre avviare ssh con l'opzione -v che mostra cosa si sta facendo al momento.

$ ssh -v you@host

Con le informazioni che hai dato posso solo suggerire alcune configurazioni lato client:

  • Dato che scrivi che stai inserendo le password manualmente, ti suggerirei di usare l'autenticazione a chiave pubblica se possibile. Questo ti elimina come collo di bottiglia della velocità.

  • Potresti anche disabilitare X-forwarding con -x e authentication forwarding con -a (questi potrebbero già essere disabilitati di default). Specialmente disabilitare X-forwarding può darti un grande miglioramento della velocità se il tuo client ha bisogno di avviare un X-server per il comando ssh (per esempio sotto OS X).

Tutto il resto dipende davvero da che tipo di ritardi si verificano dove e quando.

7
7
7
2012-06-29 07:41:22 +0000

Per quanto riguarda il punto 2., ecco una risposta che non richiede di modificare il server né di avere privilegi di root/amministrativi.

Devi modificare il tuo file “user ssh_config” che è:

vi $HOME/.ssh/config

(Nota: dovresti creare la directory $HOME/.ssh se non esiste)

E aggiungere:

Host *
  GSSAPIAuthentication no
  GSSAPIDelegateCredentials yes

Puoi farlo su una base per host se necessario :) esempio:

Host linux-srv
  HostName 192.158.1.1
  GSSAPIAuthentication no
  GSSAPIDelegateCredentials yes

Assicurati che l'indirizzo IP corrisponda a quello del tuo server. Un vantaggio interessante è che ora ssh fornirà il completamento automatico per questo server. Così potete digitare ssh lin + Tab e dovrebbe autocompletare a ssh linux-srv.

4
4
4
2017-06-08 07:57:20 +0000

Controllate /etc/resolv.conf sul server per essere sicuri che il server DNS, elencato in questo file, funzioni bene, e cancellate qualsiasi DNS non funzionante.

A volte è molto utile.

2
2
2
2010-07-22 14:24:59 +0000

Oltre ai problemi di DNS già menzionati, se state sshando in un server con molti montaggi NFS, allora ci può essere un ritardo tra la password e il prompt poiché il comando quota controlla il vostro utilizzo/quota su tutti i filesystem non montati con lo noquota. Sui sistemi Solaris, puoi vedere questo nella /etc/profile di default e saltarlo eseguendo touch $HOME/.hushlogin .

1
1
1
2013-05-02 23:01:07 +0000

Se nessuna delle risposte precedenti funziona e stai affrontando problemi di ricerca inversa dei dns puoi anche controllare se nscd (name service cache daemon) è installato e in esecuzione.

Se questo è il problema è perché non hai una cache dns, e ogni volta che interroghi per un hostname che non è sul tuo hostfile mandi la domanda al tuo name server invece di cercare nella tua cache

Ho provato tutte le opzioni di cui sopra e l'unico cambiamento che ha funzionato è stato avviare nscd.

Si dovrebbe anche verificare l'ordine di fare la risoluzione della query dns in /etc/nsswitch.conf per usare prima il file hosts.

1
1
1
2015-10-13 01:19:43 +0000

Questo è probabilmente specifico solo per Debian/Ubuntu OpenSSH, che include la user-group-modes.patch scritta da uno dei manutentori del pacchetto Debian. Questa patch permette ai file ~/.ssh di avere il bit group writable impostato (g+w) se c'è solo un utente con lo stesso gid del file. La funzione secure\permissions() della patch fa questo controllo. Una delle fasi del controllo è quella di passare attraverso ogni voce di passwd usando getpwent() e confrontare il gid della voce con il gid del file.

Su un sistema con molte voci e/o un'autenticazione NIS/LDAP lenta, questo controllo sarà lento. nscd non memorizza nella cache le chiamate getpwent(), quindi ogni voce passwd sarà letta in rete se il server non è locale. Sul sistema che ho trovato questo, ha aggiunto circa 4 secondi per ogni invocazione di ssh o login nel sistema.

La soluzione è rimuovere il bit scrivibile su tutti i file in ~/.ssh facendo chmod g-w ~/.ssh/*.

1
1
1
2018-11-20 19:15:56 +0000

Nota: Questo è iniziato come un “Come fare il debug”, tutorial, ma ha finito per essere la soluzione che mi ha aiutato su un server Ubuntu 16.04 LTS.

TLDR : Eseguite landscape-sysinfo e controllate se questo comando impiega molto tempo a finire; è la stampa delle informazioni di sistema su un nuovo login SSH. Notate che questo comando non è disponibile su tutti i sistemi, il pacchetto landscape-common lo installa. (“Ma aspetta, c'è di più…”)


Avvia un secondo server ssh su un'altra porta sulla macchina che ha il problema, fallo in modalità debug, che non lo farà biforcare e stamperà messaggi di debug:

sudo /usr/sbin/sshd -ddd -p 44321

connettersi a quel server da un'altra macchina in modalità verbose:

ssh -vvv -p 44321 username@server

Il mio client emette le seguenti linee proprio prima di iniziare a dormire:

debug1: Entering interactive session.
debug1: pledge: network

Googlando questo non è molto utile, ma i log del server sono migliori:

debug3: mm_send_keystate: Finished sending state [preauth]
debug1: monitor_read_log: child log fd closed
debug1: PAM: establishing credentials
debug3: PAM: opening session
---- Pauses here ----
debug3: PAM: sshpam_store_conv called with 1 messages
User child is on pid 28051

Ho notato che quando cambio UsePAM yes con UsePAM no allora questo problema si risolve.

Non è legato a UseDNS o a qualsiasi altra impostazione, solo UsePAM influisce su questo problema sul mio sistema.

Non ho idea del perché, e non lascio nemmeno UsePAM a no, perché non so quali siano gli effetti collaterali, ma questo mi permette di continuare a indagare.

Quindi per favore non consideratela una risposta, ma un primo passo per iniziare a scoprire cosa c'è di sbagliato.


Quindi ho continuato a indagare, e ho eseguito sshd con strace (sudo strace /usr/sbin/sshd -ddd -p 44321). Questo ha dato il seguente risultato:

sendto(4, "<87>Nov 20 20:35:21 sshd[2234]: "..., 110, MSG_NOSIGNAL, NULL, 0) = 110
close(5) = 0
stat("/etc/update-motd.d", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
umask(022) = 02
rt_sigaction(SIGINT, {SIG_IGN, [], SA_RESTORER, 0x7f15dce784b0}, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGQUIT, {SIG_IGN, [], SA_RESTORER, 0x7f15dce784b0}, {SIG_DFL, [], 0}, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
clone(child_stack=0, flags=CLONE_PARENT_SETTID|SIGCHLD, parent_tidptr=0x7ffde6152d2c) = 2385
wait4(2385, # BLOCKS RIGHT HERE, BEFORE THE REST IS PRINTED OUT # [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 2385

La linea /etc/update-motd.d mi ha insospettito, apparentemente il processo aspetta il risultato della roba che è in /etc/update-motd.d

Così ho fatto cd in /etc/update-motd.d e ho eseguito un sudo chmod -x * per inibire a PAM di eseguire tutti i file che generano questo Message Of The Day dinamico, che include il carico di sistema e se i pacchetti devono essere aggiornati, e questo ha risolto il problema.

Questo è un server basato su una CPU N3150 “ad alta efficienza energetica” che ha un sacco di lavoro da fare 24/7, quindi penso che raccogliere tutti questi motd-data fosse troppo per lui.

potrei iniziare ad abilitare gli script in quella cartella in modo selettivo, per vedere quali sono meno dannosi, ma in particolare chiamare landscape-sysinfo è molto lento, e 50-landscape-sysinfo chiama proprio quel comando. Penso che sia quello che causa il maggior ritardo.

Dopo aver riabilitato la maggior parte dei file sono giunto alla conclusione che50-landscape-sysinfo e 99-esm erano la causa dei miei problemi. 50-landscape-sysinfo ha impiegato circa 5 secondi per essere eseguito e 99-esm circa 3 secondi. Tutti i file rimanenti circa 2 secondi in tutto.

50-landscape-sysinfo99-esm sono cruciali. 50-landscape-sysinfo stampa interessanti statistiche di sistema (e anche se hai poco spazio!), e 99-esm stampa messaggi relativi a Ubuntu Extended Security Maintenance

Infine puoi creare uno script con echo '/usr/bin/landscape-sysinfo' > info.sh && chmod +x info.sh e ottenere quella stampa su richiesta.

1
1
1
2017-07-22 08:21:56 +0000

Ho provato tutte le risposte ma nessuna ha funzionato. finalmente ho scoperto il mio problema:

prima ho eseguito sudo tail -f /var/log/auth.log così posso vedere il log di ssh poi in un'altra sessione ho eseguito ssh 172.16.111.166 e ho notato l'attesa su

/usr/bin/sss_ssh_knownhostsproxy -p 22 172.16.111.166

dopo aver cercato ho trovato questa linea in /etc/ssd/ssh_config

ProxyCommand /usr/bin/sss_ssh_knownhostsproxy -p %p %h

ho commentato e il ritardo è andato

1
1
1
2012-04-25 13:37:42 +0000

Funziona bene.

# uname -a
SunOS oi-san-01 5.11 oi_151a3 i86pc i386 i86pc Solaris
# ssh -V
Sun_SSH_1.5, SSH protocols 1.5/2.0, OpenSSL 0x009080ff
# echo "GSSAPIAuthentication no" >> /etc/ssh/sshd_config
# echo "LookupClientHostnames no" >> /etc/ssh/sshd_config
# svcadm restart ssh

UseDNS no non funziona con OpenIndiana !!!

Leggi “man sshd\config” per tutte le opzioni

“LookupClientHostnames no” se il tuo server non può risolvere

1
1
1
2017-03-04 22:38:38 +0000

La connessione ssh -vvv è andata molto bene fino a quando si è bloccata sul sistema cercando di ottenere il terminale per almeno 20 secondi:

debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
... waiting ... waiting ... waiting

Dopo aver fatto un systemctl restart systemd-logind sul server ho avuto di nuovo la connessione istantanea!

Questo era su debian8! Quindi il problema era systemd!

Nota: Bastien Durel ha già dato una risposta per questo problema, tuttavia mancano le informazioni di debug. Spero che questo sia utile a qualcuno.

1
1
1
2017-07-09 09:12:53 +0000

Potremmo scoprire che il metodo di risoluzione dei nomi preferito non è il file host e poi il DNS.

Per esempio, questa sarebbe la configurazione abituale:

[root@LINUX1 ~]# cat /etc/nsswitch.conf|grep hosts
#hosts: db files nisplus nis dns
hosts: files dns myhostname

Prima si raggiunge il file host (opzione: files) e poi il DNS (opzione: dns), tuttavia possiamo scoprire che è stato aggiunto un altro sistema di risoluzione dei nomi che non è operativo e ci sta causando la lentezza nel cercare di fare la risoluzione inversa.

Se l'ordine di risoluzione dei nomi non è corretto, potete cambiarlo a: /etc/nsswitch.conf

Estratto da: http://www.sysadmit.com/2017/07/linux-ssh-login-lento.html

1
1
1
2018-01-03 15:02:47 +0000

Questo thread sta già fornendo un mucchio di soluzioni ma la mia non è data qui =). Quindi eccola qui. Il mio problema (ci è voluto circa 1 minuto per effettuare il login ssh nel mio raspberry pi), era dovuto a un file .bash\history corrotto. Poiché il file viene letto al momento del login, questo causava il ritardo del login. Una volta rimosso il file, il tempo di login è tornato alla normalità, come se fosse istantaneo.

Spero che questo possa aiutare altre persone.

1
1
1
2016-12-06 09:24:08 +0000

Per completare tutte le risposte che mostrano che le risoluzioni DNS possono rallentare il vostro login ssh, a volte, manca una regola del firewall. Per esempio, se si DROP tutte le paquets INPUT di default

iptables -t filter -P INPUT DROP

allora si dovrà accettare INPUT per la porta ssh e la richiesta DNS

iptables -t filter -A INPUT -p tcp --dport 53 -j ACCEPT
iptables -t filter -A INPUT -p udp --dport 53 -j ACCEPT
1
1
1
2016-10-24 21:49:02 +0000

Recentemente ho trovato un'altra causa di login ssh lento.

Anche se avete UseDNS no in /etc/sshd_config, sshd può ancora eseguire ricerche DNS inverse se /etc/hosts.deny ha una voce come:

nnn-nnn-nnn-nnn.rev.some.domain.com

Questo potrebbe accadere se hai DenyHosts installato nel tuo sistema.

Sarebbe bello se qualcuno sapesse come fare in modo che DenyHosts eviti di mettere questo tipo di voce in /etc/hosts.deny.

Qui c'è un link, alla DenyHosts FAQ , su come rimuovere le voci da /etc/hosts.deny - vedi How can I remove an IP address that DenyHosts blocked?

1
1
1
2016-07-13 22:35:37 +0000

Ho scoperto che riavviare systemd-logind.service ha curato il problema solo per qualche ora. Cambiare UsePAM da sì a no in sshd\config ha portato a login veloci, anche se motd non viene più visualizzato. Commenti su problemi di sicurezza?

0
0
0
2015-05-21 13:01:07 +0000

Per me c'era un problema nel mio file locale /etc/hosts. Quindi ssh stava provando due diversi IP (uno sbagliato) che ci metteva un'eternità a fare time-out.

usando ssh -v ha fatto il trucco qui:

$ ssh -vvv remotesrv
OpenSSH_6.7p1 Debian-5, OpenSSL 1.0.1k 8 Jan 2015
debug1: Reading configuration data /home/mathieu/.ssh/config
debug1: /home/mathieu/.ssh/config line 60: Applying options for remotesrv
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to remotesrv [192.168.0.10] port 22.
debug1: connect to address 192.168.0.10 port 22: Connection timed out
debug1: Connecting to remotesrv [192.168.0.26] port 22.
debug1: Connection established.
0
0
0
2014-08-28 11:41:40 +0000

Per me avevo bisogno di GSSAPI, e non volevo disattivare i lookup DNS inversi. Non mi sembrava una buona idea, così ho controllato la pagina principale di resolv.conf. Si è scoperto che un firewall tra me e i server a cui stavo facendo SSH, stava interferendo con le richieste DNS, perché non erano in una forma che il firewall si aspettava. Alla fine, tutto quello che dovevo fare era aggiungere questa linea a resolv.conf sui server a cui stavo facendo SSH:

options single-request-reopen

0
0
0
2016-12-13 17:07:11 +0000

Notevolmente, un aggiornamento del pacchetto di bind su CentOS 7 ha rotto named, dichiarando ora nel log che /etc/named.conf ha un problema di permessi. Aveva funzionato bene per mesi con la 0640. Ora vuole 0644. Questo ha senso perché il demone named appartiene all'utente “named”.

Con named fuori uso tutto era lento, dai login ssh al servizio di pagine dal server web locale, applicazioni LAMP lente, ecc, molto probabilmente perché ogni richiesta andava in time out sul server locale morto prima di cercare un DNS esterno secondario configurato.