it takes too long to connect to ssh server

Question

I've got two VMs with arch linux and debian (running under virtual box). Not long ago, it started to take a lot of time connecting to arch VM over ssh. The first time after a while, successive attempts happen quickly. Here's what I see in the arch VM:

debug1: userauth-request for user yuri service ssh-connection method none
debug1: attempt 0 failures 0
debug3: Trying to reverse map address 10.0.2.2.
# ^^^ spends a lot of time after this line
debug2: parse_server_config: config reprocess config len 314
debug2: input_userauth_request: setting up authctxt for yuri
debug1: PAM: initializing for "yuri"
debug1: PAM: setting PAM_RHOST to "10.0.2.2"
debug1: PAM: setting PAM_TTY to "ssh"
debug2: input_userauth_request: try method none
Failed none for yuri from 10.0.2.2 port 35786 ssh2

10.0.2.2 is the default gateway for the VMs. What does this all mean?

P.S. Here's a good answer, thanks to which I was able to make some progress in researching the issue.

Answer 1

At this stage, there are many possibilities that might be causing a slow connection. From this link, one issue that I see is related to encryption.

Finally I know what is the issue.

my /home/user dir is encrypted and therefore ssh wasn't able to access it unless I am logged in.

Also one more possibility from here is related to the SELinux service.

Yes, SELinux is likely the cause. The .ssh dir is probably mislabeled. Look at /var/log/audit/audit.log. It should be labeled ssh_home_t. Check with ls -laZ. Run restorecon -r -vv /root/.ssh if need be.

Also from this link, I also see the PAM authentication might be a reason for slow SSH.

Edit your "/etc/ssh/ssh_config" and comment out these lines:

GSSAPIAuthentication yes
GSSAPIDelegateCredentials no

Answer 2

My guess is, that the problem are DNS requests timeouts. Try ... turning off the UseDNS option on the server you are connecting to.

The server log pretty much confirmed this (so well done for posting it :).

debug3: Trying to reverse map address 10.0.2.2.
# ^^^ spends a lot of time after this line

Looking at man sshd_config:

 UseDNS  Specifies whether sshd(8) should look up the remote host name and
         check that the resolved host name for the remote IP address maps
         back to the very same IP address.  The default is “yes”.

Note that this is pretty much pointless. The check does not kill the connection. If it doesn't pass, it just logs a finger-wagging message:

Jul 9 05:43:00 brick sshd[18971]: Address 200.41.233.234 maps to host234.advance.com.ar, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!

which only serves to generate scary false positives for users with incompetent ISPs.

OK, so how can this cause a delay?

If the DNS server doesn't respond immediately, the client will tend to wait & retry. (In case a DNS packet was delayed or lost due to network congestion). If the DNS server isn't responding at all, the client will eventually give up. E.g. dig on my system retries for 15 seconds. (It uses more specific dns library code, but the principle is the same).

$ time dig invalid @192.0.2.1

; <<>> DiG 9.9.4-P2-RedHat-9.9.4-12.P2.fc20 <<>> invalid @192.0.2.1
;; global options: +cmd
;; connection timed out; no servers could be reached

real    0m15.020s
user    0m0.010s
sys         0m0.011s

So the problem is the reverse lookup doesn't get a response. You can run the same lookup on the server yourself manually, and you should see the same delay as ssh. getent hosts 10.0.2.2.