Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

i have a server (debian 7) setup in my university with public ip. when I ssh into the system (from outside the campus), I get a weird delay of 5-10 seconds before I get the password prompt. Why is that?

I run ssh -v to get verbose output:

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

then I get the password prompt fine.

my resolv.conf looks like

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

firewall is controlled by webmin , and the config /etc/webmin/firewall/iptables.save looks like:

# 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

Last but not least, a colleague who also has an account on the same system gets the prompt immediately!

share|improve this question
1  
First thought is that the server has UseDNS yes enabled. This is notorious for slowing down logins. Aside from that, we would need to see the server's debug logs ($(which sshd) -d). –  Patrick May 13 at 12:53
    
@Patrick , it seems to be there for a good reason. But why does it slow dowm my login , but not my colleagues? –  nass May 13 at 13:09
    
Why do you think it's there for a good reason? It's entirely likely is there because nobody ever thought to turn it off. And it likely slows you down because the authoritative DNS server for your netblock is dead, or missing. –  Patrick May 13 at 13:10
    
@Patrick well, does it not carry out this check for security purposes? –  nass May 13 at 13:11
    
@Patrick btw this solved the problem , so you might as well write this as an answer –  nass May 13 at 13:14

1 Answer 1

up vote 5 down vote accepted

As indicated in the comments, this is likely being caused by the UseDNS yes setting in the sshd_config on the server.

The UseDNS setting is a common culprit for this very issue. Basically what happens is that your IP netblock either has a defective, or missing DNS server. So sshd is trying to do a reverse lookup on your IP address, and waits until it times out. Other people do not experience the delay as they have a functional DNS server for their netblock.

Most people turn this setting off for this very reason. While yes, the setting is there for security, it is pretty much useless.

The solution is simply to set the following in the sshd_config:

UseDNS no
share|improve this answer
    
just a note: sshd_config in debian 7 comes without this clause in the config file. One must type it in. –  nass May 13 at 13:59

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.