No users can log in

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
0
down vote

favorite












Running Arch Linux (KDE). I performed an uneventful update today using pacman -Syu. No errors were encountered. Upon rebooting the system no user can log in. In sddm every user is greeted with "Login failed". In a virtual console, every user receives the message "login incorrect".



What could have happened? What would be the steps to fix it?



Initially, I was unable to ssh into the machine either, but after 3 reboots, I got in via ssh (with a key file).



As root, I created a new temp user and set a password. That user was able to ssh into the machine, but is not able to log in at the virtual console.



Here are the additional steps I tried so far (withotu resolution):



  • I updated the passwords for all users and tried to login at the virtual console as each user.

  • I restored /etc/shadow and /etc/gshadow from the pre-update snapshot and tried again

  • checked pwck and grpck -- each returned no errors


  • systemctl --failed shows no errors

  • UPDATE 1: while logged in via ssh I can su to another user, enter that user's password and authentication succeeds. I can do this for all users from the ssh session. However, no users can log in on a virtual console or via sddm still.

  • UPDATE 2: I edited /etc/shadow and removed the password hash for the test user account I created (see above), leaving the user with an empty password. Upon logging in on the virtual console, I get an immediate login failure as soon as I enter the username and return key.

For concern that I won't be able to ssh back in, I am not logging out or rebooting the machine until I solve the issue.



Responses to comments:



  1. Here is the output when running journalctl -f on one terminal or tty and attempting to log in on a virtual console (at the command line).

for testuser1 at virtual console:



Jan 03 14:25:44 client1 login[1506]: FAILED LOGIN 1 FROM tty2 FOR testuser1, Authentication failure 
Jan 03 14:25:58 client1 login[1506]: FAILED LOGIN 2 FROM tty2 FOR testuser1, Authentication failure
Jan 03 14:26:06 client1 login[1506]: FAILED LOGIN 3 FROM tty2 FOR testuser1, Authentication failure
Jan 03 14:26:13 client1 login[1506]: FAILED LOGIN 4 FROM tty2 FOR testuser1, Authentication failure


Here is the log info when attempting to log an actual user in via sddm:



Jan 03 14:36:01 client1 sddm-helper[1594]: [PAM] authenticate: Authentication failure
Jan 03 14:36:01 client1 sddm-helper[1594]: [PAM] returning.
Jan 03 14:36:01 client1 sddm[622]: Authentication error: "Authentication failure"
Jan 03 14:36:01 client1 sddm-greeter[687]: Message received from daemon: LoginFailed
Jan 03 14:36:01 client1 sddm-helper[1594]: [PAM] Ended.
Jan 03 14:36:01 client1 sddm[622]: Auth: sddm-helper exited with 1


  1. the disk is only 15% full


  2. regarding "are the users on the X group? Who has the ownership of the desktop configurations?", I do not understand this question. File ownerships were not changed by running pacman -Syu. And X would not affect logging in at the virtual console, so I don't believe this is relevant to the issue.


  3. a diff on the prior snapshot and /etc/pam.d shows no differences. In particular, /etc/pam.d/system-auth and /etc/pam.d/su are unchanged from before the update.







share|improve this question






















  • are the users on the X group? Who has the ownership of the desktop configurations?
    – vfbsilva
    Jan 3 at 19:03










  • What log output do you get when running journalctl -f on one terminal or tty and attempting to log in on another one?
    – jayhendren
    Jan 3 at 19:06










  • How full is the disk? If it is try clearing out some space as a full disk can prevent logins. Otherwise you should check the logs/dmesg and could try reinstalling some packages, in particular from the base group. Note that if you lose ssh access you can still get a live usb and chroot into the system.
    – Michael Daffin
    Jan 3 at 19:09










  • The fact that you can su to another user but you're getting PAM failures in journalctl output suggests that your PAM configuration got screwed up. What does your PAM stack look like? Probably /etc/pam.d/system-auth and /etc/pam.d/su would be useful places to start.
    – jayhendren
    Jan 3 at 20:05











  • Both the sddm and kwallet-pam packages have been recently updated.
    – StrongBad
    Jan 3 at 21:02














up vote
0
down vote

favorite












Running Arch Linux (KDE). I performed an uneventful update today using pacman -Syu. No errors were encountered. Upon rebooting the system no user can log in. In sddm every user is greeted with "Login failed". In a virtual console, every user receives the message "login incorrect".



What could have happened? What would be the steps to fix it?



Initially, I was unable to ssh into the machine either, but after 3 reboots, I got in via ssh (with a key file).



As root, I created a new temp user and set a password. That user was able to ssh into the machine, but is not able to log in at the virtual console.



