Linux account has expired

I locked my root account and when I try to do:

sudo su
I get the following message:

Your account has expired; please contact your system administrator
su: Authentication failure
(Ignored)

I thought that by locking the root account it was not possible to use the root account. Did I misinterpret what «locking» means?

I understand that it is impossible to login using the root account since the password field in /etc/shadow has the ! in front of it and that will cause the password check to always fail but I also thought that it would prevent the account from be used.

Anyway, is the error message normal or is that a sign of misconfiguration?

Thank you for the reply.
I tried it and it does what «sudo su» does except that it does not give me any errors. Under my desktop setup, if I do «sudo su» I get no error but when I try it in my server(VPS) then I get the message.

By default Ubuntu does not have root enabled but the VPS provider when they install it they enable the root account. Is there anything else that I should look for to bring the system to be like the standard way?

By default, the root account is «disabled» by using «!» as the password hash. This causes the root account to be enabled, technically, but there is no password which can authenticate as root. Another method sometimes used for disabling accounts is to set the expiration date to sometime in the past. You should not do this for root. It may cause problems with some packages or scripts.

sudo usermod -e 99999 -p ! root

You’re going to miss the root account if running a server. Not only because it is sometimes helpful, but when things go wrong that you can’t imagine yet.

Keep the root account active with a strong password, obviously don’t allow SSH logins for root, and take advantages of sudo to the full (not just allowing 1 user to do everything, but really lock down an account to what is needed — read the man page for sudo, very powerful).

sudo usermod -e 99999 -p ! root

Thank you very much for your replay.
I looked at my shadow file in my server and my desktop machine and I notice the following.
The last field, the one that specifies when the account expires has the value:14513. Which is probably why I get the error message from «su».

How do I delete that number from there? Or should I say, how do I set nothing for that field?

You don’t have to worry about that number if the fifth field is set to 99999. If you really want to, you can edit it with a text editor, but be careful.

You’re going to miss the root account if running a server. Not only because it is sometimes helpful, but when things go wrong that you can’t imagine yet.

Haha, is funny that you say that because I was thinking the same thing! It may not be such a bad thing to have the account available. I already have setup a good password and also root is not allow to login from ssh. I was also thinking the same about not just having one account to do everything.
I’m in the process of tuning the server and when I typed «sudo su» like I normally do to get a root shell and got the message (I actually got it before but I was very busy to take the time to investigate).

Thank you for taking the time to answer and your tips are good ones to.

You don’t have to worry about that number if the fifth field is set to 99999. If you really want to, you can edit it with a text editor, but be careful.

I figured that, that number (assuming my math is correct) is the reason why «su» says the account is expired. So I just wanted to get rid of that number so I don’t get the message. I figured there may be a safe way to edit the shadow file the same way there is visudo but I guess since I’m the only user in the system editing the file that it would not be such a big deal.

Well, that is what the «usermod» command is for, except it edits the fifth field instead of the one you are referring to, either of which will prevent the account from being locked.

Will do the trick. This set when the account should expire. The 5th field sets when the password should expire. In my case, I had my root account expired so that’s why when I did:

«su» will give me the message that it was giving me.

Источник

Arch Linux

Recently I’ve fresh installed my system and notice this behavior from systemd:

user@976 belongs to git sddm user, and it seems to have problem with systemd itself.

Sep 30 13:39:34 gnu kernel: audit: type=1130 audit(1569838174.485:42): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=user-runtime-dir@976 comm="systemd" exe="/us> Sep 30 13:39:34 gnu systemd[3033]: pam_unix(systemd-user:account): account sddm has expired (account expired) Sep 30 13:39:34 gnu systemd[3033]: PAM failed: User account has expired Sep 30 13:39:34 gnu systemd[3033]: user@976.service: Failed to set up PAM session: Operation not permitted Sep 30 13:39:34 gnu systemd[3033]: user@976.service: Failed at step PAM spawning /usr/lib/systemd/systemd: Operation not permitted -- Subject: Process /usr/lib/systemd/systemd could not be executed

If you have notice this or there’s any active bug request please let me know, so I can track this down.

Last edited by Bersam (2019-10-06 21:48:19)

#2 2019-09-30 11:16:24

Re: [SOLVED] PAM failed: User account has expired

Sep 30 13:39:34 gnu systemd[3033]: pam_unix(systemd-user:account): account sddm has expired (account expired)

