Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I have a server that has OpenSSH running. When I log from the local network (there are a few network interfaces and this is true for all of them) then the login is relatively fast - a couple of seconds usually.

I also have a bridged VPN running into the local network the server is on, using OpenVPN, and when I try to access the server over the VPN, there's a 40 seconds delay in the login - the 40 seconds number is quite exact and its always the same delay.

Looking in the sshd debug logs, I see that a normal log in process has these lines:

Oct 18 10:05:07 server sshd[7745]: debug1: KEX done
Oct 18 10:05:07 server sshd[7745]: debug1: userauth-request for user root service ssh-connection method none
Oct 18 10:05:07 server sshd[7745]: debug1: attempt 0 failures 0
Oct 18 10:05:07 server sshd[7744]: debug1: PAM: initializing for "root"
Oct 18 10:05:07 server sshd[7744]: debug1: PAM: setting PAM_RHOST to "192.168.xx.xx"
Oct 18 10:05:07 server sshd[7744]: debug1: PAM: setting PAM_TTY to "ssh"
Oct 18 10:05:10 server sshd[7745]: debug1: userauth-request for user root service ssh-connection method publickey
Oct 18 10:05:10 server sshd[7745]: debug1: attempt 1 failures 1
Oct 18 10:05:10 server sshd[7744]: debug1: temporarily_use_uid: 0/0 (e=0/0)
Oct 18 10:05:10 server sshd[7744]: debug1: trying public key file /root/.ssh/authorized_keys
Oct 18 10:05:10 server sshd[7744]: debug1: matching key found: file /root/.ssh/authorized_keys, line 13

When a connection over the VPN occurs, I get similar lines looking like this (note the time stamps):

Oct 18 10:01:14 server sshd[31438]: debug1: KEX done
Oct 18 10:01:14 server sshd[31438]: debug1: userauth-request for user root service ssh-connection method none
Oct 18 10:01:14 server sshd[31438]: debug1: attempt 0 failures 0
Oct 18 10:01:14 server sshd[31437]: debug1: PAM: initializing for "root"
Oct 18 10:01:14 server sshd[31437]: debug1: PAM: setting PAM_RHOST to "192.168.xx.xx"
Oct 18 10:01:14 server sshd[31437]: debug1: PAM: setting PAM_TTY to "ssh"
Oct 18 10:01:54 server sshd[31438]: debug1: userauth-request for user root service ssh-connection method publickey
Oct 18 10:01:54 server sshd[31438]: debug1: attempt 1 failures 1
Oct 18 10:01:54 server sshd[31438]: debug1: test whether pkalg/pkblob are acceptable             
Oct 18 10:01:54 server sshd[31437]: debug1: temporarily_use_uid: 0/0 (e=0/0)
Oct 18 10:01:54 server sshd[31437]: debug1: trying public key file /root/.ssh/authorized_keys
Oct 18 10:01:54 server sshd[31437]: debug1: matching key found: file /root/.ssh/authorized_keys, line 13

As you can see, the second log has a 40 seconds gap in the middle - this happens every time I try to log in through the VPN to any server on the LAN, but never from the local network or the public network, and I'm using the same SSH key.

The servers are CentOS 5 and 6, the client is OpenSSH on Fedora, Ubuntu and Putty on MS-Windows.

Any hints will be appreciated.

share|improve this question
    
Could it be that the VPN session has to be re-established? You may want to check the VPN logs about this. –  ktf Oct 18 '11 at 11:56
    
The VPN continues to work just fine - for example I'm using MySQL connection and HTTP over the VPN without any issue. –  Guss Oct 18 '11 at 15:32

3 Answers 3

up vote 3 down vote accepted

I've finally found the problem - it is the GSSAPIAuthentication.

I've set

GSSAPIAuthentication no

in /etc/ssh/sshd_config and now it works fine. I'm not sure what GSSAPIAuthentication does (something to do with Kerberos) but as I'm not using that I don't care much, and apparently when it is on OpenSSH tries to do GSS authentication and times out after 40 seconds - or some such.

share|improve this answer

It's probably trying to do a reverse DNS lookup on your IP address and failing with an eventual timeout.

Make sure that reverse DNS for the IP address assigned to you by the VPN is working - it doesn't necessarily have to come up with an answer but you want to make sure that it can at least give a "not found" answer quickly rather than having to timeout.

share|improve this answer
    
I've checked the the reverse DNS resolution works - I'm using DNSMasq as the DNS/DHCP server for the LAN in question and I made sure to add the VPN's local port to the DNS server. I've tested it and the resolution works fine. –  Guss Oct 18 '11 at 15:31

I agree with TomH, reverse lookup should be the first place to look. You could quickly disable reverse lookup:

nano /etc/ssh/sshd_config

UseDNS may have a # before it, if so remove the # and set it to:

UseDNS No

Save the config file and restart ssh service.

share|improve this answer
    
I've set UseDNS No and there is no effect. –  Guss Oct 18 '11 at 15:30
    
Whats in the logs? tail /var/log/secure –  Ben Oct 20 '11 at 11:52
    
I have the secure log snippet (as relevant) in the question, with sshd set to DEBUG. –  Guss Oct 20 '11 at 13:44

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.