Here are the additional steps I tried so far (withotu resolution):



  • I updated the passwords for all users and tried to login at the virtual console as each user.

  • I restored /etc/shadow and /etc/gshadow from the pre-update snapshot and tried again

  • checked pwck and grpck -- each returned no errors


  • systemctl --failed shows no errors

  • UPDATE 1: while logged in via ssh I can su to another user, enter that user's password and authentication succeeds. I can do this for all users from the ssh session. However, no users can log in on a virtual console or via sddm still.

  • UPDATE 2: I edited /etc/shadow and removed the password hash for the test user account I created (see above), leaving the user with an empty password. Upon logging in on the virtual console, I get an immediate login failure as soon as I enter the username and return key.

For concern that I won't be able to ssh back in, I am not logging out or rebooting the machine until I solve the issue.



Responses to comments:



  1. Here is the output when running journalctl -f on one terminal or tty and attempting to log in on a virtual console (at the command line).

for testuser1 at virtual console:



Jan 03 14:25:44 client1 login[1506]: FAILED LOGIN 1 FROM tty2 FOR testuser1, Authentication failure 
Jan 03 14:25:58 client1 login[1506]: FAILED LOGIN 2 FROM tty2 FOR testuser1, Authentication failure
Jan 03 14:26:06 client1 login[1506]: FAILED LOGIN 3 FROM tty2 FOR testuser1, Authentication failure
Jan 03 14:26:13 client1 login[1506]: FAILED LOGIN 4 FROM tty2 FOR testuser1, Authentication failure


Here is the log info when attempting to log an actual user in via sddm:



Jan 03 14:36:01 client1 sddm-helper[1594]: [PAM] authenticate: Authentication failure
Jan 03 14:36:01 client1 sddm-helper[1594]: [PAM] returning.
Jan 03 14:36:01 client1 sddm[622]: Authentication error: "Authentication failure"
Jan 03 14:36:01 client1 sddm-greeter[687]: Message received from daemon: LoginFailed
Jan 03 14:36:01 client1 sddm-helper[1594]: [PAM] Ended.
Jan 03 14:36:01 client1 sddm[622]: Auth: sddm-helper exited with 1


  1. the disk is only 15% full


  2. regarding "are the users on the X group? Who has the ownership of the desktop configurations?", I do not understand this question. File ownerships were not changed by running pacman -Syu. And X would not affect logging in at the virtual console, so I don't believe this is relevant to the issue.


  3. a diff on the prior snapshot and /etc/pam.d shows no differences. In particular, /etc/pam.d/system-auth and /etc/pam.d/su are unchanged from before the update.







share|improve this question






















  • are the users on the X group? Who has the ownership of the desktop configurations?
    – vfbsilva
    Jan 3 at 19:03










  • What log output do you get when running journalctl -f on one terminal or tty and attempting to log in on another one?
    – jayhendren
    Jan 3 at 19:06










  • How full is the disk? If it is try clearing out some space as a full disk can prevent logins. Otherwise you should check the logs/dmesg and could try reinstalling some packages, in particular from the base group. Note that if you lose ssh access you can still get a live usb and chroot into the system.
    – Michael Daffin
    Jan 3 at 19:09










  • The fact that you can su to another user but you're getting PAM failures in journalctl output suggests that your PAM configuration got screwed up. What does your PAM stack look like? Probably /etc/pam.d/system-auth and /etc/pam.d/su would be useful places to start.
    – jayhendren
    Jan 3 at 20:05











  • Both the sddm and kwallet-pam packages have been recently updated.
    – StrongBad
    Jan 3 at 21:02












up vote
0
down vote

favorite









up vote
0
down vote

favorite











Running Arch Linux (KDE). I performed an uneventful update today using pacman -Syu. No errors were encountered. Upon rebooting the system no user can log in. In sddm every user is greeted with "Login failed". In a virtual console, every user receives the message "login incorrect".



What could have happened? What would be the steps to fix it?



Initially, I was unable to ssh into the machine either, but after 3 reboots, I got in via ssh (with a key file).



As root, I created a new temp user and set a password. That user was able to ssh into the machine, but is not able to log in at the virtual console.



Here are the additional steps I tried so far (withotu resolution):



  • I updated the passwords for all users and tried to login at the virtual console as each user.

  • I restored /etc/shadow and /etc/gshadow from the pre-update snapshot and tried again

  • checked pwck and grpck -- each returned no errors


  • systemctl --failed shows no errors

  • UPDATE 1: while logged in via ssh I can su to another user, enter that user's password and authentication succeeds. I can do this for all users from the ssh session. However, no users can log in on a virtual console or via sddm still.

  • UPDATE 2: I edited /etc/shadow and removed the password hash for the test user account I created (see above), leaving the user with an empty password. Upon logging in on the virtual console, I get an immediate login failure as soon as I enter the username and return key.

