Eu estava experimentando com os módulos RSA SecurID na minha configuração do PAM há um tempo atrás e criei exatamente esse comportamento para mim mesmo, por isso sei uma maneira de replicar o que você está vendo.
Se você tiver um módulo pam que falha (retorna PAM_AUTH_ERR ) como o único módulo required configurado ou como requisite antes de qualquer outra coisa (ou em várias outras configurações possíveis com efeito semelhante), Retorna instantaneamente a falha para sudo , que tentará novamente, duas vezes, obtendo três falhas em rápida sucessão. (Você pode configurar passwd_tries em /etc/sudoers para um valor diferente de 3 para obter mais ou menos falhas, se por algum motivo você preferir.)
Isso não solicita sua senha uma vez primeiro, mas definitivamente há algumas configurações de PAM que podem fazer isso, bloqueando você após a primeira falha e, em seguida, retornando falhas rapidamente para as próximas tentativas.
Então, vou adivinhar que você alterou sua configuração do PAM ou algo apontado por essa configuração está falhando (corretamente ou não) de uma maneira que não introduz um demora. (Normalmente, o atraso "normal" é introduzido pelo módulo pam_unix.so , a menos que você forneça o argumento nodelay .)
Uma maneira fácil de recriar isso é colocar
auth requisite pam_deny.so
logo acima de todas as linhas auth existentes em /etc/pam.d/sudo . Novamente, isso é falha de insta, não prompt-once-and-then-fail, mas isso deve colocá-lo no caminho certo para sua configuração específica. (Pelo que entendi, sua configuração funciona bem se você der a senha correta, então eu examinaria os comportamentos em falha de seus módulos PAM configurados.)