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?
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:
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:
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:
sudo apt-get remove landscape-client landscape-common
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:
If you can connect OK with Windows and PuTTY, it's probably not an issue on the server's side.
If PermitEmptyPassword
and 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
flag 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.
So: disable PermitEmptyPassword
or UsePAM
, but remember: without PAM, wou won't be able to login without a key.
Reference: https://groups.google.com/forum/?fromgroups=#!topic/comp.security.ssh/wExY8lWlG-c
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
Edit /etc/sshd_config
and set (or add)
UseDNS no
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:
top
there 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).