Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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?

share|improve this question
    
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 '09 at 9:38

10 Answers 10

up vote 11 down vote accepted

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?

share|improve this answer
    
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 '09 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 '09 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 '09 at 10:01
    
@john, do you recall if that slowed down after typing the user name? –  Arjan Oct 29 '09 at 10:04
1  
"UseDNS no" helped me too! UpVotes for both Q & A! –  Grizly Oct 17 '12 at 23:10

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.

share|improve this answer
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 '09 at 8:47

What are the specs on the client system and server system? I'm looking primarily at the CPU, but also RAM(memory) usage too. Are either one of those low or do either one max out while this is taking place?

share|improve this answer
2  
That isn't the problem: 25% memory usage, 0.00 load averages for the past 5, 10, 15 min during which time I logged in.. –  rcampbell Oct 29 '09 at 8:50

I seem to recall that this is actually a firewall issue. Unfortunately, I can't recall how to fix it right now.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer
    
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 '09 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 '09 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 '12 at 13:09

In your sshd_config file set GSSAPIAuthentication=no

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

share|improve this answer
    
Thanks, this has fixed my problem in CentOS 6.4 server. –  kubilay Dec 2 '13 at 7:11
    
Thanks, this worked for me as well –  cuzzea Mar 6 at 8:44

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.

share|improve this answer

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.

share|improve this answer
2  
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 '11 at 20:35

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
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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