Project

General

Profile

Actions

tickets #170020

open

sudo sometimes does not accept passphrase

Added by crameleon 17 days ago. Updated 11 days ago.

Status:
New
Priority:
Normal
Assignee:
Category:
FreeIPA/Kanidm
Target version:
-
Start date:
2024-11-16
Due date:
% Done:

0%

Estimated time:

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.


Related issues 1 (1 open0 closed)

Related to openSUSE admin - tickets #170044: Login to idm.o.o sometimes returns "InvalidState"Newfirstyear2024-11-18

Actions
Actions #1

Updated by crameleon 17 days ago

  • Private changed from Yes to No
Actions #2

Updated by crameleon 17 days ago

  • Description updated (diff)
Actions #3

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'
Actions #4

Updated by crameleon 17 days ago

  • Assignee set to firstyear

Please let me know what else to check @firstyear.

Actions #5

Updated by crameleon 14 days ago

  • Related to tickets #170044: Login to idm.o.o sometimes returns "InvalidState" added
Actions #6

Updated by firstyear 13 days ago

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

Actions #7

Updated by firstyear 13 days ago

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.

Actions #8

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.

Actions #9

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.

Actions

Also available in: Atom PDF