Nota: questo è iniziato come un tutorial "Come eseguire il debug", ma alla fine è stata la soluzione che mi ha aiutato su un server Ubuntu 16.04 LTS.
TLDR : esegui landscape-sysinfoe controlla se quel comando impiega molto tempo per terminare; è la stampa delle informazioni di sistema su un nuovo login SSH. Si noti che questo comando non è disponibile su tutti i sistemi, il landscape-commonpacchetto lo installa. ("Ma aspetta, c'è di più ...")
Avviare un secondo server SSH su un'altra porta sulla macchina che presenta il problema, farlo in modalità debug, che non lo farà fork e stamperà i messaggi di debug:
sudo /usr/sbin/sshd -ddd -p 44321
connettersi a quel server da un'altra macchina in modalità dettagliata:
ssh -vvv -p 44321 username@server
Il mio client genera le seguenti righe subito prima di iniziare a dormire:
debug1: Entering interactive session.
debug1: pledge: network
Googling che non è davvero 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 yesa UsePAM noquesto problema viene risolto.
Non correlato UseDNSo qualsiasi altra impostazione, UsePAMriguarda solo questo problema sul mio sistema.
Non ho nessuna idea perché, e non sto lasciando anche UsePAMa no, perché non so che gli effetti collaterali sono, ma questo mi permette di continuare a indagare.
Quindi, per favore, non considerare questa come una risposta, ma un primo passo per iniziare a scoprire cosa c'è che non va.
Quindi ho continuato a indagare e ho corso sshdcon strace( sudo strace /usr/sbin/sshd -ddd -p 44321). Ciò ha prodotto quanto segue:
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.dmi ha reso sospettoso, apparentemente il processo attende il risultato delle cose che si trovano/etc/update-motd.d
Quindi ho cdinserito /etc/update-motd.de eseguito un sudo chmod -x *comando per impedire a PAM di eseguire tutti i file che generano questa dinamica Message Of The Day, che include il caricamento del 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 molto lavoro da fare 24 ore su 24, 7 giorni su 7, quindi penso che raccogliere tutti questi dati motd sia stato troppo per questo.
Potrei iniziare ad abilitare gli script in quella cartella in modo selettivo, per vedere quali sono meno dannosi, ma specialmente la chiamata landscape-sysinfoè molto lenta e 50-landscape-sysinfochiama quel comando. Penso che sia quello che causa il ritardo maggiore.
Dopo riattivazione maggior parte dei file sono arrivato alla conclusione che
50-landscape-sysinfoe 99-esmerano la causa per i miei guai. 50-landscape-sysinfoci sono voluti circa 5 secondi per l'esecuzione e 99-esmcirca 3 secondi. Tutti i file rimanenti circa 2 secondi complessivamente.
Né 50-landscape-sysinfoe 99-esmsono cruciali. 50-landscape-sysinfostampa statistiche di sistema interessanti (e anche se hai poco spazio!) e 99-esmstampa messaggi relativi aUbuntu Extended Security Maintenance
Finalmente puoi creare uno script con echo '/usr/bin/landscape-sysinfo' > info.sh && chmod +x info.she ottenere quella stampa su richiesta.