For concern that I won't be able to ssh back in, I am not logging out or rebooting the machine until I solve the issue.



Responses to comments:



  1. Here is the output when running journalctl -f on one terminal or tty and attempting to log in on a virtual console (at the command line).

for testuser1 at virtual console:



Jan 03 14:25:44 client1 login[1506]: FAILED LOGIN 1 FROM tty2 FOR testuser1, Authentication failure 
Jan 03 14:25:58 client1 login[1506]: FAILED LOGIN 2 FROM tty2 FOR testuser1, Authentication failure
Jan 03 14:26:06 client1 login[1506]: FAILED LOGIN 3 FROM tty2 FOR testuser1, Authentication failure
Jan 03 14:26:13 client1 login[1506]: FAILED LOGIN 4 FROM tty2 FOR testuser1, Authentication failure


Here is the log info when attempting to log an actual user in via sddm:



Jan 03 14:36:01 client1 sddm-helper[1594]: [PAM] authenticate: Authentication failure
Jan 03 14:36:01 client1 sddm-helper[1594]: [PAM] returning.
Jan 03 14:36:01 client1 sddm[622]: Authentication error: "Authentication failure"
Jan 03 14:36:01 client1 sddm-greeter[687]: Message received from daemon: LoginFailed
Jan 03 14:36:01 client1 sddm-helper[1594]: [PAM] Ended.
Jan 03 14:36:01 client1 sddm[622]: Auth: sddm-helper exited with 1


  1. the disk is only 15% full


  2. regarding "are the users on the X group? Who has the ownership of the desktop configurations?", I do not understand this question. File ownerships were not changed by running pacman -Syu. And X would not affect logging in at the virtual console, so I don't believe this is relevant to the issue.


  3. a diff on the prior snapshot and /etc/pam.d shows no differences. In particular, /etc/pam.d/system-auth and /etc/pam.d/su are unchanged from before the update.







share|improve this question














Running Arch Linux (KDE). I performed an uneventful update today using pacman -Syu. No errors were encountered. Upon rebooting the system no user can log in. In sddm every user is greeted with "Login failed". In a virtual console, every user receives the message "login incorrect".



What could have happened? What would be the steps to fix it?



Initially, I was unable to ssh into the machine either, but after 3 reboots, I got in via ssh (with a key file).



As root, I created a new temp user and set a password. That user was able to ssh into the machine, but is not able to log in at the virtual console.



Here are the additional steps I tried so far (withotu resolution):



  • I updated the passwords for all users and tried to login at the virtual console as each user.

  • I restored /etc/shadow and /etc/gshadow from the pre-update snapshot and tried again

  • checked pwck and grpck -- each returned no errors


  • systemctl --failed shows no errors

  • UPDATE 1: while logged in via ssh I can su to another user, enter that user's password and authentication succeeds. I can do this for all users from the ssh session. However, no users can log in on a virtual console or via sddm still.

  • UPDATE 2: I edited /etc/shadow and removed the password hash for the test user account I created (see above), leaving the user with an empty password. Upon logging in on the virtual console, I get an immediate login failure as soon as I enter the username and return key.

For concern that I won't be able to ssh back in, I am not logging out or rebooting the machine until I solve the issue.



Responses to comments:



  1. Here is the output when running journalctl -f on one terminal or tty and attempting to log in on a virtual console (at the command line).

for testuser1 at virtual console:



Jan 03 14:25:44 client1 login[1506]: FAILED LOGIN 1 FROM tty2 FOR testuser1, Authentication failure 
Jan 03 14:25:58 client1 login[1506]: FAILED LOGIN 2 FROM tty2 FOR testuser1, Authentication failure
Jan 03 14:26:06 client1 login[1506]: FAILED LOGIN 3 FROM tty2 FOR testuser1, Authentication failure
Jan 03 14:26:13 client1 login[1506]: FAILED LOGIN 4 FROM tty2 FOR testuser1, Authentication failure


Here is the log info when attempting to log an actual user in via sddm:



Jan 03 14:36:01 client1 sddm-helper[1594]: [PAM] authenticate: Authentication failure
Jan 03 14:36:01 client1 sddm-helper[1594]: [PAM] returning.
Jan 03 14:36:01 client1 sddm[622]: Authentication error: "Authentication failure"
Jan 03 14:36:01 client1 sddm-greeter[687]: Message received from daemon: LoginFailed
Jan 03 14:36:01 client1 sddm-helper[1594]: [PAM] Ended.
Jan 03 14:36:01 client1 sddm[622]: Auth: sddm-helper exited with 1


  1. the disk is only 15% full


  2. regarding "are the users on the X group? Who has the ownership of the desktop configurations?", I do not understand this question. File ownerships were not changed by running pacman -Syu. And X would not affect logging in at the virtual console, so I don't believe this is relevant to the issue.


  3. a diff on the prior snapshot and /etc/pam.d shows no differences. In particular, /etc/pam.d/system-auth and /etc/pam.d/su are unchanged from before the update.









