¿Por qué el mensaje de "contraseña" de ssh tarda tanto en aparecer?

Cuando lo intento ssh, la solicitud de contraseña tarda demasiado (casi dos minutos) en aparecer.

¿Por qué pasó esto?

Hay varias cosas que pueden salir mal. Agregue -vvvpara que ssh imprima un rastro detallado de lo que está haciendo y vea dónde se detiene.

El problema podría estar en el cliente o en el servidor.

Un problema común en el servidor es si se está conectando desde un cliente para el cual las búsquedas de DNS inversas caducan. (Una "búsqueda inversa de DNS" significa volver de la dirección IP de la máquina cliente a un nombre de host. No es realmente útil para la seguridad, solo un poco útil para diagnosticar intentos de ruptura de las entradas de registro, pero la configuración predeterminada lo hace de todos modos). Para desactivar las búsquedas inversas de DNS, agregue UseDNS noa /etc/ssh/sshd_config(debe ser root en el servidor; recuerde reiniciar el servicio SSH después).

Otra cosa que puede salir mal es el tiempo de espera de autenticación GSSAPI . Si no sabes qué es eso, probablemente no estés confiando en ello; puede desactivarlo agregando la línea GSSAPIAuthentication noa /etc/ssh/ssh_configo ~/.ssh/config(que está en el lado del cliente).

Espere el proceso de inicio de sesión y vea cuánto tiempo llevará:

[root@gislab00207 ~]# time ssh root@ISSLABNTL01
root@isslabntl01's password:
Last login: Fri Oct  4 07:55:03 2013 from 3.60.40.232

[root@ISSLABNTL01 ~]# exit
logout
Connection to ISSLABNTL01 closed.

real    0m45.192s
user    0m0.003s
sys     0m0.005s

You have new mail in /var/spool/mail/root
[root@gislab00207 ~]#

Ver arriba, tardó unos 45 segundos en iniciar sesión -------- MUY LENTO

Una vez que inicie sesión como root, edite el archivo sshd_config y cambie la entrada UseDNS como se muestra a continuación. Aquí estoy usando sed en lugar de editar el archivo.

[root@ISSLABNTL01 ~]# grep -i dns /etc/ssh/sshd_config
#UseDNS yes

[root@ISSLABNTL01 ~]# sed -i 's/#UseDNS yes/UseDNS no/g' /etc/ssh/sshd_config
[root@ISSLABNTL01 ~]# grep -i dns /etc/ssh/sshd_config
UseDNS no

[root@ISSLABNTL01 ~]# service sshd restart
Stopping sshd:                                             [  OK  ]
Starting sshd:                                             [  OK  ]
[root@ISSLABNTL01 ~]# exit

Permítanos cronometrar el proceso de inicio de sesión y ver ahora cuánto tiempo llevará.

[root@gislab00207 ~]# time ssh root@ISSLABNTL01
root@isslabntl01's password:
Last login: Fri Oct  4 07:55:03 2013 from 3.60.40.232

[root@ISSLABNTL01 ~]# exit
logout

Connection to ISSLABNTL01 closed.

real    0m6.192s
user    0m0.003s
sys     0m0.005s

You have new mail in /var/spool/mail/root
[root@gislab00207 ~]#

Ver que tardó 6 segundos, el tiempo para que yo escriba la contraseña.

Es algo que viene mal de la instalación de Ubuntu.

Para solucionarlo, debe cambiar esta línea en /etc/nsswitch.conf :

hosts:          files mdns4_minimal [NOTFOUND=return] dns mdns4

Y cámbialo por este:

hosts:          files dns

En mi caso, el problema se puede resolver reiniciando systemd-logind:

systemctl restart systemd-logind

Esto se menciona en Serverfault .

Sin embargo, tengo que hacer esto regularmente y no sé cuál es la causa raíz del problema.

La salida de depuración para ssh en mi caso simplemente se detuvo durante 30 segundos mientras se estaba "conectando". La solución resultó estar relacionada con la configuración de DNS en mi sistema local. Una configuración de red anterior había dejado un falso servidor DNS en el /etc/resolv.confarchivo. Reemplazarlo con un servidor DNS actual solucionó el problema.

Para mí estaba cambiando el sistema dns a 127.0.0.1, antes de esto era un host no existente.

nano /etc/resolv.conf

Y escribe lo siguiente

domain localdomain
search localdomain
(Removed this line) ===> nameserver 10.0.0.1
(Added this line) ===> nameserver 127.0.0.1

No sé tanto sobre el entorno del póster como me gustaría, pero para otros con un problema similar, puede ser un problema con el sssdque usamos para vincular ldap mojo.

Esto me pasa a mí:

$ time ssh server.example.com

real  2m0.018s
user  0m0.006s
sys   0m0.004s

Tengo que obtener acceso al servidor (en mi caso a través de la consola) y luego hacer lo siguiente:

service restart sssd

Después de eso, las cosas simplemente funcionan. No he tenido tiempo de depurar la causa raíz, pero esta venda me funciona.

Podría resolver la solicitud de contraseña lenta a través del problema ssh marcando Habilitar retransmisión DNS en la configuración de DHCP en mi enrutador dlink. Posteriormente, las conexiones con SSH funcionaron en un segundo.

Network Settings -> Router Settings -> Enable DNS Relay [x]

La configuración predeterminada reenvía todas las solicitudes de DNS al proveedor. Era lento aunque me estaba conectando con ssh [email protected]. Una sugerencia para la solución fue una entrada en /etc/resolv.conf "search upc.at" que se proporciona a través de dhcp.

El manual de dlink dice:

When DNS Relay is enabled, DHCP clients of the router will be assigned 
the router's LAN IP address as their DNS server. All DNS requests that 
the router receives will be forwarded to your ISPs DNS servers. 
When DNS relay is disabled, all DHCP clients of the router will 
be assigned the ISP's DNS server.

Después de un lanzamiento de dhcp en cliente y servidor, la conexión a través de SSH fue rápida nuevamente. HTH