Stavo sperimentando i moduli RSA SecurID nella mia configurazione PAM qualche tempo fa e ho creato con successo esattamente questo comportamento per me stesso, quindi conosco un modo per replicare ciò che stai vedendo.
Se hai un modulo pam che fallisce (ritorna PAM_AUTH_ERR
) come l'unico required
modulo configurato o come requisite
prima di ogni altra cosa (o in una serie di altre possibili configurazioni con effetto simile), restituirà immediatamente l'errore a sudo
, che quindi riproverà, due volte , ottenendo tre guasti in rapida successione. (È possibile configurare passwd_tries
in /etc/sudoers
un valore diverso da 3, al fine di ottenere i guasti più o meno, se per qualche motivo si preferisce.)
Questo non richiede la password una volta per prima, ma ci sono sicuramente alcune configurazioni PAM che potrebbero farlo, bloccandoti dopo il primo errore e restituendo rapidamente gli errori per i tentativi successivi.
Quindi, vado avanti e suppongo che tu abbia incasinato la tua configurazione PAM, altrimenti qualcosa a cui punta quella configurazione sta fallendo (o correttamente o no) in un modo che non introduce un ritardo. (Il ritardo "normale" viene di solito introdotto dal pam_unix.so
modulo, a meno che non gli si dia l' nodelay
argomento.)
Un modo semplice per ricreare questo è quello di mettere
auth requisite pam_deny.so
proprio sopra qualsiasi auth
linea esistente in /etc/pam.d/sudo
. Ancora una volta, questo è insta-failure, non prompt-once-and-then-fail, ma questo dovrebbe metterti sulla buona strada per la tua configurazione specifica. (A quanto ho capito, la tua configurazione funziona bene se dai la password giusta, quindi esaminerei i comportamenti in caso di guasto dei moduli PAM configurati.)
sudo -V
euname -a
?