26

Answer: It was, in fact, performing reverse DNS resolution. Based on the suggestions below and this article, I added "UseDNS no" to my sshd_config, rebooted ssh, and now the password prompt displays immediately.

When I SSH into my server I am given the standard "login as:" prompt, followed by the "user@host's password:" prompt. For whatever reason, the second one always takes a while to display. My server isn't under any load and typically executes commands quite fast.

Now, we're talking only 10 seconds or so between the time I hit Enter for the username and when the second prompt displays, but when you do this a lot it gets annoying. I suspect Ubuntu is looking up my user account, but it has < 5 accounts on the entire installation.

Update @Josh /var/log/messages does contain this gem:

Oct 28 16:54:59 Athena sudo: pam_sm_authenticate: Called
Oct 28 16:54:59 Athena sudo: pam_sm_authenticate: username = [msmith]
Oct 28 16:54:59 Athena sudo: Warning: Using default salt value (undefined in ~/.ecryptfsrc)
Oct 28 16:55:01 Athena sudo: Passphrase key already in keyring; rc = [1]
Oct 28 16:55:02 Athena sudo: Passphrase key already in keyring; rc = [1]
Oct 28 16:55:02 Athena sudo: There is already a key in the user session keyring for the given passphrase.

Where msmith is my username. What does this all mean?

Improve this question
1
  • Do you know (or want to learn) how to use packet sniffers such as Wireshark or tcpdump? That can tell you if the server is indeed using all that time by itself, or is actually communicating with the client.
    – Arjan
    Oct 29, 2009 at 9:38

9 Answers 9

Reset to default
16

Is it possible it's doing a reverse DNS lookup on your IP? You can check the results online if the client is using a public IP address, or use something like the following from your server:

dig -x CLIENT_IP_ADDRESS

Is there anything in /var/log/messages?

Improve this answer
7
  • I do have a Warning in the log: Warning: Using default salt value (undefined in ~/.ecryptfsrc). I posted the entire section to the question for your analysis.
    – rcampbell
    Oct 29, 2009 at 8:55
  • @rrc7cz, so what about that reverse DNS? Does your IP address resolve to something? (I doubt it will help, as most often it will take some handshakes to decide if a prompt for the user name should be shown. A quick test using Wireshark on my Mac shows that SSH is initiated long before the user name is asked for. But maybe some clients ask for that user name before even trying to connect...?)
    – Arjan
    Oct 29, 2009 at 9:28
  • 3
    I had this reverse DNS lookup issue slow down my ssh connections in couple of installations... If you find this is the case comment out the line "UseDNS yes" in /etc/ssh/sshd_config and restart sshd.
    – John Barrett
    Oct 29, 2009 at 10:01
  • @john, do you recall if that slowed down after typing the user name?
    – Arjan
    Oct 29, 2009 at 10:04
  • 1
    "UseDNS no" helped me too! UpVotes for both Q & A!
    – Grizly
    Oct 17, 2012 at 23:10
14

Probably the reverse DNS resolution (server trying to get client's name given IP) is taking time. Can you check if /etc/ssh/sshd_config has setting "VerifyReverseMapping yes" ? Set it to "VerifyReverseMapping no" and check if helps.

Edit: It seems VerifyReverseMapping is now deprecated and useDNS is the new configuration in the sshd_config.

Improve this answer
3
  • It may be true, but does it make sense then that the user name prompt is shown right away, after which it takes 10 seconds to be asked for the password?
    – Arjan
    Oct 29, 2009 at 10:22
  • Client is able to resolve server's name and send a request, that is why the user prompt is shown right away. But then server tries to get client's name (reverse DNS resolution). This may timeout if the entry dose not exist. The "VerifyReverseMapping" setting in the sshd-config controls this check.
    – secureBadshah
    Oct 30, 2009 at 5:23
  • 1
    This was the reason for slowness in my case, so it does make sense in some cases at least. Mind you that the default is yes, so don't just search if useDNS is set :)
    – Nanne
    Apr 13, 2012 at 13:09
9

In your sshd_config file set GSSAPIAuthentication=no

https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/84899

Improve this answer
0
3

You can always login with the username to begin with:

ssh user@server

does that have any effect?

If you're using PuTTY, it's configurable under Connection -> Data as Auto-login username.

Improve this answer
1
  • 1
    While this obviously doesn't speed up the time it takes for the password prompt to appear, it definitely speeds up the overall login process. Thanks
    – rcampbell
    Oct 29, 2009 at 8:47
3

If you don't have proper domain names for everything just make something up and put it in /etc/hosts. See if that goes faster...don't bother with .com just use "bob, carol, ted, alice" or whatever you want...

If the problem is resolver timeouts then this will fix it.

Improve this answer
0
2

Remember that the client will also do reverse-DNS checking checking, which can take 30 seconds or more to timeout if the reverse-DNS mapping doesn't exist with certain resolution configurations.

In either /etc/ssh/ssh_config or in ~/.ssh/config set CheckHostIP no to disable this client-side lookup.

See man 5 ssh_config for further details.

Improve this answer
1

I've found an alternative solution to this problem :- http://www.patrickmin.com/linux/tip.php?name=ssh_pause

I was having this same problem logging into a linux build machine using Putty under windows. Adding the IP address of my windows box to /etc/hosts on the linux machine solved the problem.

Improve this answer
1
  • 3
    Welcome to Super User - We generally prefer you include details and not just links. Could you EDIT your answer to add more information from the link?
    – Simon Sheehan
    Dec 19, 2011 at 20:35
1

Just for the record, I experienced the same problem where ssh would be fast from home to my home-server (mainly using it for git), but it would take some 10-20 seconds at work to get a prompt for the password.

I had to turn off UseDNS no and restart sshd sudo systemctl restart sshd.service. Then it work from all locations.

I know the question is answered and accepted, but I wanted to add the information since I had to "actively" set it to no in order to get it to stop using dns.

Improve this answer
0

Please check if nslcd (LDAP daemon) is running:

ps -ef | grep nslcd

It can cause this problem.

If it is running stop it and remove from the list of services

service nslcd stop
chkconfig nslcd off
Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.