session optional pam_systemd.so

As it is optional https://bugs.archlinux.org/task/63706#comment181624 only session registration with systemd fails.

#3 2019-09-30 15:39:58

Re: [SOLVED] PAM failed: User account has expired

I’ve experienced the same in a systemd-nspawn container environment. Fresh install with pacstrap, only base group and git are installed.

su git resulted in «Account expired». I thought it was caused by git’s shell beeing /usr/bin/git-shell. I will look into PAM, thanks.

#4 2019-09-30 16:39:46

Re: [SOLVED] PAM failed: User account has expired

@tolga9009 as an alternative to su git assuming you are following https://git-scm.com/book/en/v2/Git-on-t … the-Server
you could run the commands as root and chown the files to git:git.
Edit:
or chage -E -1 git

Last edited by loqs (2019-09-30 16:44:16)

#5 2019-09-30 18:03:08

Re: [SOLVED] PAM failed: User account has expired

Yepp, I was following that guide !

you could run the commands as root and chown the files to git:git

That’s what I did in the end, but I still couldn’t do anything over SSH.

[root@git srv]# chage -l git Last password change : Sep 30, 2019 Password expires : never Password inactive : never Account expires : Jan 02, 1970 Minimum number of days between password change : -1 Maximum number of days between password change : -1 Number of days of warning before password expires : -1

I’ve simply done «chage -E -1 git», as you suggested. Thanks!

#6 2019-09-30 18:50:18

Re: [SOLVED] PAM failed: User account has expired

Can you please file a bug report against the git package as it appears the user git can not have an expired password.

#7 2019-09-30 23:07:40

Re: [SOLVED] PAM failed: User account has expired

After further investigating the issue, I don’t think it’s a bug. User ‘git’ is created by ‘/usr/lib/sysusers.d/git.conf’:
«The account will be created disabled, so that logins are not allowed.» from ‘man sysusers.d’.

Still, out of the box, you’re getting:

git clone ssh://git@example.com:22/~git/test.git Cloning into 'test'. Your account has expired; please contact your system administrator Connection closed by example.com port 22 fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists.

Can’t say anything about git-daemon, as I don’t use it.

#8 2019-09-30 23:43:01

Re: [SOLVED] PAM failed: User account has expired

https://github.com/systemd/systemd/pull/13277
The account can be locked but not expired as was the case before that change.

#9 2019-10-01 04:28:03

Re: [SOLVED] PAM failed: User account has expired

I see. Wasn’t aware of this beeing a very recent change upstream. I think a bug report makes sense in this case. Thanks for the links!

Last edited by tolga9009 (2019-10-01 04:48:59)

#10 2019-10-02 10:13:09

Re: [SOLVED] PAM failed: User account has expired

Recently I’ve fresh installed my system and notice this behavior from systemd:

user@976 belongs to git user, and it seems to have problem with systemd itself.

Sep 30 13:39:34 gnu kernel: audit: type=1130 audit(1569838174.485:42): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=user-runtime-dir@976 comm="systemd" exe="/us> Sep 30 13:39:34 gnu systemd[3033]: pam_unix(systemd-user:account): account sddm has expired (account expired) Sep 30 13:39:34 gnu systemd[3033]: PAM failed: User account has expired Sep 30 13:39:34 gnu systemd[3033]: user@976.service: Failed to set up PAM session: Operation not permitted Sep 30 13:39:34 gnu systemd[3033]: user@976.service: Failed at step PAM spawning /usr/lib/systemd/systemd: Operation not permitted -- Subject: Process /usr/lib/systemd/systemd could not be executed

If you have notice this or there’s any active bug request please let me know, so I can track this down.

I think this is related to a change in how systemd creates users.

Removing the expiration date in the sddm user should fix it:

[root@arch ~]# usermod --expiredate= sddm

Источник

Question: what is the best way to re-activate these accounts? What the SA’s have been doing is su over to the account, then exit, so it will have an entry in lastlog, but this seems inelegant.

I don’t think that helps. While the password was indeed expired, the real problem was the lastlog inactivity timer being hit. IFAIK, chage will manipulate /etc/shadow, but won’t affect lastlog and that countdown.

2 Answers 2

To fix the pam_unix password expiration, edit /etc/shadow . It has the format [colon separated fields]:

Читайте также: Нет директории etc linux

and set the 3rd field to zero.

