gran retraso al iniciar sesión con CentOS7

Tengo un sistema CentOS 7 y cuando inicio sesión con masilla o ssh hay un largo retraso antes de recibir la solicitud de contraseña. Ejecuté ssh -v y descubrí que se puede hacer esto:

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

y luego se queda allí durante 1-2 minutos y luego esta salida explota:

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

Y luego aparece el mensaje de contraseña. Esto sucede independientemente del usuario que inicie sesión. Solo ocurre en el sistema 1. Tengo otros 5 donde procede sin demora.

No hay disco ni memoria ni ningún otro error en los registros.

¿Qué podría estar causando que se demore así?

ACTUALIZAR:

Traté de establecer GSSAPIAuthenticationen no y eso no resolvió el problema.

Ejecuté ssh nuevamente, esta vez con -vvv. Esta salida salió y luego se colgó:

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)),

Después de 1-2 minutos salió esto:

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

Y luego la solicitud de contraseña.

En su /etc/ssh/sshd_configservidor remoto, debe cambiar la opción GSSAPIAuthenticationa no. Reinicie sshd y debería estar listo para comenzar.

editar: GSSAPI (Interfaz de programación de aplicaciones de servicio de seguridad genérico) es esencialmente una API que utiliza bibliotecas Kerberos para proporcionar un cifrado de red fuerte. A menos que haya una razón particular por la que necesite GSSAPI habilitado, este método debería resolver el problema que está teniendo.

edit2: para mayor claridad, también puede ser posible que la verificación inversa de DNS esté caducando (específicamente verificando el registro PTR de los hosts de conexión). SSH realiza esta comprobación de forma habitual porque actúa como una medida de seguridad para validar el host de conexión.

Dicho esto, el proceso no agrega mucho en términos de seguridad real porque, de manera realista, hay una proporción significativa de hosts que no tienen un PTR de todos modos. Hay tres formas de solucionar este problema:

1) Puede modificar el sshd_configarchivo para usar el UseDNS noparámetro. Esto detendrá la búsqueda inversa de DNS. Es seguro hacerlo.

2) Agregue un registro PTR en el sistema DNS apropiado para el host que se conecta lentamente.

3) Agregue una entrada manual en el hostsarchivo del sistema operativo con la entrada correspondiente.

¡Espero que ayude!

Esto suena como un problema de DNS: durante un intento de inicio de sesión, se realiza una búsqueda inversa de DNS para proporcionar el nombre de host remoto en los registros de autenticación.

Verifique para asegurarse de que el servidor no tenga una resolución que no responda en el /etc/resolv.confarchivo.