Porque é que o meu login no SSH é lento?

Tente definir UseDNS a no em /etc/sshd_config ou /etc/ssh/sshd_config.

Quando corri ssh -vvv num servidor com um desempenho lento semelhante, vi um enforcamento aqui:

debug1: Next authentication method: gssapi-with-mic

Ao editar /etc/ssh/ssh_config e ao comentar esse método de autenticação consegui que o desempenho de login voltasse ao normal. Aqui está o que tenho no meu /etc/ssh/ssh_config no servidor:

GSSAPIAuthentication no

Pode definir isto globalmente no servidor, pelo que não aceita GSSAPI para autenticar. Basta adicionar GSSAPIAuthentication no a /etc/ssh/sshd_config no servidor e reiniciar o serviço.

Para mim, o culpado era a resolução IPv6, era o timing out. (Má configuração do DNS no meu fornecedor anfitrião, acho eu.) Descobri isto ao fazer ssh -v, o que mostrou que passo estava pendurado.

A solução é ssh com a opção -4:

ssh -4 me@myserver.com

Com o systemd, o login pode ficar pendurado na comunicação dbus com logind após algumas actualizações, depois precisa de reiniciar o logind

systemctl restart systemd-logind

Viu que no debian 8, arch linx, e numa lista suse

Pode sempre começar ssh com a opção -v que mostra o que está a ser feito neste momento.

$ ssh -v you@host

Com a informação que deu, posso apenas sugerir algumas configurações do lado do cliente:

• Uma vez que escreve que está a introduzir passwords manualmente, sugiro que utilize autenticação de chave pública, se possível. Isto remove-o como um estrangulamento de velocidade.

& - Poderá também desactivar o reencaminhamento X com -x e o reencaminhamento de autenticação com -a (estes podem já estar desactivados por defeito). Especialmente desactivar o reencaminhamento X pode dar-lhe uma grande melhoria de velocidade se o seu cliente precisar de iniciar um servidor X para o comando ssh (por exemplo, sob OS X).

Tudo o resto depende realmente de que tipo de atrasos experimenta, onde e quando.

Em relação ao ponto 2., aqui está uma resposta que não requer modificação do servidor nem privilégios de raiz/administrativos.

Necessita de editar o seu ficheiro “user ssh_config” que é:

vi $HOME/.ssh/config

(Nota: teria de criar o directório $HOME/.ssh se este não existir)

E adicionar:

Host *
  GSSAPIAuthentication no
  GSSAPIDelegateCredentials yes

Pode fazê-lo numa base por anfitrião, se necessário :) exemplo:

Host linux-srv
  HostName 192.158.1.1
  GSSAPIAuthentication no
  GSSAPIDelegateCredentials yes

Certifique-se de que o endereço IP corresponde ao IP do seu servidor. Uma vantagem interessante é que agora o ssh irá fornecer o autocompletar para este servidor. Assim pode digitar ssh lin + Tab e deve autocompletar para ssh linux-srv.

Verifique /etc/resolv.conf no servidor para ter a certeza de que o servidor DNS, listado neste ficheiro, funciona bem, e apague qualquer DNS que não funcione.

Por vezes é muito útil.

Para além das questões DNS já mencionadas, se estiver a entrar num servidor com muitas montagens NFS, então pode haver um atraso entre a palavra-passe e o prompt, uma vez que o comando quota verifica a sua utilização/quota em todos os sistemas de ficheiros não montados com o noquota. Nos sistemas Solaris, pode ver isto no /etc/profile padrão e ignorá-lo executando o touch $HOME/.hushlogin .

Se nenhuma das respostas acima funcionar e estiver a enfrentar problemas de pesquisa inversa, pode também verificar se o daemon nscd (name service cache daemon) está instalado e a funcionar.

Se é este o problema é porque não tem a cache dns, e cada vez que consulta um nome de anfitrião que não está no seu ficheiro de anfitrião, envia a pergunta para o seu servidor de nomes em vez de procurar na sua cache

tentei todas as opções acima e a única alteração que funcionou foi iniciar nscd.

Deverá também verificar a ordem para fazer a resolução da consulta dns em /etc/nsswitch.conf para utilizar primeiro o ficheiro de anfitrião.

