tickets #170020
opensudo sometimes does not accept passphrase
0%
Description
In the past this worked reliably. Now sometimes I connect to a machine, and sudo
rejects my passphrase repeatedly. I then need to enter the machine using its root passphrase, exit, and afterwards sudo
accepts my passphrase again.
I do not know how to reproduce this. The kanidm-unixd log only has some lines about "session expired" at the given timestamp.
It happened to me on different arbitrary machines.
Updated by crameleon 17 days ago
Happened again, this time I was able to capture it:
crameleon@atlas1:/home/crameleon> sudo -i
[sudo] password for crameleon:
Sorry, try again.
[sudo] password for crameleon:
Sorry, try again.
[sudo] password for crameleon:
sudo: 3 incorrect password attempts
crameleon@atlas1:/home/crameleon> su
Password:
atlas1 (Proxy):/home/crameleon # exit
crameleon@atlas1:/home/crameleon> sudo -i
[sudo] password for crameleon:
atlas1 (Proxy):~ #
I copy my passphrase from a password store every time, I doubt it is incorrect. And this happens on two different client machines, so I doubt it is a clipboard issue too.
The journal just reports:
Nov 16 22:22:32 atlas1 sudo[26675]: crameleon : 3 incorrect password attempts ; TTY=pts/0 ; PWD=/root ; USER=root ; COMMAND=/bin/bash
Nov 16 22:22:35 atlas1 sudo[26677]: crameleon : 3 incorrect password attempts ; TTY=pts/0 ; PWD=/root ; USER=root ; COMMAND=/bin/bash
In the audit log are a few lines like:
ses=173 subj=unconfined msg='op=PAM:authentication grantors=? acct="crameleon" e
xe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=failed'
Updated by crameleon 17 days ago
- Assignee set to firstyear
Please let me know what else to check @firstyear.
Updated by crameleon 14 days ago
- Related to tickets #170044: Login to idm.o.o sometimes returns "InvalidState" added
Updated by firstyear 13 days ago
I managed to recreate this in my own environment, but it may not be quite the same issue. What happens is Kanidm believes it's online at the start of the authentication, then haproxy rapidly kills the connection. That causes the first password input to fail, since we're now disconnected, but we can't downgrade the auth session at that point.
I think we can make the "error" path better, when we don't prompt multiple times given we can't proceed.
But we need to also check the "timeouts" to haproxy to ensure they're reasonable. The debug logs will confirm for us if it's the connection timeout causing the issue. I'll do some work to try and "make this more robust" for now.
Updated by crameleon 11 days ago
Can you set "Environment=RUST_LOG=debug" in systemctl edit kanidm-unixd?
I can't set it while it is happening before first going into su
first, but I will set it on some machines proactively and then if it happens again on those machines I will paste the information.