ssh leva muito tempo para se conectar em alguns hosts

Question

Eu tenho a versão da máquina linux red-hat 5.5.0

Eu tenho problema

se eu executar da minha máquina ssh para outra máquina linux - node1, então eu logro rapidamente no node1

mas se eu executar o ssh em outra máquina linux node2, então o ssh levará um longo tempo

por favor, avise por quê?

o que precisa fazer para executar o ssh imediatamente no node2?

remark - no debug do ssh eu recebo o erro - GSS?

    

Answer 1

Como você está com falha no GSS, pode tentar adicionar:

GSSAPIAuthentication no

para / etc / ssh / sshd_config. Então reinicie o serviço

/etc/init.d/sshd restart

    

Answer 2

Tente adicionar a seguinte linha a /etc/ssh/sshd_config no node2:

UseDNS no

Em seguida, reinicie o sshd:

/etc/init.d/ssh restart

Ou se o acima não existir:

/etc/init.d/sshd restart

    

Answer 3

Edite / etc / ssh / sshd_config no servidor e adicione (se não estiver lá) na parte inferior UseDNS no e reinicie o daemon SSH.

Parará suas máquinas de resolver o DNS e agilizará o processo.

    

Answer 4

2. Dê uma olhada aqui: OpenSSH FAQ especialmente o capítulo 3.3. Também aponta para algumas outras possíveis causas de atraso.

3. ou O método mais apropriado para saber o problema é conectar usando o ssh no modo de depuração:
   

   # ssh -v <Server name>
   
   OpenSSH_5.8p1 Debian-1ubuntu3, OpenSSL 0.9.8o 01 Jun 2010
   debug1: Reading configuration data /etc/ssh/ssh_config
   debug1: Applying options for *
   debug1: Connecting to mysql [192.168.0.29] port 22.
   debug1: Connection established.
   debug1: permanently_set_uid: 0/0
   debug1: identity file /root/.ssh/id_rsa type -1
   debug1: identity file /root/.ssh/id_rsa-cert type -1
   debug1: identity file /root/.ssh/id_dsa type -1
   debug1: identity file /root/.ssh/id_dsa-cert type -1
   debug1: identity file /root/.ssh/id_ecdsa type -1
   debug1: identity file /root/.ssh/id_ecdsa-cert type -1
   debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
   debug1: match: OpenSSH_5.3 pat OpenSSH*
   debug1: Enabling compatibility mode for protocol 2.0
   debug1: Local version string SSH-2.0-OpenSSH_5.8p1 Debian-1ubuntu3
   debug1: SSH2_MSG_KEXINIT sent
   debug1: SSH2_MSG_KEXINIT received
   debug1: kex: server->client aes128-ctr hmac-md5 none
   debug1: kex: client->server aes128-ctr hmac-md5 none
   debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
   debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
   debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
   debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
   debug1: Server host key: RSA 1a:2c:c4:62:cc:27:1b:76:6b:f7:b2:38:00:7b:3f:63
   debug1: Host 'mysql' is known and matches the RSA host key.
   debug1: Found key in /root/.ssh/known_hosts:5
   debug1: ssh_rsa_verify: signature correct
   debug1: SSH2_MSG_NEWKEYS sent
   debug1: expecting SSH2_MSG_NEWKEYS
   debug1: SSH2_MSG_NEWKEYS received
   debug1: Roaming not allowed by server
   debug1: SSH2_MSG_SERVICE_REQUEST sent
   debug1: SSH2_MSG_SERVICE_ACCEPT received
   debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
   ->> debug1: Next authentication method: gssapi-keyex
   debug1: No valid Key exchange context
   debug1: Next authentication method: gssapi-with-mic
   debug1: Unspecified GSS failure. Minor code may provide more information Credentials cache file '/tmp/krb5cc_0' not found<br/>
   

   A linha marcada com a seta estava causando o atraso no meu caso. Eu comentei a seguinte linha no servidor de destino e resolvi o problema no meu caso
   

   #GSSAPI options
   #GSSAPIAuthentication no
   #GSSAPIAuthentication yes
   #GSSAPICleanupCredentials yes
   #GSSAPICleanupCredentials yes
   #GSSAPIStrictAcceptorCheck yes
   #GSSAPIKeyExchange no
   

   reinicie o daemon do SSH no servidor remoto e tente reconectar-se ... tudo bem!
   

4. Algumas versões de glibc ( notably glibc 2.1 shipped with Red Hat 6.1 ) podem levar muito tempo para resolver “IPv6 or IPv4″ endereços de nomes de domínio. Isso pode ser resolvido com a especificação da opção AddressFamily inet em ssh_config .
   
5. Pode haver um problema de pesquisa de DNS no cliente ou no servidor. Você pode usar o comando nslookup para verificar isso no cliente e no servidor, procurando o nome e o endereço IP do outro lado. Além disso, no servidor, procure o nome retornado pela pesquisa de nome de IP do cliente. Você pode desativar a maioria das pesquisas do lado do servidor definindo UseDNS não em sshd_config .

Answer 5

Também encontrei esta resposta:

1. Especifique a opção para desativar a autenticação GSSAPI ao usar o comando SSH ou SCP, por exemplo: %código%

-OU -

2. Desabilite explicitamente a autenticação GSSAPI no arquivo de configuração do programa cliente SSH, por exemplo, edite o ssh -o GSSAPIAuthentication=no [email protected] e adicione essa configuração (se ainda não estiver no arquivo de configuração): %código%

-OU -

3. Como 2, mas na sua configuração privada ssh
    Edite /etc/ssh/ssh_config e adicione  %código%

=== ERRO ===

Quando tento me conectar a um servidor ssh (com GSSAPIAuthentication no ) eu sempre tenho (meu sistema é um Ubuntu 8.04):

debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure. Minor code may provide more information
No credentials cache found
debug1: Unspecified GSS failure. Minor code may provide more information
No credentials cache found
debug1: Unspecified GSS failure. Minor code may provide more information
debug1: Next authentication method: publickey

O fato é que em muitos servidores o estabelecimento de conexão ssh é muito lento por causa deste problema.

link