To fix the pam_lastlog it’s a bit uglier. The control file is /var/log/lastlog . It’s a compressed and/or binary format file.

It can be viewed with the lastlog utility. But [AFAICT] the utility provides no mechanism to change an individual entry.

It seems the recommended method is to null out the file. While this changes it for all users, this is less severe than the passwd expiry changes. cp /dev/null /var/log/lastlog will do this without disturbing the selinux permissions.

The usermod utility will reset the information for a single user but only when using the -u option to change the user’s uid. Perhaps, used in conjunction with -o :

At worst, do it in two commands, first setting uid to new unique uid, then set it back to the old one. For example, if the user’s uid was 5001 and there was no uid 5500 in use, do:

usermod -u 5500 fred usermod -u 5001 fred

If you really want to preserve most information in /var/log/lastlog and the above doesn’t work, the shadow-utils source package has a way to do it .

Here’s the source snippet from useradd:

static void lastlog_reset (uid_t uid) < struct lastlog ll; int fd; off_t offset_uid = (off_t) (sizeof ll) * uid; if (access (LASTLOG_FILE, F_OK) != 0) < return; >memzero (&ll, sizeof (ll)); fd = open (LASTLOG_FILE, O_RDWR); if ( (-1 == fd) || (lseek (fd, offset_uid, SEEK_SET) != offset_uid) || (write (fd, &ll, sizeof (ll)) != (ssize_t) sizeof (ll)) || (fsync (fd) != 0) || (close (fd) != 0)) < fprintf (stderr, _("%s: failed to reset the lastlog entry of UID %lu: %s\n"), Prog, (unsigned long) uid, strerror (errno)); SYSLOG ((LOG_WARN, "failed to reset the lastlog entry of UID %lu", (unsigned long) uid)); /* continue */ >>

Here’s a snippet from usermod:

/* * update_lastlog - update the lastlog file * * Relocate the "lastlog" entries for the user. The old entry is * left alone in case the UID was shared. It doesn't hurt anything * to just leave it be. */ static void update_lastlog (void) < struct lastlog ll; int fd; off_t off_uid = (off_t) user_id * sizeof ll; off_t off_newuid = (off_t) user_newid * sizeof ll; if (access (LASTLOG_FILE, F_OK) != 0) < return; >fd = open (LASTLOG_FILE, O_RDWR); if (-1 == fd) < fprintf (stderr, _("%s: failed to copy the lastlog entry of user %lu to user %lu: %s\n"), Prog, (unsigned long) user_id, (unsigned long) user_newid, strerror (errno)); return; >if ( (lseek (fd, off_uid, SEEK_SET) == off_uid) && (read (fd, &ll, sizeof ll) == (ssize_t) sizeof ll)) < /* Copy the old entry to its new location */ if ( (lseek (fd, off_newuid, SEEK_SET) != off_newuid) || (write (fd, &ll, sizeof ll) != (ssize_t) sizeof ll) || (fsync (fd) != 0) || (close (fd) != 0)) < fprintf (stderr, _("%s: failed to copy the lastlog entry of user %lu to user %lu: %s\n"), Prog, (unsigned long) user_id, (unsigned long) user_newid, strerror (errno)); >> else < /* Assume lseek or read failed because there is * no entry for the old UID */ /* Check if the new UID already has an entry */ if ( (lseek (fd, off_newuid, SEEK_SET) == off_newuid) && (read (fd, &ll, sizeof ll) == (ssize_t) sizeof ll)) < /* Reset the new uid's lastlog entry */ memzero (&ll, sizeof (ll)); if ( (lseek (fd, off_newuid, SEEK_SET) != off_newuid) || (write (fd, &ll, sizeof ll) != (ssize_t) sizeof ll) || (fsync (fd) != 0) || (close (fd) != 0)) < fprintf (stderr, _("%s: failed to copy the lastlog entry of user %lu to user %lu: %s\n"), Prog, (unsigned long) user_id, (unsigned long) user_newid, strerror (errno)); >> else < (void) close (fd); >> >

The definition for struct lastlog comes from #include and will look like:

/* The structure describing an entry in the database of previous logins. */ struct lastlog < #ifdef __WORDSIZE_TIME64_COMPAT32 int32_t ll_time; #else __time_t ll_time; #endif char ll_line[UT_LINESIZE]; char ll_host[UT_HOSTSIZE]; >;

Источник

Linux account has expired