Bug#1037044: Forced password reset leaves behind failed user@.service unit
Control: tags -1 moreinfo Control: close -1 On Wed, 23 Aug 2023 11:20:35 +0200 Michael Biebl wrote: > Am 23.08.23 um 10:29 schrieb Michael Biebl: > > Control: notfixed -1 254.1-2 > > > > Am 23.08.23 um 00:29 schrieb Michael Biebl: > >> Control: fixed -1 254.1-2 > >> > > > >> Seems to work in trixie/sid, so marking as fixed for that version. > > > > Actually, that's not the case. So removing the version information again. > > > > I suspect this is a PAM issue, most likely in the sshd PAM configuration. > > If you login locally and you get the password change request, do you > also get a failed user@.service? No follow-up in almost a year, hence closing for now. If it can be proved it's still an issue, and not a problem in the pam ssh config, then it can be reopened with the requested info. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1037044: Forced password reset leaves behind failed user@.service unit
Am 23.08.23 um 10:29 schrieb Michael Biebl: Control: notfixed -1 254.1-2 Am 23.08.23 um 00:29 schrieb Michael Biebl: Control: fixed -1 254.1-2 Seems to work in trixie/sid, so marking as fixed for that version. Actually, that's not the case. So removing the version information again. I suspect this is a PAM issue, most likely in the sshd PAM configuration. If you login locally and you get the password change request, do you also get a failed user@.service? OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1037044: Forced password reset leaves behind failed user@.service unit
Control: notfixed -1 254.1-2 Am 23.08.23 um 00:29 schrieb Michael Biebl: Control: fixed -1 254.1-2 Seems to work in trixie/sid, so marking as fixed for that version. Actually, that's not the case. So removing the version information again. OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1037044: Forced password reset leaves behind failed user@.service unit
Control: fixed -1 254.1-2 On Fri, 2 Jun 2023 13:22:02 -0400 Jason Franklin wrote: Package: systemd Version: 252.6-1 Severity: normal Greetings: It appears that user@.service is left in a failed state when a user logs in over ssh and is forced to reset their password due to expiration. I was able to regularly reproduce this behavior with the process described below. # Create a test user. $ sudo adduser fish ... # Ensure no failed units. $ systemctl list-units --failed ... # Expire the user's password. $ sudo passwd -e fish # Log in via ssh. Properly change the user's password when prompted. $ ssh fish@localhost ... # Here, you will be kicked back out to your prompt after the new # password is set. # Now, note that a failed unit for the user is left behind. $ systemctl list-units --failed UNIT LOAD ACTIVE SUBDESCRIPTION * user@1001.service loaded failed failed User Manager for UID 1001 ... I think the above accurately describes the behavior I'm seeing. It seems odd to me that the failed service lingers even though the user's password has been changed correctly, without any real failures in the process. The user is now able to log in and what not, but systemd indicates a failure. This is an issue for me because these failures can stack up on systems at my work, and monitoring of failed units then indicates a problem where there is not one. Please let me know any thoughts on this. It could be another piece of software that's causing the error. Or, it could be that I have something improperly configured or that I am misinterpreting things. Seems to work in trixie/sid, so marking as fixed for that version. OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1037044: Forced password reset leaves behind failed user@.service unit
Package: systemd Version: 252.6-1 Severity: normal Greetings: It appears that user@.service is left in a failed state when a user logs in over ssh and is forced to reset their password due to expiration. I was able to regularly reproduce this behavior with the process described below. # Create a test user. $ sudo adduser fish ... # Ensure no failed units. $ systemctl list-units --failed ... # Expire the user's password. $ sudo passwd -e fish # Log in via ssh. Properly change the user's password when prompted. $ ssh fish@localhost ... # Here, you will be kicked back out to your prompt after the new # password is set. # Now, note that a failed unit for the user is left behind. $ systemctl list-units --failed UNIT LOAD ACTIVE SUBDESCRIPTION * user@1001.service loaded failed failed User Manager for UID 1001 ... I think the above accurately describes the behavior I'm seeing. It seems odd to me that the failed service lingers even though the user's password has been changed correctly, without any real failures in the process. The user is now able to log in and what not, but systemd indicates a failure. This is an issue for me because these failures can stack up on systems at my work, and monitoring of failed units then indicates a problem where there is not one. Please let me know any thoughts on this. It could be another piece of software that's causing the error. Or, it could be that I have something improperly configured or that I am misinterpreting things. Many thanks, -- Jason Franklin
