Question: When I’m trying to ssh to a remote server, after I enter the username, it takes a lot of time before it displays the password prompt. Basically, my SSH ( openSSH ) is slow during authentication process. How do I solve this problem?
Answer: If your ssh login from localhost to remotehost is slow, enable the ssh debugging while starting the ssh connection using option -v as shown below.
After it displays the “debug1: SSH2_MSG_SERVICE_ACCEPT received” message, ssh session will be hanging for almost a minute before it continues to the next debug statement.
$ ssh -v ramesh@remote-host debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received <-- OpenSSH hanging here for 1 min debug1: Authentications that can continue: publickey,password debug1: Next authentication method: publickey debug1: Trying private key: /root/.ssh/identity debug1: Trying private key: /root/.ssh/id_rsa debug1: Trying private key: /root/.ssh/id_dsa debug1: Next authentication method: password ramesh@remote-host's password:
Solution: set UseDNS to no in sshd_config file
To fix this performance issue while connecting to a remote server using ssh, set the UseDNS to no as shown below in your /etc/ssh/sshd_config file.
$ vi /etc/ssh/sshd_config UseDNS no
Restart the openssh and connect to the remote server again, which should be quick this time and will not hang at SSH2_MSG_SERVICE_ACCEPTED.
# service sshd restart $ ssh -v ramesh@remote-host
My name is Ramesh Natarajan. I will be posting instruction guides, how-to, troubleshooting tips and tricks on Linux, database, hardware, security and web. My focus is to write articles that will either teach you or help you resolve a problem. Read more about
Comments on this entry are closed.
This will work if you are doing ssh from a Linux machine.
What if you are doing ssh from a Windows machine?
you can download the free secureshell SSH client from the link below or google for
SSHSecureShellClient-3.2.9.exe
http://charlotte.at.northwestern.edu/bef/SSH/SSHSecureShellClient-3.2.9.exe
This is a command line windows SSH client, been working fine for a long time..
Hope this helps…
-Mike
@Narendra, even though you may not be able to use the Debug option in your Windows client, changing the UseDNS setting on your target machine will still resolve the slow SSH problem. If that is indeed the problem We have started to disable that on all our SSH servers as a standard practice.
Great tip – using putty on a windows machine, but changed the option on the linux server (as you said) and it worked like a charm.
Thanks much!
Cool tip.
By the way, If I remember correctly, the length of time of the delay correlates with how many resolvers you have listed in /etc/resolv.conf.
You could also just add an entry in the /etc/hosts file of the remote host for your client machine (if it is predictable). It could be as simple as:
1.1.1.1 me
…of course, the address must match your client host.
Or, you could add a reverse-dns (ptr) record for your client machine to the DNS server that your remote host uses (if you have control over it, and other mitigating conditions).
🙂
Mike / Brad,
Thanks for the suggestions.
I am using putty from my windows machine to login to ssh server.
Regards,
Narendra
Thanks, worked for me!
Tanx 🙂 worked for me gooood 😉
Thanks A lot 🙂
Thanks a lot!
Another thing to try BEFORE you do any of the above is verify what your MTU settings on your NIC…..
This advice is a bit like going to the doctor with a pain in the leg and the doctor advices that the easy way to stop the pain in the leg is to amputate it.
Yes setting UseDNS to no in the sshd_config file on the *remote* machine will cure the symptom but it will not cure the underlying problem that DNS lookups on the remote machine are not working as they should, the most likely reason being that your local machine does not have a DNS record. And if your machine does not have a DNS record either on the internal network or on the Internet, then the DNS service is not being managed effectively, so why even bother with it for local/internal network.
And people who are still using passwords with ssh rather than passphrases and key files, obviously do not know how to use ssh in its most secure mode in the first place, so failing to chastise the questioner on that point in the response demonstrates how much security is being taken seriously in this “fixing” of the problem.
Jeremy’s answer was the CORRECT way to FIX this problem.
UseDNS no — yay! The answer to all my SSH problems! I don’t know why SSH thinks it should use DNS for anything at all – it seems like a place to import security problems, rather than a feature.
I stumbled upon that article because an update of Cygwin had the exact same effect and “UseDNS no” did not resolve the issue. My temporary solution is to downgrade openssh from 6.8p1-1 to 6.7p1-2 and libssh from 1.5.0-1 to 1.4.3-1. (FTR)