Somewhat like in How to suppress su authentication failure warning?, but it actually does not run the command at all.

# su limited
su: Authentication failure
# su -s /bin/bash limited
su: Authentication failure
# su -s /bin/bash - limited
su: Authentication failure

Why does it bother to check authentication when being run from root?

For most users su does work normally.

# grep limited /etc/passwd
# grep limited /etc/shadow

Being missing from /etc/shadow does not prevent most other users from being su-ed into.

I see log entry when I try:

Apr 21 10:43:18 thehostname su: FAILED SU (to limited) root on pts/110
# egrep -v '^#|^$' /etc/pam.d/su
auth       sufficient pam_rootok.so
session       required   pam_env.so readenv=1
session       required   pam_env.so readenv=1 envfile=/etc/default/locale
session    optional   pam_mail.so nopen
session    required   pam_limits.so
@include common-auth
@include common-account
@include common-session
  • Does the host in question have any non-standard PAM configuration? Apr 21 '20 at 3:01
  • @JosephSible-ReinstateMonica, I don't remember setting it up. For most other users su does work normally.
    – Vi.
    Apr 21 '20 at 7:25
  • How did you create the limited user? AFAIK, there ought to be an entry for it in the shadow file.
    – Kusalananda
    Apr 21 '20 at 7:31
  • @Kusalananda, I don't remember, it was long ago. There are 95 entries in /etc/shadow and 157 entries in /etc/passwd, but for most other users that are missing from shadow su $USERNAME is working like it should.
    – Vi.
    Apr 21 '20 at 7:42
  • What does egrep -v '^#|^$' /etc/pam.d/su say? (edit it into your Q)
    – mosvy
    Apr 21 '20 at 7:52

You have an x in the (mostly obsolete) password field of /etc/passwd. According to man 5 passwd (on my Debian/Raspbian machines as well as online) this means that there must be a corresponding entry in /etc/shadow:

If the password field is a lower-case “x”, then the encrypted password is actually stored in the shadow(5) file instead; there must be a corresponding line in the /etc/shadow file, or else the user account is invalid.

I suspect that you're hitting that last clause, "the user account is invalid", and su is erring on the side of caution.

Example (Raspbian)

grep test.: /etc/passwd
test1:x:1005:1005:Test 1:/home/test1:/bin/bash
test2:x:1006:1006:Test 2:/home/test2:/bin/bash

grep test.: /etc/shadow

su test1 -c id
uid=1005(test1) gid=1005(test1) groups=1005(test1)

su test2 -c id
su: Authentication failure

The solution appears to be either not to use x in the passwd password field or to add corresponding entries in /etc/shadow. (Note that making the password field in /etc/passwd empty will probably allow the user to log in without a password. Instead, use !, which will mark the account as locked.)

You should be able to use the pwconv command to fix up the /etc/shadow file with the missing entries.

  • but according to the OP, this works with other users (admittedly, that may be a user mistake, I was not able to reproduce it)
    – mosvy
    Apr 21 '20 at 8:30
  • Yes, removing x from the /etc/passwd line made su work again. Why there was no specific error message neither in console nor in auth log?
    – Vi.
    Apr 21 '20 at 12:26
  • 2
    @Vi. removing the x will let anybody login as that user without any password (at least from console, Ctrl-Alt-F3 and enter the user name; ssh or su may be more fastidious and refuse to accept it). Don't do that. It's a bad idea to mess with that stuff by hand. NB On a vanilla Debian 10, su will not complain, and let anybody become a user, if that user has an empty password field in /etc/passwd.
    – mosvy
    Apr 21 '20 at 15:01
  • Indeed. pwconv resolved the issues.
    – Vi.
    Apr 21 '20 at 15:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.