Nota: Isso começou como um tutorial "Como depurar", mas acabou sendo a solução que me ajudou em um servidor Ubuntu 16.04 LTS.
TLDR : execute landscape-sysinfoe verifique se esse comando leva muito tempo para terminar; é a impressão das informações do sistema em um novo login SSH. Observe que este comando não está disponível em todos os sistemas, o landscape-commonpacote o instala. ("Mas espere, tem mais ...")
Inicie um segundo servidor ssh em outra porta na máquina com o problema, faça-o no modo de depuração, o que não tornará a bifurcação e imprimirá as mensagens de depuração:
sudo /usr/sbin/sshd -ddd -p 44321
conecte-se a esse servidor a partir de outra máquina no modo detalhado:
ssh -vvv -p 44321 username@server
Meu cliente gera as seguintes linhas antes de começar a dormir:
debug1: Entering interactive session.
debug1: pledge: network
Pesquisando no Google realmente não é útil, mas os logs do servidor são melhores:
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
Percebi que, quando mudo UsePAM yespara UsePAM no, esse problema é resolvido.
Não relacionado a UseDNSou a nenhuma outra configuração, UsePAMafeta apenas esse problema no meu sistema.
Eu não tenho idéia por que, e eu também não vou sair UsePAMem no, porque eu não sei quais os efeitos colaterais são, mas isso me permite continuar investigando.
Portanto, não considere que isso seja uma resposta, mas um primeiro passo para começar a descobrir o que há de errado.
Então continuei investigando e corri sshdcom strace( sudo strace /usr/sbin/sshd -ddd -p 44321). Isso produziu o seguinte:
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
A linha /etc/update-motd.dme deixou desconfiada, aparentemente o processo aguarda o resultado das coisas que estão em/etc/update-motd.d
Então eu cd'd em /etc/update-motd.de passou a sudo chmod -x *fim de inibir a PAM para executar todos os arquivos que geram essa dinâmica Message Of The Day, que inclui carga do sistema e se os pacotes precisam ser atualizados, e isso resolveu o problema.
Este é um servidor baseado em uma CPU N3150 "com baixo consumo de energia", que tem muito trabalho a ser feito 24 horas por dia, sete dias por semana, por isso acho que coletar todos esses dados motd foi demais para isso.
Posso começar a habilitar scripts nessa pasta seletivamente, para ver quais são menos prejudiciais, mas a chamada especialmente landscape-sysinfoé muito lenta e 50-landscape-sysinfochama esse comando. Eu acho que é o que causa o maior atraso.
Depois de reativar a maioria dos arquivos cheguei à conclusão de que
50-landscape-sysinfoe 99-esmforam a causa de meus problemas. 50-landscape-sysinfodemorou cerca de 5 segundos para executar e 99-esmcerca de 3 segundos. Todos os arquivos restantes duram cerca de 2 segundos.
Nem 50-landscape-sysinfoe 99-esmsão cruciais. 50-landscape-sysinfoimprime estatísticas interessantes do sistema (e também se você estiver com pouco espaço!) e 99-esmimprime mensagens relacionadas aUbuntu Extended Security Maintenance
Finalmente, você pode criar um script echo '/usr/bin/landscape-sysinfo' > info.sh && chmod +x info.she obter essa impressão mediante solicitação.