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!



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.

| improve this answer | |
  • 1
    Your answer is good, but see covert channel vs. side channel attack; "covert channel" seems to refer to breaches from the inside. – Andrew Aug 4 '10 at 23:01
  • 1
    @Andrew: but side channel seems to be primarily restricted to crypto ... The timing data leak that those PAM mechanisms mask could be time to hash potential passwords, it could be which portions of the PAM stack are run, or it could be whether or not a network lookup of some sort is performed... I'll edit, though... – freiheit Aug 5 '10 at 15:05
  • +1 interesting, didn't know about the randomization. I thought it was just to discourage brute-force attacks. – sleske Aug 5 '10 at 15:13

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.

| improve this answer | |
  • Seconded. I believe this is true. Same with logins on most Linux distros (at least GNOME based). – Luke has no name Aug 4 '10 at 15:59
  • 1
    It appears that @freheit has provided a more specific answer. – Skyhawk Aug 4 '10 at 18:28

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

| improve this answer | |

Is it not also something to do with the fall back mechanisms - What happens if you login with verbose output on, when you get your credentials right it doesn't need to fall back on any other form of authentication.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.