I was experimenting with the RSA SecurID modules in my PAM configuration a while back, and successfully created exactly this behavior for myself, so I know one way to replicate what you're seeing.
If you have a pam module that fails (returns
PAM_AUTH_ERR) as either the only configured
required module or as
requisite before anything else (or in a number of other possible configurations with similar effect), it will instantly return failure to
sudo, which will then try again, twice, getting three failures in quick succession. (You can configure
/etc/sudoers to a value other than 3 in order to get more or less failures, if for some reason you prefer.)
This doesn't prompt for your password once first, but there's definitely some PAM configurations which could do that, locking you out after the first failure and then returning failures quickly for the next tries.
So, I'm going to go ahead and guess that you've either messed up your PAM configuration, or else something pointed to by that configuration is failing (either correctly or not) in a way that doesn't introduce a delay. (The "normal" delay is usually actually introduced by the
pam_unix.so module, unless you give it the
One easy way to recreate this is to put
auth requisite pam_deny.so
right above any existing
auth lines in
/etc/pam.d/sudo. Again, that's insta-failure, not prompt-once-and-then-fail, but this should put you on the track for your specific configuration. (As I understand it, your setup works fine if you give the right password, so I'd look into the on-failure behaviors of your configured PAM modules.)