задержка для получения пароля при отправке ssh'ing на общедоступный сервер

У меня есть установка сервера (debian 7) в моем университете с публичным ip. когда я ssh в систему (из-за пределов кампуса), я получаю странную задержку в 5-10 секунд, прежде чем я получу подсказку с паролем. Почему это?

Я запускаю ssh -v для получения подробного вывода:

 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 

то я получаю пароль быстро.

мой resolv.conf выглядит

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

брандмауэр управляется webmin , а config /etc/webmin/firewall/iptables.save выглядит так:

 # 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 

И последнее, но не менее важное: коллега, у которого также есть учетная запись в той же системе, сразу же получает приглашение!

Как указано в комментариях, это, скорее всего, вызвано параметром UseDNS yes в sshd_config на сервере.

Параметр UseDNS является общим виновником этой проблемы. В основном происходит то, что ваш IP-блок блокировки имеет дефектный или отсутствующий DNS-сервер. Поэтому sshd пытается сделать обратный поиск на вашем IP-адресе и ждет, пока он не истечет. Другие люди не испытывают задержки, поскольку у них есть функциональный DNS-сервер для их netblock.

По этой причине большинство людей отключает эту службу. Хотя да, настройка там для обеспечения безопасности, она в значительной степени бесполезна .

Решение состоит в том, чтобы установить следующее в sshd_config :

 UseDNS no