délai pour obtenir une invite de mot de passe lors de la connexion à un serveur public

J'ai un serveur (Debian 7) installé dans mon université avec une IP publique. quand je ssh dans le système (de l'extérieur du campus), j'obtiens un délai étrange de 5-10 secondes avant d'obtenir l'invite de mot de passe. Pourquoi donc?

Je cours ssh -vpour obtenir une sortie détaillée:

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

alors je reçois l'amende de mot de passe.

mon resolv.confapparence

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

le pare-feu est contrôlé par webmin, et la configuration /etc/webmin/firewall/iptables.saveressemble à:

# 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

Enfin et surtout, un collègue qui possède également un compte sur le même système reçoit immédiatement l'invite!

— nass
source

La première pensée est que le serveur a UseDNS yesactivé. Ceci est connu pour ralentir les connexions. En dehors de cela, nous aurions besoin de voir les journaux de débogage du serveur ( $(which sshd) -d).

— Patrick

@Patrick, il semble être là pour une bonne raison. Mais pourquoi ralentit-il ma connexion, mais pas mes collègues?

— nass

Pourquoi pensez-vous que c'est là pour une bonne raison? Il est tout à fait probable qu'il soit là parce que personne n'a jamais pensé à l'éteindre. Et cela vous ralentit probablement parce que le serveur DNS faisant autorité pour votre netblock est mort ou manquant.

— Patrick

@Patrick bien, n'effectue-t-il pas ce contrôle pour des raisons de sécurité?

— nass

@Patrick btw cela a résolu le problème, vous pourriez donc aussi bien écrire ceci comme une réponse

— nass

Comme indiqué dans les commentaires, cela est probablement dû au UseDNS yesparamètre du sshd_configsur le serveur.

Le UseDNSparamètre est un coupable commun à ce problème. Fondamentalement, ce qui se passe est que votre netblock IP a un serveur DNS défectueux ou manquant. Donc sshd essaie de faire une recherche inversée sur votre adresse IP, et attend qu'il expire. D'autres personnes ne connaissent pas le retard car elles ont un serveur DNS fonctionnel pour leur netblock.

La plupart des gens désactivent ce paramètre pour cette raison. Bien que oui, le paramètre est là pour la sécurité, il est à peu près inutile .

La solution consiste simplement à définir les éléments suivants dans sshd_config:

UseDNS no

— Patrick
source

juste une note: sshd_configdans debian 7 vient sans cette clause dans le fichier de configuration. Il faut le taper.

— nass