≡ Menu

[FIXED] OpenSSH Slow: Hanging at SSH2_MSG_SERVICE_ACCEPT received

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_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
Add your comment

If you enjoyed this article, you might also like..

  1. 50 Linux Sysadmin Tutorials
  2. 50 Most Frequently Used Linux Commands (With Examples)
  3. Top 25 Best Linux Performance Monitoring and Debugging Tools
  4. Mommy, I found it! – 15 Practical Linux Find Command Examples
  5. Linux 101 Hacks 2nd Edition eBook Linux 101 Hacks Book

Bash 101 Hacks Book Sed and Awk 101 Hacks Book Nagios Core 3 Book Vim 101 Hacks Book

Comments on this entry are closed.

  • Narendra July 16, 2010, 2:12 am

    This will work if you are doing ssh from a Linux machine.
    What if you are doing ssh from a Windows machine?

  • Kuric July 16, 2010, 6:40 am

    you can download the free secureshell SSH client from the link below or google for


    This is a command line windows SSH client, been working fine for a long time..

    Hope this helps…


  • Brad July 16, 2010, 7:16 am

    @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.

  • Geoff July 16, 2010, 9:04 am

    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!

  • Jeremy July 16, 2010, 11:17 am

    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: 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).

  • Narendra July 18, 2010, 11:50 pm

    Mike / Brad,

    Thanks for the suggestions.
    I am using putty from my windows machine to login to ssh server.


  • Dennis January 6, 2012, 11:35 am

    Thanks, worked for me!

  • Anonymous April 27, 2012, 11:38 pm

    Tanx 🙂 worked for me gooood 😉

  • Tzach June 26, 2013, 6:01 am

    Thanks A lot 🙂

  • PM June 27, 2013, 11:09 am

    Thanks a lot!

  • Grisa October 25, 2013, 11:34 am

    Another thing to try BEFORE you do any of the above is verify what your MTU settings on your NIC…..

  • Yale Chubb June 3, 2014, 6:05 pm

    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.

  • Jan January 28, 2015, 1:34 am

    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.

  • Konrad April 20, 2015, 2:33 am

    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)