Por que meu login SSH é lento?

Estou vendo atrasos nos logins SSH. Especificamente, existem dois pontos em que vejo uma variação de atrasos instantâneos a vários segundos.

1. Entre emitir o comando ssh e obter um prompt de login e
2. entre digitar a senha e ter o shell carregado

Agora, especificamente, estou vendo detalhes ssh apenas aqui. Obviamente, a latência da rede, a velocidade do hardware e dos sistemas operacionais envolvidos, scripts de login complexos etc. podem causar atrasos. Para o contexto, eu ssh para uma grande variedade de distribuições linux e alguns hosts Solaris usando principalmente Ubuntu, CentOS e MacOS X como meus sistemas clientes. Quase o tempo todo, a configuração do servidor ssh permanece inalterada em relação às configurações padrão do sistema operacional.

Em quais configurações de servidor ssh devo me interessar? Existem parâmetros de SO / kernel que podem ser ajustados? Truques de shell de login? Etc?

Tente configurar UseDNSa noem /etc/sshd_configou /etc/ssh/sshd_config.

Quando executei ssh -vvvem um servidor com desempenho lento semelhante, vi um travar aqui:

debug1: Next authentication method: gssapi-with-mic

Ao editar /etc/ssh/ssh_confige comentar esse método de autenticação, obtive o desempenho do login de volta ao normal. Aqui está o que eu tenho no meu /etc/ssh/ssh_configservidor:

GSSAPIAuthentication no

Você pode configurá-lo globalmente no servidor, para que ele não aceite o GSSAPI para autenticação. Basta adicionar GSSAPIAuthentication noa /etc/ssh/sshd_configno servidor e reiniciar o serviço.

Para mim, o culpado era a resolução IPv6, estava chegando ao tempo limite. (Configuração ruim de DNS no meu provedor de host, eu acho.) Descobri isso fazendo ssh -v, o que mostrava qual etapa estava travando.

A solução é sshcom a -4opção:

ssh -4 [email protected]

Com systemd, o login pode travar na comunicação do dbus com o logind após algumas atualizações, então você precisa reiniciar o logind

systemctl restart systemd-logind

Vi isso no debian 8, arch linx e em uma lista de suse

Você sempre pode começar sshcom a -vopção que exibe o que está sendo feito no momento.

$ ssh -v you@host

Com as informações que você forneceu, só posso sugerir algumas configurações do lado do cliente:

• Como você escreve que está inserindo senhas manualmente, sugiro que você use a autenticação de chave pública, se possível. Isso remove você como um gargalo de velocidade.

• Você também pode desativar o encaminhamento X com o encaminhamento de -xautenticação com -a(eles já podem estar desativados por padrão). Desabilitar o encaminhamento de X especialmente pode oferecer uma grande melhoria de velocidade se o seu cliente precisar iniciar um servidor X para o sshcomando (por exemplo, no OS X).

Todo o resto depende realmente de que tipo de atraso você experimenta onde e quando.

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

Você precisa editar o arquivo "user ssh_config", que é:

vi $HOME/.ssh/config

(Nota: você precisaria criar o diretório $ HOME / .ssh se ele não existir)

E adicione:

Host *
  GSSAPIAuthentication no
  GSSAPIDelegateCredentials yes

Você pode fazer isso por host, se necessário :) exemplo:

Host linux-srv
  HostName 192.158.1.1
  GSSAPIAuthentication no
  GSSAPIDelegateCredentials yes

Verifique se o endereço IP corresponde ao IP do servidor. Uma vantagem interessante é que agora o ssh fornecerá o preenchimento automático para este servidor. Então você pode digitar ssh lin+ Tabe ele deve ser preenchido automaticamente ssh linux-srv.

Verifique /etc/resolv.confno servidor para garantir que o servidor DNS listado neste arquivo funcione bem e exclua qualquer DNS que não esteja funcionando.

Às vezes é muito útil.

Além dos problemas de DNS já mencionados, se você estiver transferindo para um servidor com muitas montagens NFS, pode haver um atraso entre a senha e o prompt, pois o quotacomando verifica seu uso / cota em todos os sistemas de arquivos não montados com o noquota. Nos sistemas Solaris, você pode ver isso no padrão /etc/profilee ignorá-lo executando touch $HOME/.hushlogin .

Funciona 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, não funciona com o OpenIndiana !!!

Leia "man sshd_config" para todas as opções

"LookupClientHostnames no" se o servidor não puder resolver

Se nenhuma das respostas acima funcionar e você estiver enfrentando problemas de pesquisa reversa do DNS, também poderá verificar se nscd(daemon de cache do serviço de nomes) está instalado e em execução.

Se esse é o problema, é porque você não possui cache de DNS e, toda vez que você consulta um nome de host que não esteja no seu arquivo de host, você envia a pergunta ao servidor de nomes em vez de procurar no cache

Tentei todas as opções acima e a única alteração que funcionou foi o início nscd.

Você também deve verificar a ordem de resolução da consulta DNS /etc/nsswitch.confpara usar o arquivo hosts primeiro.

