Try to add the remote IP address into /etc/hosts, or set UseDNS to "No" in /etc/ssh/sshd_config.

1 maybe you change encrypting ssh

2 maybe your network have problem for example many roules for iptables

3 your switch when read data encrypt slower send data

4 in your network have a spyware to listen network

Ahh, the old DNS lookups breaking the login time :)

UseDNS no fixed it. Thank you very much.

50 Best Answer points and 50 from my account over to you now. I'll ask Server Circle to move them over.

If it's a DNS resolving issue, it's easy to check:

on the server, after login via ssh (the one that takes ages), run

getent hosts ${SSH_CLIENT%% *}

if that takes ages, then that's the issue. If not, try a getent hosts on the hostname returned by the command above.

If it is due to DNS resolving issue, best would be to resolve your DNS issues. If that's not possible you can put "UseDNS no" in your sshd_config.

Is the server running ubuntu? Then it could also be due to the pam_motd PAM module that on some ubuntu version dynamically generates a /etc/motd file upon login, and that can take a very long time.

It would be helpful to see the output of ssh -v hostname and see where it hangs.

You may also want to change the sshd LogLevel to "debug" to get more information. Check your syslog configuration to see where sshd messages end up. The could be found in /var/log/syslog, /var/log/auth.log, /var/log/messages, /var/log/secure, even /var/adm/messages depending on the system.

Try disabling GSSAuthentication in /etc/ssh/sshd_config and restarting the daemon.

Also could you post: grep sshd /var/log/messages /var/log/secure | tail -60

Thank you. I still can't figure it out though :-(

I've seen that before when sshd fails to resolve the hostname of the client.

Running the ssh command with -v might give other suggestions.