share|improve this question













share|improve this question




share|improve this question








edited Jan 3 at 22:36

























asked Jan 3 at 18:56









MountainX

4,4612367116




4,4612367116











  • are the users on the X group? Who has the ownership of the desktop configurations?
    – vfbsilva
    Jan 3 at 19:03










  • What log output do you get when running journalctl -f on one terminal or tty and attempting to log in on another one?
    – jayhendren
    Jan 3 at 19:06










  • How full is the disk? If it is try clearing out some space as a full disk can prevent logins. Otherwise you should check the logs/dmesg and could try reinstalling some packages, in particular from the base group. Note that if you lose ssh access you can still get a live usb and chroot into the system.
    – Michael Daffin
    Jan 3 at 19:09










  • The fact that you can su to another user but you're getting PAM failures in journalctl output suggests that your PAM configuration got screwed up. What does your PAM stack look like? Probably /etc/pam.d/system-auth and /etc/pam.d/su would be useful places to start.
    – jayhendren
    Jan 3 at 20:05











  • Both the sddm and kwallet-pam packages have been recently updated.
    – StrongBad
    Jan 3 at 21:02
















  • are the users on the X group? Who has the ownership of the desktop configurations?
    – vfbsilva
    Jan 3 at 19:03










  • What log output do you get when running journalctl -f on one terminal or tty and attempting to log in on another one?
    – jayhendren
    Jan 3 at 19:06










  • How full is the disk? If it is try clearing out some space as a full disk can prevent logins. Otherwise you should check the logs/dmesg and could try reinstalling some packages, in particular from the base group. Note that if you lose ssh access you can still get a live usb and chroot into the system.
    – Michael Daffin
    Jan 3 at 19:09










  • The fact that you can su to another user but you're getting PAM failures in journalctl output suggests that your PAM configuration got screwed up. What does your PAM stack look like? Probably /etc/pam.d/system-auth and /etc/pam.d/su would be useful places to start.
    – jayhendren
    Jan 3 at 20:05











  • Both the sddm and kwallet-pam packages have been recently updated.
    – StrongBad
    Jan 3 at 21:02















are the users on the X group? Who has the ownership of the desktop configurations?
– vfbsilva
Jan 3 at 19:03




are the users on the X group? Who has the ownership of the desktop configurations?
– vfbsilva
Jan 3 at 19:03












What log output do you get when running journalctl -f on one terminal or tty and attempting to log in on another one?
– jayhendren
Jan 3 at 19:06




What log output do you get when running journalctl -f on one terminal or tty and attempting to log in on another one?
– jayhendren
Jan 3 at 19:06












How full is the disk? If it is try clearing out some space as a full disk can prevent logins. Otherwise you should check the logs/dmesg and could try reinstalling some packages, in particular from the base group. Note that if you lose ssh access you can still get a live usb and chroot into the system.
– Michael Daffin
Jan 3 at 19:09




How full is the disk? If it is try clearing out some space as a full disk can prevent logins. Otherwise you should check the logs/dmesg and could try reinstalling some packages, in particular from the base group. Note that if you lose ssh access you can still get a live usb and chroot into the system.
– Michael Daffin
Jan 3 at 19:09












The fact that you can su to another user but you're getting PAM failures in journalctl output suggests that your PAM configuration got screwed up. What does your PAM stack look like? Probably /etc/pam.d/system-auth and /etc/pam.d/su would be useful places to start.
– jayhendren
Jan 3 at 20:05





The fact that you can su to another user but you're getting PAM failures in journalctl output suggests that your PAM configuration got screwed up. What does your PAM stack look like? Probably /etc/pam.d/system-auth and /etc/pam.d/su would be useful places to start.
– jayhendren
Jan 3 at 20:05













Both the sddm and kwallet-pam packages have been recently updated.
– StrongBad
Jan 3 at 21:02




Both the sddm and kwallet-pam packages have been recently updated.
– StrongBad
Jan 3 at 21:02















active

oldest

votes











Your Answer







StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: false,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);








 

draft saved


draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f414609%2fno-users-can-log-in%23new-answer', 'question_page');

);

Post as a guest



































active

oldest

votes













active

oldest

votes









active

oldest

votes






active

oldest

votes










 

draft saved


draft discarded


























 


draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f414609%2fno-users-can-log-in%23new-answer', 'question_page');

);

Post as a guest













































































Popular posts from this blog

How to check contact read email or not when send email to Individual?

Bahrain

Postfix configuration issue with fips on centos 7; mailgun relay