Provavelmente isso é específico apenas para o Debian / Ubuntu OpenSSH, que inclui os modos de grupo de usuários.patch escritos por um dos mantenedores de pacotes Debian. Esse patch permite que os arquivos ~ / .ssh tenham o conjunto de bits graváveis ​​do grupo (g + w) se houver apenas um usuário com o mesmo gid que o arquivo. A função secure_permissions () do patch faz essa verificação. Uma das fases da verificação é passar por cada entrada de senha usando getpwent () e comparar o gid da entrada com o gid do arquivo.

Em um sistema com muitas entradas e / ou autenticação NIS / LDAP lenta, essa verificação será lenta. O nscd não armazena em cache as chamadas getpwent (), portanto, toda entrada de senha será lida pela rede se o servidor não for local. No sistema que encontrei, foram adicionados cerca de 4 segundos para cada chamada do ssh ou login no sistema.

A correção é remover o bit gravável em todos os arquivos em ~ / .ssh fazendo isso chmod g-w ~/.ssh/*.

Eu descobri que reiniciar o systemd-logind.service apenas curou o problema por algumas horas. Alterar o UsePAM de yes para no no sshd_config resultou em logins rápidos, embora o motd não seja mais exibido. Comentários sobre problemas de segurança?

Para concluir todas as respostas que mostram que as resoluções DNS podem retardar o seu login ssh, às vezes falta uma regra de firewall. Por exemplo, se você DROP todos os paquets INPUT por padrão

iptables -t filter -P INPUT DROP

então você terá que aceitar INPUT para porta ssh e solicitação de DNS

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

ssh -vvv a conexão funcionou muito bem até travar no sistema, tentando obter o terminal por pelo menos 20 segundos:

debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Requesting [email protected]
debug1: Entering interactive session.
... waiting ... waiting ... waiting

Depois de fazer um systemctl restart systemd-logind no servidor , tive conexão instantânea novamente!

Isso foi no debian8 ! Então systemd foi o problema aqui!

Nota: Bastien Durel já deu uma resposta para esse problema, no entanto, faltam as informações de depuração. Espero que isso seja útil para alguém.

Eu encontrei recentemente outra causa de logins ssh lentos.

Mesmo se você tiver UseDNS noparticipado /etc/sshd_config, o sshd ainda poderá realizar pesquisas reversas no DNS se /etc/hosts.denyhouver uma entrada como:

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

Isso pode acontecer se você tiver o DenyHosts instalado no seu sistema.

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

Aqui está um link, para as perguntas frequentes do DenyHosts , sobre como remover entradas de /etc/hosts.deny- consulte Como remover um endereço IP que o DenyHosts bloqueou?

Podemos achar que o método preferido de resolução de nomes não é o arquivo host e depois o DNS.

Por exemplo, essa seria a configuração usual:

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

Primeiro, o arquivo hosts é atingido (opção: arquivos) e depois o DNS (opção: dns), no entanto, podemos descobrir que foi adicionado outro sistema de resolução de nomes que não está operacional e está nos causando lentidão ao tentar executar a resolução reversa.

Se a ordem de resolução de nomes não estiver correta, você poderá alterá-la em: /etc/nsswitch.conf

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

Eu tentei todas as respostas, mas nenhuma delas funcionou. finalmente descubro o meu problema:

primeiro eu corro sudo tail -f /var/log/auth.log para poder ver o log do ssh e depois em outra sessão rodar ssh 172.16.111.166e notei esperando

/usr/bin/sss_ssh_knownhostsproxy -p 22 172.16.111.166

depois de pesquisar, localizei esta linha em / etc / ssd / ssh_config

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

Eu comentei e o atraso se foi

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.

Este tópico já está fornecendo várias soluções, mas o meu não é fornecido aqui =). Então aqui está. Meu problema (demorou cerca de 1 minuto para o login do ssh no meu raspberry pi) foi devido a um arquivo .bash_history corrompido. Como o arquivo é lido no login, isso estava causando o atraso do login. Depois que removi o arquivo, o tempo de login voltou ao normal, como instantâneo.

Espero que isso ajude outras pessoas.

Para mim, eu precisava do GSSAPI e não queria desativar as pesquisas reversas de DNS. Isso não parecia uma boa ideia, então verifiquei a página principal do resolv.conf. Acontece que um firewall entre mim e os servidores aos quais eu estava usando SSH estava interferindo nas solicitações de DNS, porque não estavam no formato esperado pelo firewall. No final, tudo o que eu precisava fazer era adicionar esta linha ao resolv.conf nos servidores aos quais eu estava SSH:

options single-request-reopenO que outras pessoas estão dizendo

Notavelmente, uma atualização do pacote de ligação no CentOS 7 quebrou o nome, agora declarando no log que /etc/named.conf teve um problema de permissão. Funcionou bem por meses com 0640. Agora ele quer 0644. Isso faz sentido, pois o daemon nomeado pertence ao usuário 'nomeado'.

Com o nome desativado, tudo ficou lento, desde logins ssh a páginas servindo a partir do servidor web local, aplicativos LAMP lentos, etc., provavelmente porque cada solicitação atingia o tempo limite no servidor local morto antes de procurar um DNS secundário externo configurado.

Para mim, houve um problema no meu /etc/hostsarquivo local . Então, sshestava tentando dois IP diferentes (um errado) que levaram uma eternidade para atingir o tempo limite.

Usando ssh -vfez 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.