Retraso para obtener la solicitud de contraseña cuando se envía a un servidor público

Tengo una configuración de servidor (Debian 7) en mi universidad con IP pública. cuando ingreso al sistema (desde fuera del campus), recibo un retraso extraño de 5 a 10 segundos antes de recibir la solicitud de contraseña. ¿Porqué es eso?

Corro ssh -vpara obtener resultados detallados:

debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received

.... delay of 5-10 seconds here

debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/nass/.ssh/id_rsa
debug1: Trying private key: /home/nass/.ssh/id_dsa
debug1: Trying private key: /home/nass/.ssh/id_ecdsa
debug1: Next authentication method: password

entonces recibo el aviso de contraseña bien.

mi resolv.confparece

domain <mydomain>.edu
nameserver <dns ip address>

el firewall está controlado por webmin, y la configuración se /etc/webmin/firewall/iptables.saveve así:

# Generated by iptables-save v1.4.14 on Mon Feb 10 17:41:38 2014
*filter
:FORWARD DROP [0:0]
:IP_TCP - [0:0]
:INPUT DROP [0:0]
:IP_UDP - [0:0]
:OUTPUT ACCEPT [0:0]
:IP_ICMP - [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state ESTABLISHED -j ACCEPT
-A INPUT -m state --state RELATED -j ACCEPT
-A INPUT -p tcp -m tcp --tcp-flags ACK ACK -j ACCEPT
-A INPUT -s 127.0.0.1/32 -i eth0 -j DROP
-A INPUT -p icmp -i eth0 -j IP_ICMP
-A INPUT -p udp -m udp -i eth0 -j IP_UDP
-A INPUT -p tcp -m tcp -i eth0 -j IP_TCP
-A INPUT -m limit --limit 3/second --limit-burst 3 -j ULOG --ulog-prefix "FW_INPUT: " --ulog-nlgroup 1
-A IP_ICMP -p icmp -m icmp --icmp-type 0 -j ACCEPT
-A IP_ICMP -p icmp -m icmp --icmp-type 3 -j ACCEPT
-A IP_ICMP -p icmp -m icmp --icmp-type 4 -j ACCEPT
-A IP_ICMP -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A IP_ICMP -p icmp -m icmp --icmp-type 12 -j ACCEPT
-A IP_ICMP -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A IP_ICMP -p icmp -j RETURN
-A IP_TCP -p tcp -m tcp --dport 2049:2050 -j DROP
-A IP_TCP -p tcp -m tcp --dport 6000:6063 -j DROP
-A IP_TCP -p tcp -m tcp --dport 7000:7010 -j DROP
-A IP_TCP -p tcp -m tcp --dport 19001 -j ACCEPT
-A IP_TCP -p tcp -m tcp --dport 12321 -j ACCEPT
-A IP_TCP -p tcp -m tcp --dport 80 -j ACCEPT
-A IP_TCP -p tcp -m tcp --dport 443 -j ACCEPT
-A IP_TCP -p tcp -m tcp -j RETURN
COMMIT
# Completed on Mon Feb 10 17:41:38 2014
# Generated by iptables-save v1.4.14 on Mon Feb 10 17:41:38 2014
*mangle
:PREROUTING ACCEPT [2386474:238877913]
:INPUT ACCEPT [2251067:225473866]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [1100410:5416839301]
:POSTROUTING ACCEPT [1100428:5416842284]
COMMIT
# Completed on Mon Feb 10 17:41:38 2014
# Generated by iptables-save v1.4.14 on Mon Feb 10 17:41:38 2014
*nat
:PREROUTING ACCEPT [211832:26633302]
:INPUT ACCEPT [444:26827]
:OUTPUT ACCEPT [1817:114098]
:POSTROUTING ACCEPT [1817:114098]
COMMIT
# Completed on Mon Feb 10 17:41:38 2014

Por último, pero no menos importante, un colega que también tiene una cuenta en el mismo sistema recibe el aviso de inmediato.

— nass
fuente

El primer pensamiento es que el servidor se ha UseDNS yeshabilitado. Esto es notorio por ralentizar los inicios de sesión. Aparte de eso, necesitaríamos ver los registros de depuración del servidor ( $(which sshd) -d).

— Patrick

@Patrick, parece estar allí por una buena razón. Pero, ¿por qué ralentiza mi inicio de sesión, pero no mis colegas?

— nass

¿Por qué crees que está ahí por una buena razón? Es muy probable que esté allí porque nadie pensó en apagarlo. Y es probable que lo ralentice porque el servidor DNS autorizado para su netblock está muerto o falta.

— Patrick

@Patrick, ¿no se realiza esta verificación por motivos de seguridad?

— nass

@Patrick por cierto, esto resolvió el problema, por lo que podría escribir esto como una respuesta

— nass

Como se indica en los comentarios, esto probablemente se deba a la UseDNS yesconfiguración en sshd_configel servidor.

El UseDNSentorno es un culpable común de este mismo problema. Básicamente, lo que sucede es que su bloque de red IP tiene un servidor DNS defectuoso o falta. Entonces sshd está tratando de hacer una búsqueda inversa en su dirección IP, y espera hasta que se agote el tiempo de espera. Otras personas no experimentan el retraso ya que tienen un servidor DNS funcional para su bloque de red.

La mayoría de las personas desactiva esta configuración por esta misma razón. Si bien sí, la configuración está ahí para la seguridad, es prácticamente inútil .

La solución es simplemente establecer lo siguiente en sshd_config:

UseDNS no

— Patricio
fuente

solo una nota: sshd_configen debian 7 viene sin esta cláusula en el archivo de configuración. Uno debe escribirlo.

— nass