Why does a login failure via ssh take longer than a successful one?

This is something that has bugged me for years, and I am curious if one of you uber admins can explain it to me.

If I ssh into one of my linux boxes and provide the correct credentials, my authentication is nearly instantaneous. On the same box, if I provide the wrong password, it takes a couple of seconds to present the failed login message and re-prompt. What's happening on the server that takes a bad password so long to fail?

Thanks sf!

SR

This is a security feature implemented by the PAM module that's checking your passwords.

If you read the manpage for pam_unix(8), you'll see a "nodelay" option. pam_unix is used by ssh to check passwords, by login, and anything else that checks your password. "The default action is for the module to request a delay-on-failure of the order of two second."

There's a function all the pam modules can call to request the main pam stuff delay. pam_fail_delay. This function takes the longest delay any module called and randomly changes it by up to 25% and waits that long before returning to the application (sshd, login, etc).

It's a common security measure on many systems that a failure (such as trying to check password for a user that doesn't exist) will insert a small sleep. This prevents timing attacks, since otherwise an unsuccessful login to a valid account could take slightly longer (encrypting password, stats in home directory, etc) than an attempt to log into a non-existent account. Other terms for this are covert channel, timing channel, or side channel attack. It also discourages brute force attacks (but not very well, just open more connections). Randomizing the sleep slightly helps, also.

Although I am not intimately familiar with the workings of OpenSSH, it stands to reason that this is a security feature. With no delay, it would be easy for an (automated) attacker to attempt numerous passwords within a very short period of time. Any kind of "sludge factor" renders this type of attack less feasible.

That depends on your server's authetication configuration. On most linux boxes (plain vanilla off the shelf) this will use PAM, for local accounts. However, it will probably also look for a NIS service. This never comes to bear when you successfully log into a local user account, but if that doesn't work then PAM will time out in the search for the NIS server (or the credentials on the NIS server, if there is one).

Of course, there are many other possible scenarios, where similar principles apply. In order to give you a detailed answer, you would need tom provide more details about your server's authentication setup (e.g. /etc/nsswitch.conf and /etc/pam.conf or contents of files in /etc/pam.d).