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...
Is this wait time normal or should I do something to "repair" this?
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It only takes a minute to sign up.Sign up to join this community
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:
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
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:
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/sshdif you don't want to display a motd.
- delete the contents of the
- chmod -x the scripts in
/etc/update-motd.dthat you don't want to run.
Found solution myself finally:
sudo apt-get remove landscape-client landscape-common
session optional pam_motd.soin
Now login is INSTANT!
From your description it sounds more like a networking problem. To diagnose:
If you can connect OK with Windows and PuTTY, it's probably not an issue on the server's side.
UsePAM are both enabled, OpenSSH server always attempts authentication with a null password, which it takes as a sign that no authentication is needed for the account in question. It does this as soon as the authentication process begins, in both protocols, and not in response any "real" authentication request
from the client. OpenSSH will only allow such access if the sshd_config
PermitEmptyPassword is set; unfortunately, the way the code is
written, it performs the password test in any case, and thus shows up to
PAM as a failure.
UsePAM, but remember: without PAM, wou won't be able to login without a key.
I think when you login, ubuntu executes one or more of these files:
/etc/bash.bashrc ~/.bash_profile ~/.bashrc
You could see what's in them and maybe even try executing them to see what's taking so long.
In my limited experience, when putty works, but Linux, Ubuntu in this case, does not, it is usually keep alive. Networking or server problems would affect both client OS.
You can use the above keep alive option on the command line, but it is sort of tedious to type.
Easier to edit a few configuration files.
If you have
root access, and wish to enable it automatically for all users, edit
/etc/ssh/ssh_config , add
KeepAlive yes ServerAliveInterval 120
If you do not have root access, or to enable it for a single user, edit
~/.ssh/config and add the same two lines.
Check your system logs at /var/log, you may find a message with the related error/timeout.
If you have also a time wait before
and set (or add)
or add your ip in
/etc/hosts if its a static local one
You might want to try to monitor the running processes while you're logging in to the server from an already logged-in connection (or a different console). There is a chance to spot which processes are the most active or using the most CPU at that time.
Below is one possible method:
topthere to see what happens.
Please note, that if the delay is not caused by some CPU-intensive calculation, you will not spot anything out-of-place. This case the problem might be I/O bound (waiting for some disk read/write or network response).