No prompt for password when piping through ssh

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?

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?

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.

In your sshd_config file set GSSAPIAuthentication=no

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

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.

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.

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.

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

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

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?