Como acelerar meu login ssh muito lento?

42

Correr ssh user@hostnameleva ~ 30s. Aqui está o cenário:

esta é uma VM na LAN local
Máquinas Windows e Mac obtêm login instantâneo
estou usando o Debian e eu poderia me reproduzir com uma máquina Ubuntu
alguém usando o Ubuntu diz que fazer login na minha máquina (LAN local) também é instantâneo
o uso do endereço IP do nome do host leva cerca da metade do tempo (~ 15s)

[ atualização ]

Usando ssh -vvv user@hostname, aqui é onde espera mais:

debug3: authmethod_lookup gssapi-with-mic
debug3: remaining preferred: publickey,keyboard-interactive,password
debug3: authmethod_is_enabled gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic

E então espera um pouco aqui:

debug1: Unspecified GSS failure.  Minor code may provide more information
Credentials cache file '/tmp/krb5cc_1000' not found

debug1: Unspecified GSS failure.  Minor code may provide more information
Credentials cache file '/tmp/krb5cc_1000' not found

ssh

— tshepang
fonte

1

você usa autenticação por senha ou pubkey? e se senha, o arquivo a id_dsaou está id_rsano seu ~/.ssh? talvez sua instalação ssh tenta a autenticação errado em primeiro lugar e seu servidor não nega, mas simplesmente ignorar essa solicitação, resultando em que 30s tempo limite

— Tobias KIENZLER

@tobias Eu uso senha e não tenho "~/.ssh"arquivo. Esse é um diretório e só possui "known_hosts"arquivos.

— tshepang 10/01

5

Parece que você tem um tempo limite de DNS de 15 anos. Talvez o servidor esteja fazendo uma pesquisa de DNS; se puder, verifique se está UseDNS nono sshd_configservidor. De qualquer forma, execute ssh -vvv user@hostnamepara ver onde o logon está suspenso.

— Gilles 'pare de ser mau'

@gil Obrigado. Eu atualizei a pergunta. Vou pedir ao administrador para verificar essa configuração do UseDNS .

— tshepang

3

@Tshepang: Ah, você está usando a autenticação Kerberos (GSSAPI). Eu não estou familiarizado com isso. Se estiver mal configurado, talvez esteja causando o atraso. Isso é algo que você pode perguntar ao seu administrador. DNS pode ser um arenque vermelho; é a causa mais comum na natureza, mas talvez o seu problema seja diferente.

— Gilles 'SO- stop be evil'

32

Edite seu " / etc / ssh / ssh_config " e comente estas linhas:

GSSAPIAuthentication yes
GSSAPIDelegateCredentials no

— Alvaro Araos
fonte

3

+1 Boa resposta! (1) É uma velocidade normal para a conexão de login ssh levar o tempo que o cursor pisca 7 vezes? (2) Por que funciona comentando GSSAPIAuthentication yese GSSAPIDelegateCredentials no? @Tshepang

— Tim

@ Tim (1) é muito longo ... dependendo da conexão, não espero que demore mais de 2 segundos; (2) Eu não tenho idéia, só que ele funciona

— tshepang

1

O padrão para GSSAPIAuthentication na maioria das versões do OpenSSH é "não", mas algumas distribuições o definem como "yes" nos arquivos sshd_config e ssh_config. Se você não precisar / usá-lo, isso diminui a velocidade do handshake de conexão / autenticação.

— tgharold

Se a autenticação LDAP / AD estiver em uso, a desativação do GSSAPI não fará com que uma ligação simples seja usada, potencialmente enviando senhas pela rede em texto sem formatação?

— Shannon

Verifique se todos os servidores de nomes ainda existem no /etc/resolv.conf. Se não, tire-os. Isso resolveu meu problema.

— technocrat

30

Eu tive esse problema e resolvi-o desativando a resolução de DNS reverso no SSH.

Então, sshd_configno servidor, mude isso:

 #UseDNS yes

para isso:

UseDNS no

— Earlz
fonte

1

Fiz a alteração (apesar de não ter a opção UseDNS comentada ), redefini meu servidor ssh e ainda o mesmo problema.

— tshepang

2

@ Hmm, estranho. Os únicos problemas de velocidade que já tive com o SSH foram devido a isso.

— Earlz 22/01

1

Fiquei cético ao usar o endereço IP (LAN local), mas essa solução corrigiu meu problema. Pelo bem do Google, embora estivesse ocorrendo logo após, o atraso não teve nada a ver com a mensagem "key: /home/mylogin/.ssh/id_ecdsa ((nil))" (em execução ssh -vvv).

— Skippy le Grand Gourou

7

Você verificou sua configuração de DNS?

Experimente a definição mdns offem /etc/host.conf.

Isso desativa a resolução mdns e me ajudou muito.

EDITAR:

Parece que o gentoo está lidando com isso um pouco diferente. Para desativar as pesquisas DNS multicast, é necessário alterar o arquivo /etc/nsswitch.conf.
Deve haver algo como:

hosts:          files mdns

Altere para:

hosts:          files dns

— cristão
fonte

+1 de boa ideia. @Tshepang o ssh se conecta mais rápido quando você usa o IP do nome do host diretamente?

— Tobias Kienzler 10/01

@tobias leva metade do tempo

— tshepang

Estou tirando /etc/host.conf: line 2: bad command mdns '' quando corro ssh user@hostname.

— tshepang

Parece que esta é uma configuração desatualizada, desde glibc 2.3.x (2006): forums.gentoo.org/viewtopic-t-476558-highlight-mdns.html . O que você está usando (SO, versão glic)?

— tshepang

1

Você está dizendo que leva apenas metade do tempo quando você usa o endereço IP. Isso significa que você tem um problema com sua resolução de nome (IP => FQDN ou FQDN => IP). Então, primeiro dê uma olhada na sua configuração de DNS e tente descobrir se você tem algum problema com ssh ou não.

— Christian

3

Adicionar o nome do host às /etc/hostsvezes pode resolver esse problema.

— Don Mclachlan
fonte

Funciona para um único nome de host, mas a solução do Earlz é mais genérica (e corrige o mesmo problema).

— Skippy le Grand Gourou

1

Verifique também se nscdestá instalado e em execução.

Não ter um cache DNS pode aumentar o tempo necessário para resolver o registro PTR (supondo que o cliente ssh esteja executando uma pesquisa reversa de DNS para o endereço IP do servidor)

— altmas5
fonte

0

Eu tenho o mesmo problema no ambiente Windows 2008 R2, mas "useDNS no" não funciona.

Eu tento adicionar aos arquivos de hosts o IP e o host do servidor de conexão e é mais rápido em 30seg. O que me faz pensar que a resolução pode estar no DNS.

Eu tento adicionar servidores DNS, mas isso não resolve.

Meu servidor tem dois sufixos DNS. 1 para o domínio corporativo ao qual o servidor pertence (domain.com) e o outro para sua interface externa conectando-se a uma rede privada (domain.net).

A ordem do sufixo DNS é domain.net primeiro e depois domain.com em seguida

Meus clientes SFTP / SSH estão no domínio corporativo. A propósito, clientes problemáticos são do domínio corporativo.

O que funciona para mim é que eu faço domínio.com primeiro e depois domínio.net segundo

O atraso da conexão 2m30s antes se tornou apenas 3-4s.

— Eric Arpon
fonte