On Mon, 8 Jun 2026 13:33:43 +0700 Alexander Ermakov
<[email protected]> wrote:
04.06.2026 03:28, Chris Hofstaedtler:
> Maybe you have a PAM config that interferes on the non-working
> systems?
I was able to reproduce the problem on another machine:
# apt install libpam-winbind
No special settings. Just install an additional package.
logs:
июн 07 13:49:33 deb13 su[868728]: pam_unix(su:auth): auth could not
identify password for [root]
июн 07 13:49:33 deb13 su[868728]: pam_winbind(su:auth): getting password
(0x00000388)
июн 07 13:49:36 deb13 su[868728]: pam_winbind(su:auth): request
wbcLogonUser failed: WBC_ERR_AUTH_ERROR, PAM error: PAM_USER_UNKNOWN
(10), NTSTATUS: NT_STATUS_NO_SUCH_USER, Error message was: The specified
account does not exist.
июн 07 13:49:36 deb13 su[868728]: FAILED SU (to root) fox on pts/4
Any other additional module will do the same. This comes from, in case
of winbind, /usr/share/pam-configs/winbind:
Auth:
[success=end default=ignore] pam_winbind.so krb5_auth
krb5_ccache_type=FILE cached_login try_first_pass
Note try_first_pass. It uses password which is set by another module,
or ask for the password if no password has been set before.
/usr/share/pam-configs/krb5 from libpam-heimdal does the same:
Auth:
[success=end default=ignore] pam_krb5.so minimum_uid=1000
try_first_pass
and so on.
It looks like the whole thing is configured as expected, it's just
that Ctrl+D in this context is not expected at all, - it is treated
as an error by pam_unix (the usual first module in the stack), so
password is not set, and any subsequent module with try_first_pass
will ask for the password once again.
In short, "Doctor, it hurts when I do this" -- "So don't do this".
I thinks.
Thanks,
/mjt