Isto é provavelmente apenas específico do OpenSSH Debian/Ubuntu, que inclui o user-group-modes.patch escrito por um dos mantenedores do pacote Debian. Este patch permite que os ficheiros ~/.ssh tenham o bit gravável do grupo (g+w) definido se houver apenas um utilizador com o mesmo gid que o do ficheiro. A função de segurança do patch_permissões() faz esta verificação. Uma das fases da verificação é passar por cada entrada passwd usando getpwent() e comparar o gid da entrada com o gid do ficheiro.

Num sistema com muitas entradas e/ou autenticação NIS/LDAP lenta, esta verificação será lenta. nscd não guarda as chamadas getpwent(), por isso cada entrada de senha será lida através da rede se o servidor não for local. No sistema encontrei isto, adicionou cerca de 4 segundos para cada invocação de ssh ou login no sistema.

A correcção é remover o bit gravável em todos os ficheiros em ~/.ssh, fazendo chmod g-w ~/.ssh/*.

Nota: Isto começou como um “Como depurar”, tutorial, mas acabou por ser a solução que me ajudou num Ubuntu 16.04 servidor LTS.

TLDR* : Executar landscape-sysinfo e verificar se esse comando leva muito tempo a terminar; é a impressão da informação do sistema num novo login SSH. Note-se que este comando não está disponível em todos os sistemas, o pacote landscape-common instala-o. (“Mas espera, há mais…”)

Iniciar um segundo servidor ssh noutra porta da máquina que tenha o problema, fazê-lo em modo de depuração, o que não o fará fork e imprimirá mensagens de depuração:

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

ligar a esse servidor a partir de outra máquina em modo verboso:

ssh -vvv -p 44321 username@server

O meu cliente emite as seguintes linhas mesmo antes de começar a dormir:

debug1: Entering interactive session.
debug1: pledge: network

Googling que não é realmente útil, mas os registos 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

Notei que quando mudo UsePAM yes para UsePAM no então esta questão está resolvida.

Não relacionado com UseDNS ou qualquer outra configuração, apenas UsePAM afecta este problema no meu sistema.

não faço ideia porquê, e também não vou deixar UsePAM em no, porque não sei quais são os efeitos secundários, mas isto permite-me continuar a investigar.

Portanto, por favor não considere isto como uma resposta, mas como um primeiro passo para começar a descobrir o que está errado.

Assim, continuei a investigar, e corri sshd com strace (sudo strace /usr/sbin/sshd -ddd -p 44321). Isto 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.d fez-me suspeitar, aparentemente o processo espera pelo resultado do material que está em /etc/update-motd.d

Então eu cd‘d into /etc/update-motd.d e corri um sudo chmod -x * para inibir o PAM de correr todos os ficheiros que geram esta dinâmica Message Of The Day, o que inclui a carga do sistema e se os pacotes precisam de ser actualizados, e isto resolveu o problema.

Este é um servidor baseado num CPU N3150 “energeticamente eficiente” que tem muito trabalho para fazer 24/7, por isso penso que recolher todos estes dados motd era demasiado para ele.

Posso começar a activar os scripts nessa pasta selectivamente, para ver quais são menos nocivos, mas especialmente chamar landscape-sysinfo é muito lento, e 50-landscape-sysinfo chama esse comando. Penso que é o que causa o maior atraso.

Depois de reactivar a maioria dos ficheiros cheguei à conclusão de que 50-landscape-sysinfo e 99-esm foram a causa dos meus problemas. 50-landscape-sysinfo levou cerca de 5 segundos a executar e 99-esm cerca de 3 segundos. Todos os restantes ficheiros demoraram cerca de 2 segundos no total.

nem 50-landscape-sysinfo e 99-esm são cruciais. 50-landscape-sysinfo imprime estatísticas interessantes do sistema (e também se tiver pouco espaço!), e 99-esm imprime mensagens relacionadas com Ubuntu Extended Security Maintenance

Finalmente, pode criar um guião com echo '/usr/bin/landscape-sysinfo' > info.sh && chmod +x info.sh e obter essa impressão a pedido.

tentei todas as respostas mas nenhuma delas funcionou. finalmente descobri o meu problema:

primeiro corro sudo tail -f /var/log/auth.log para poder ver o log do ssh depois noutra sessão correr ssh 172.16.111.166 e reparei à espera em

/usr/bin/sss_ssh_knownhostsproxy -p 22 172.16.111.166

depois de procurar localizei esta linha em /etc/ssd/ssh_config

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

comentei e o atraso desapareceu

Trabalhar bem.

# 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 não trabalhe com OpenIndiana!!!

Leia “man sshd_config” para todas as opções

“LookupClientHostnames no” se o seu servidor não consegue resolver

ssh -vvv a ligação correu muito bem até ficar pendurada no sistema tentando obter o terminal durante pelo menos 20 Segundos:

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

Depois de fazer uma systemctl restart systemd-logind no servidor tive de novo uma ligação instantânea!

Isto foi em debian8*! Então o problema aqui era o sistemad!

Nota: Bastien Durel já deu uma resposta para este problema, no entanto falta-lhe a informação de debug. Espero que isto seja útil para alguém.

Podemos descobrir que o método preferido de resolução de nomes não é o ficheiro hospedeiro e depois o DNS.

Por exemplo, esta seria a configuração habitual:

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

Primeiro, o ficheiro anfitrião é atingido (opção: ficheiros) e depois o DNS (opção: dns), contudo, podemos descobrir que foi adicionado outro sistema de resolução de nomes que não está operacional e está a causar-nos a lentidão em tentar fazer a resolução inversa.

Se a ordem de resolução do nome não estiver correcta, pode alterá-la em: /etc/nsswitch.conf

Extraído de: http://www.sysadmit.com/2017/07/linux-ssh-login-lento.html

Este fio já está a fornecer um monte de soluções, mas a minha não é dada aqui =). Portanto, aqui está ele. O meu problema (demorou cerca de 1 minuto a entrar no ssh no meu pi de framboesa), foi devido a um ficheiro .bash_history corrompido. Uma vez que o ficheiro é lido no início de sessão, isto estava a causar o atraso no início de sessão. Uma vez removido o ficheiro, o tempo de início de sessão voltou ao normal, como se fosse instantâneo.

Espero que isto ajude algumas outras pessoas.

Para completar todas as respostas que mostram que as resoluções DNS podem atrasar o seu login ssh, por vezes, falta uma regra de firewall. Por exemplo, se você DROPAR todos os paquetes INPUT por defeito

iptables -t filter -P INPUT DROP

então terá de aceitar INPUT para porta ssh e pedido DNS

iptables -t filter -A INPUT -p tcp --dport 53 -j ACCEPT
iptables -t filter -A INPUT -p udp --dport 53 -j ACCEPT

Recentemente encontrei outra causa de lentidão dos logins ssh.

Mesmo que tenha UseDNS no em /etc/sshd_config, o sshd pode ainda assim efectuar pesquisas DNS invertidas se o /etc/hosts.deny tiver uma entrada semelhante:

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

Isso pode acontecer se tiver DenyHosts instalado no seu sistema.

Seria óptimo se alguém soubesse como fazer o DenyHosts evitar colocar este tipo de entrada em /etc/hosts.deny.

Aqui está um link, para a DenyHosts FAQ , sobre como remover entradas de /etc/hosts.deny - ver Como posso remover um endereço IP que DenyHosts bloqueou?

Descobri que o reinício do systemd-logind.service apenas curou o problema durante algumas horas. A alteração do UsePAM de sim para não no sshd_config resultou em logins rápidos, embora o motd já não seja exibido. Comentários sobre questões de segurança?

Para mim havia um problema no meu ficheiro local /etc/hosts. Assim, o ssh estava a tentar dois IP diferentes (um errado) que demorou uma eternidade a ficar sem tempo.

usando ssh -v fez o truque aqui:

$ 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.

Para mim precisava de GSSAPI, e não queria desligar as pesquisas DNS invertidas. Isso não me pareceu uma boa ideia, por isso verifiquei a página principal para resolv.conf. Acontece que uma firewall entre mim e os servidores para os quais eu estava a SSHing, estava a interferir com os pedidos DNS, porque eles não estavam numa forma que a firewall esperava. No final, tudo o que precisava de fazer era adicionar esta linha ao resolv.conf nos servidores para os quais eu era o SSHing:

options single-request-reopen

Notavelmente, um pacote de actualização do bind no CentOS 7 partiu-se, declarando agora no registo que o /etc/named.conf tinha um problema de permissões. Tinha funcionado bem durante meses com 0640. Agora quer 0644. Isto faz sentido uma vez que o daemon nomeado pertence ao utilizador ‘nomeado’.

Com named down tudo era lento, desde logins ssh a páginas servidas a partir do servidor web local, aplicações LAMP lentas, etc., muito provavelmente porque cada pedido iria demorar no servidor local morto antes de olhar para um DNS externo, secundário que está configurado.