Tente definir UseDNS como no em /etc/sshd_config ou /etc/ssh/sshd_config .
Estou vendo atrasos nos logins do SSH. Especificamente, há dois pontos em que vejo um intervalo de atrasos instantâneos a vários segundos.
Agora, especificamente estou vendo detalhes do ssh somente aqui. Obviamente, latência de rede, velocidade do hardware e sistemas operacionais envolvidos, scripts de login complexos, etc, podem causar atrasos. Para o contexto eu ssh para uma vasta variedade de distribuições linux e alguns hosts Solaris usando principalmente Ubuntu, CentOS e MacOS X como meus sistemas cliente. Quase o tempo todo, a configuração do servidor ssh não é alterada das configurações padrão do sistema operacional.
Quais configurações do servidor ssh devo me interessar? Existem parâmetros do sistema operacional / kernel que podem ser ajustados? Truques de shell de login? Etc?
Quando eu executei ssh -vvv em um servidor com um desempenho lento semelhante, vi um travamento aqui:
debug1: Next authentication method: gssapi-with-mic
Ao editar /etc/ssh/ssh_config e comentar esse método de autenticação, o desempenho de login voltou ao normal. Aqui está o que eu tenho no meu /etc/ssh/ssh_config no servidor:
GSSAPIAuthentication no
Você pode definir isso globalmente no servidor, por isso 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 foi a resolução IPv6, que estava expirando. (Configuração incorreta de DNS no meu provedor de hospedagem, eu acho). Eu descobri isso fazendo ssh -v , que mostrava qual etapa estava pendente.
A solução é ssh com a opção -4 :
ssh -4 [email protected]
Com o 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, no arch linx e em uma lista de suse
Você sempre pode iniciar ssh com a opção -v , que exibe o que está sendo feito no momento.
$ ssh -v you@host
Com as informações fornecidas, posso sugerir apenas algumas configurações do lado do cliente:
Como você escreve que está inserindo senhas manualmente, sugiro que use a autenticação de chave pública, se possível. Isso remove você como um afunilamento de velocidade.
Você também pode desabilitar o encaminhamento de X com -x e o encaminhamento de autenticação com -a (eles podem já estar desabilitados por padrão). Especialmente, desabilitar o X-forwarding pode proporcionar uma grande melhoria de velocidade se o cliente precisar iniciar um X-server para o comando ssh (por exemplo, no OS X).
Tudo depende dos tipos de atraso que você sente quando e onde.
Em relação ao ponto 2., aqui está uma resposta que não requer modificar o servidor nem requer privilégios root / administrativos.
Você precisa editar o arquivo "user ssh_config" que é:
vi $HOME/.ssh/config
(Nota: você teria que criar o diretório $ HOME / .ssh se ele não existe)
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 seu IP do servidor. Uma vantagem interessante é que agora o ssh fornecerá autocomplete para este servidor. Assim, você pode digitar ssh lin + Tab e preencher automaticamente para ssh linux-srv .
Verifique /etc/resolv.conf no servidor para ter certeza de que o servidor DNS, listado neste arquivo, funciona 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 executando ssh em um servidor com muitas montagens NFS, poderá haver um atraso entre a senha e o prompt, pois o comando quota verificará seu uso / cota em todos os sistemas de arquivos não montado com o noquota . Nos sistemas Solaris, você pode ver isso no padrão /etc/profile e ignorá-lo executando touch $HOME/.hushlogin .
Trabalhe 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 trabalha com OpenIndiana !!!
Leia "man sshd_config" para todas as opções
"LookupClientHostnames no" se o seu servidor não puder resolver
Se nenhuma das respostas acima funcionar e você estiver enfrentando problemas de pesquisa inversa do DNS, você também pode verificar se nscd (serviço de nome de cache) está instalado e em execução.
Se este é o problema, é porque você não tem cache de dns, e toda vez que você consulta um nome de host que não está em seu hostfile, você envia a pergunta para seu servidor de nomes em vez de procurar em seu cache
Eu tentei todas as opções acima e a única mudança que funcionou foi iniciar nscd .
Você também deve verificar o pedido para tornar a resolução de consulta do DNS em /etc/nsswitch.conf para usar o arquivo de hosts primeiro.
Isto é provavelmente apenas específico para o Debian / Ubuntu OpenSSH, que inclui o user-group-modes.patch escrito por um dos mantenedores do pacote Debian. Este patch permite que os arquivos ~ / .ssh tenham o grupo gravável bit set (g + w) se houver apenas um usuário com o mesmo gid que o arquivo. A função secure_permissions () do patch faz esta verificação. Uma das fases da verificação é percorrer cada entrada passwd usando getpwent () e comparar o gid da entrada com o gid do arquivo.
Em um sistema com muitas entradas e / ou autenticação lenta NIS / LDAP, esta verificação será lenta. O nscd não armazena em cache as chamadas getpwent (), portanto todas as entradas passwd serão lidas pela rede se o servidor não for local. No sistema eu achei isso, ele adicionou cerca de 4 segundos para cada invocação do ssh ou login no sistema.
A correção é remover o bit gravável em todos os arquivos em ~ / .ssh fazendo chmod g-w ~/.ssh/* .
Descobri que reiniciar o systemd-logind.service apenas curou o problema por algumas horas. Mudar o UsePAM de yes para no em sshd_config resultou em logins rápidos, embora o motd não seja mais exibido. Comentários sobre questões de segurança?
Para completar todas as respostas mostrando que as resoluções DNS podem retardar seu login ssh, às vezes, falta uma regra de firewall. Por exemplo, se você DROP todos os pacotes 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 foi muito bem até que ficou pendurada 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 em debian8 ! Então systemd foi a questão aqui!
Nota: Bastien Durel já deu uma resposta para esta questão, no entanto, falta-lhe a informação 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 no em /etc/sshd_config , o sshd ainda poderá realizar pesquisas reversas de DNS se /etc/hosts.deny tiver uma entrada como:
nnn-nnn-nnn-nnn.rev.some.domain.com
Isso pode acontecer se você tiver DenyHosts instalado em seu sistema.
Seria ótimo se alguém soubesse como fazer com que o DenyHosts evitasse esse tipo de entrada em /etc/hosts.deny .
Aqui está um link, para a FAQ do DenyHosts , sobre como remover entradas de /etc/hosts.deny - consulte Como posso remover um endereço IP que o DenyHosts bloqueou?
Podemos descobrir que o método de resolução de nome preferido não é o arquivo host e, em seguida, 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 é alcançado (opção: arquivos) e, em seguida, DNS (opção: dns), no entanto, podemos encontrar outro sistema de resolução de nomes que não está operacional e está causando lentidão na tentativa de fazer o resolução inversa.
Se a ordem de resolução de nomes não estiver correta, você poderá alterá-la em: /etc/nsswitch.conf
Extraído de: link
Este tópico já está fornecendo várias soluções, mas o meu não é fornecido aqui =). Então aqui está. Meu problema (levou cerca de 1 minuto para o login do ssh no meu pi de framboesa), foi devido a um arquivo .bash_history corrompido. Como o arquivo é lido no login, isso estava causando o atraso de login. Depois que removi o arquivo, o tempo de login voltou ao normal, como instantâneo.
Espero que isso ajude outras pessoas.
Felicidades
Para mim, eu precisava do GSSAPI e não queria desativar as pesquisas reversas de DNS. Isso não parece uma boa idéia, então eu verifiquei a página principal do resolv.conf. Acontece que um firewall entre mim e os servidores para os quais eu estava usando o SSHing estava interferindo nas solicitações de DNS, porque elas não estavam na forma esperada pelo firewall. No final, tudo que eu precisava fazer era adicionar essa linha ao resolv.conf nos servidores que eu estava usando o SSHing:
options single-request-reopen
Para mim, houve um problema no meu arquivo /etc/hosts . Então ssh estava tentando dois IPs diferentes (um errado) que levaram uma eternidade para expirar.
Usar ssh -v foi 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.
Notavelmente, uma atualização de pacote de ligação no CentOS 7 quebrou o nome, agora declarando no log que /etc/named.conf tinha um problema de permissões. Ele funcionou bem durante meses com 0640. Agora ele quer 0644. Isso faz sentido, pois o daemon nomeado pertence ao usuário 'nomeado'.
Com o named down, tudo ficou lento, de logins ssh para página servindo do servidor web local, aplicativos LAMP lentos etc., muito provavelmente porque cada requisição expiraria no servidor local morto antes de procurar por um DNS secundário externo configurado.
Eu tentei todas as respostas, mas nenhuma delas funcionou. finalmente eu descubro o meu problema:
primeiro corro sudo tail -f /var/log/auth.log
então eu posso ver o log do ssh
em seguida, em outra sessão, execute ssh 172.16.111.166 e observe a espera em
/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 passou
Tags performance ssh login solaris linux