openSUSE admin

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'

May not be a duplicate in the end, going to review this.

Can you set "Environment=RUST_LOG=debug" in systemctl edit kanidm-unixd? That should give us the info we need. I think the su inbetween is a "red herring". I suspect the fault is occurring during the first sudo invocation, before the second.

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.

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.

Sounds good

Has this happened since?

Last observation of this was on 2024-12-05 on jekyll.i.o.o, no debug was enabled on the machine.

What version of the unixd was on that client?