Long wait time on login

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.

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.

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:

1. Try to log in on an other console.
2. Run top there to see what happens.
3. Log in on the 1st console.

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).

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