longo atraso ao efetuar login com o CentOS7

Question

Eu tenho um sistema CentOS 7 e quando eu faço o login com putty ou ssh há um longo atraso antes que eu receba o aviso de senha. Eu corri o ssh -v e descobri que é necessário:

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, em seguida, ele fica lá por 1-2 minutos e, em seguida, essa saída é emitida:

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 de senha é exibido. Isso acontece independentemente do usuário que está efetuando login. Isso ocorre apenas no sistema 1. Eu tenho 5 outros onde ele prossegue sem o atraso.

Não há disco ou memória ou qualquer outro erro nos registros.

O que pode estar causando atrasos assim?

ATUALIZAÇÃO:

Eu tentei definir GSSAPIAuthentication como não e isso não resolveu o problema.

Eu executei o ssh novamente, desta vez com -vvv. Esta saída saiu e depois desligou:

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 a 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, em seguida, o prompt da senha.

    

Answer 1

Em seu /etc/ssh/sshd_config no servidor remoto, você deve alterar a opção GSSAPIAuthentication para no. Reinicie o sshd e você deve estar pronto.

edit: GSSAPI (Interface de Programação de Aplicativo de Serviço de Segurança Genérica) é essencialmente uma API que utiliza bibliotecas Kerberos para fornecer criptografia de rede strong. A menos que exista uma razão específica pela qual você precise ativar o GSSAPI, esse método deve resolver o problema que você está tendo.

edit2: Para maior clareza, também é possível que a verificação de DNS reverso esteja expirando (verificando especificamente o registro PTR dos hosts de conexão). O SSH faz isso como uma coisa óbvia, pois age como uma medida de segurança para validar o host de conexão.

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

1). Você pode alterar o arquivo sshd_config para usar o parâmetro UseDNS no . Isso interromperá a pesquisa reversa de DNS. É seguro fazer.

2). Adicione um registro PTR no sistema DNS apropriado para o host que está lento na conexão.

3). Adicione uma entrada manual no arquivo OS hosts com a entrada relevante.

Espero que ajude!

    

Answer 2

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

Verifique se o servidor não possui um resolvedor sem resposta no arquivo /etc/resolv.conf .