On modern linux systems, the reason is that pam_unix.so imposes such a delay. As previously reported, this can be configured down to two seconds by changing FAIL_DELAY in /etc/login.defs . If you want to reduce the delay further, you have to give pam_unix.so the "nodelay" option. For example, on my system, if you trace the includes starting from /etc/pam.d/sudo , you find you have to edit the following line of /etc/pam.d/system-auth :

auth required pam_unix.so try_first_pass nullok

and change it to this:

auth required pam_unix.so try_first_pass nullok nodelay

Unfortunately, the way my linux distro (arch) configures things, that very same system-auth file gets included by system-remote-login , which is used by sshd.

While it is safe to eliminate the delay on sudo, because that is logged, only used by local users, and bypassable by local attackers anyway, you probably don't want to eliminate this delay for remote logins. You can of course fix it by writing a custom sudo that doesn't just include the shared system-auth files.

Personally, I think the delay on sudo (and ignoring SIGINT) is a big mistake. It means users who know they mistyped the password can't kill the process and get frustrated. Of course, you still can stop sudo with Ctrl-Z, as sudo doesn't catch SIGTSTP, and after stopping it you can kill it with kill -9 (SIGKILL). It's just annoying to do. So that means an automated attack could fire off sudos on pseudo-terminals at a super high rate. But the delay frustrates legitimate users and encourages them to suspend their root shells instead of exiting them to avoid having to sudo again.