SSH login is very slow from VPN

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

Could it be that the VPN session has to be re-established? You may want to check the VPN logs about this.

Answer 4

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.