Avoid stuck after ‘SSH2_MSG_SERVICE_ACCEPT received’

It is becoming pretty slow in SSH to a CentOS server.

Trying to print a verbose log:

$ ssh -vvvv my-host
....
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug1: SSH2_MSG_NEWKEYS received
debug2: set_newkeys: mode 0
debug1: rekey in after 134217728 blocks
debug1: Will attempt key: /Users/user/.ssh/id_rsa RSA SHA256:XXXXX/gNY explicit
debug2: pubkey_prepare: done
debug3: send packet: type 5
debug3: receive packet: type 7
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
..... <<<-- long long long silence here
debug3: receive packet: type 51 <<<-- and then continue to access the server
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic,password
debug3: preferred publickey,keyboard-interactive,password

This is due to we opened UseDNS option.

Solution

sed 's@#UseDNS yes@UseDNS no@g' -i /etc/ssh/sshd_config
service sshd reload

Why

When you opened UseDNS, it will try to resolve your reverse DNS (of course, it may empty). But there is a long period to dial the DNS server, and sometimes, especially when your machine is out of Internet, or in a slow bandwidth. It may stuck you for a long time.

What is the point of sshd “UseDNS” option?

The UseDNS option is mostly useless. If the client machines are out there on the Internet, there is a high chance that they don't have any reverse DNS, their reverse DNS doesn't resolve forward, or their DNS doesn't provide any information other than “belongs to this ISP” which the IP address already tells you.

In typical configurations, DNS is only used for logging. It can be used for authentication, but only if IgnoreRhosts no is specified in sshd_config. This is for compatibility with old installations that used rsh, where you can say “the user called bob on the machine called darkstar may log in as alice without showing any credentials” (by writing darkstar bob in ~alice/.rhosts). It is only secure if you trust all the machines that may possibly be connecting to the ssh server. In other words, this is very very rarely usable in a secure way.

Given that the DNS lookup doesn't provide any useful information except in very peculiar circumstances, it should be turned off. As far as I can tell, the only reason it's on by default is that it's technically more secure (if you're concerned about authentication, not availability), even though that only applies to a tiny set of circumstances.

Another argument for turning off this feature is that every superfluous feature is an unnecessary security risk.