longo atraso ao efetuar login com o CentOS7

Eu tenho um sistema CentOS 7 e quando eu faço login com putty ou ssh, há um longo atraso antes de receber a solicitação de senha. Eu executei o ssh -v e descobri que isso é possível:

debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received

e fica lá por 1 a 2 minutos e, em seguida, essa saída explode:

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
No Kerberos credentials available
debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available
debug1: Unspecified GSS failure.  Minor code may provide more information
debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available
debug1: Next authentication method: publickey
debug1: Trying private key: /home/motor/.ssh/id_rsa
debug1: Trying private key: /home/motor/.ssh/id_dsa
debug1: Trying private key: /home/motor/.ssh/id_ecdsa
debug1: Trying private key: /home/motor/.ssh/id_ed25519
debug1: Next authentication method: password

E então o prompt da senha sai. Isso acontece independentemente do usuário que estiver efetuando login. Isso acontece apenas no sistema 1. Eu tenho outros 5 onde ele prossegue sem demora.

Não há disco, memória ou outros erros nos logs.

O que poderia estar causando um atraso assim?

ATUALIZAR:

Tentei definir GSSAPIAuthenticationcomo não e isso não resolveu o problema.

Corri o ssh novamente, desta vez com -vvv. Essa saída foi lançada e depois foi interrompida:

debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/motor/.ssh/id_rsa ((nil)),
debug2: key: /home/motor/.ssh/id_dsa ((nil)),
debug2: key: /home/motor/.ssh/id_ecdsa ((nil)),
debug2: key: /home/motor/.ssh/id_ed25519 ((nil)),

Após 1-2 minutos, saiu:

debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/motor/.ssh/id_rsa
debug3: no such identity: /home/motor/.ssh/id_rsa: No such file or directory
debug1: Trying private key: /home/motor/.ssh/id_dsa
debug3: no such identity: /home/motor/.ssh/id_dsa: No such file or directory
debug1: Trying private key: /home/motor/.ssh/id_ecdsa
debug3: no such identity: /home/motor/.ssh/id_ecdsa: No such file or directory
debug1: Trying private key: /home/motor/.ssh/id_ed25519
debug3: no such identity: /home/motor/.ssh/id_ed25519: No such file or directory
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password

E então o prompt da senha.

No seu /etc/ssh/sshd_configservidor remoto, você deve alterar a opção GSSAPIAuthenticationpara não. Reinicie o sshd e você deve estar pronto.

editar: GSSAPI (Interface de programação de aplicativos de serviço de segurança genérica) é essencialmente uma API que utiliza bibliotecas Kerberos para fornecer criptografia de rede forte. A menos que haja uma razão específica para a necessidade da ativação do GSSAPI, esse método deve resolver o problema que está ocorrendo.

edit2: Para maior clareza, também pode ser possível que a verificação DNS reversa esteja atingindo o tempo limite (verificando especificamente o registro PTR dos hosts que estão conectando). O SSH faz essa verificação normalmente, porque atua como uma medida de segurança para validar o host de conexão.

Dizendo isso, o processo não adiciona muito em termos de segurança real, porque, realisticamente, há uma proporção significativa de hosts que não possuem um PTR. Existem três maneiras de corrigir esse problema:

1) Você pode alterar o sshd_configarquivo para usar o UseDNS noparâmetro Isso interromperá a pesquisa reversa do DNS. É seguro fazer.

2) Adicione um registro PTR no sistema DNS apropriado para o host com conexão lenta.

3) Adicione uma entrada manual no hostsarquivo do SO com a entrada relevante.

Espero que ajude!

Isso parece um problema de DNS - durante uma tentativa de logon, uma pesquisa reversa de DNS é realizada para fornecer o nome do host remoto nos logs de autenticação.

Verifique para garantir que o servidor não tenha um resolvedor que não responda no /etc/resolv.confarquivo.