Long wait time on login

When I log in on my server I get this:

No mail.
Last login: Fri Nov  5 14:22:45 2010...

then I must wait for 5 sec and then is ready...

wolfy@ubuntu-server:~$

Is this wait time normal or should I do something to "repair" this?

This is usually the result of pam_motd regenerating the /etc/motd file. You can check the individual scripts in /etc/update-motd.d to see if something is especially slow.

I have the same issues with 10.04 (LTS).

When I run my ssh with -vvv, it dies at:

debug1: Entering interactive session.

Extending this answer.

I managed to reboot the server remotely and enabled DEBUG loggin. Also used this opportunity to stay logged in and observe other login attempts. Here is what happens. The client connects and is authorized and hangs at above message.

On the server, the process list shows this:

root       835  0.0  0.1  11476  3348 ?        Ss   13:39   0:00 sshd: till [priv]
root       840  0.0  0.0   4804  1124 ?        S    13:39   0:00 /bin/sh -c /usr/bin/env -i PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin /bin/run-parts --lsbsysinit /etc/update-motd.d
root       841  0.0  0.0   4728  1108 ?        S    13:39   0:00 /bin/run-parts --lsbsysinit /etc/update-motd.d
root       854  0.0  0.0   4804  1144 ?        S    13:39   0:00 /bin/sh /etc/update-motd.d/50-landscape-sysinfo
root       861  0.2  0.5  15388  9248 ?        S    13:39   0:00 /usr/bin/python /usr/bin/landscape-sysinfo
root       863  0.0  0.0      0     0 ?        Z    13:39   0:00 [who] <defunct>

I can execute /usr/bin/python /usr/bin/landscape-sysinfo just fine while I am logged in, but for some reason, I cannot figure out why it stalls the login process. When I kill the process, the login continues to the prompt and is successful.

This doesn't seem to be an ssh(d) problem, it's more related to update-motd and landscape. I uninstalled the update-motd package, but it seems like the /etc/update-motd directory persists and the scripts are still executed - causing the process to hang.

Debuging this further:

Turns out the /etc/update-motd.d/ directory doesn't really belong to the package update-motd, it seems to be triggered by pam authentication through sshd.

I seem to have nailed it!

Disabled pam_motd in the following files:

• /etc/pam.d/sshd
• /etc/pam.d/login

One more:

apt-get purge landscape-client landscape-common

These seem to help to a certain extend. Though, it only removes the offending script in /etc/update-motd.d/ and neither deletes all scripts in that directory nor does it get rid off pam_motd either.

In general, I found no way to disable pam_motd completely because it seems, whatever it does – it slows down the login process to a certain extend. It doesn't block like the script in landscape-common, but it is slower.

Bug report on this issue:

• https://bugs.launchpad.net/ubuntu/+source/pam/+bug/805423

Workarounds from there:

You are right that the ability to log in is more important than presenting a motd. If this behavior is a problem for you, there are several ways that you can disable it:

• comment out the 'pam_motd' line in /etc/pam.d/sshd if you don't want to display a motd.
• delete the contents of the /etc/update-motd.d directory.
• chmod -x the scripts in /etc/update-motd.d that you don't want to run.

Found solution myself finally:

1. sudo apt-get remove landscape-client landscape-common
2. comment line session optional pam_motd.so in /etc/pam.d/login and /etc/pam.d/sshd

Now login is INSTANT!

From your description it sounds more like a networking problem. To diagnose:

• Run ssh with the -v parameter to be verbose.
• Try running a ping to the SSH server you're connecting to, and see if this also hangs at the same time.
• Try some other kind of transfer to the same server. For instance, wget with the --limit-rate parameter to fetch a file through HTTP and have it take long enough that it may trigger the "hanging" behavior.
• See whether it hangs only when idle, or even if you're doing something at the moment. If it hangs while idle, the -v diagnostics will probably tell you so, in which case the advice to use keepalive could help (ssh -o "TCPKeepAlive yes")

If you can connect OK with Windows and PuTTY, it's probably not an issue on the server's side.