19

It's best to use public keys for SSH. So my sshd_config has PasswordAuthentication no.

Some users never log in, e.g. a sftp user with shell /usr/sbin/nologin. Or a system account.

So I can create such a user without a password with adduser gary --shell /usr/sbin/nologin --disabled-password.

Is that a good/bad idea? Are there ramifications I've not considered?

  • 3
    So long as these are not real users' accounts, or they don't need their password for sudo access (either by virtue of not having sudo permissions at all, or by having sudo permission with NOPASSWD), the answer you selected should be suitable. I've submitted an edit on that answer to include the sudo concern but figured I'd call it out to you here in the meantime. – Doktor J Sep 4 '18 at 16:24
36

If you have root access to the server and can regenerate ssh keys for your users in case they lose them

AND

you're sure a user (as a person) won't have multiple user accounts and they need to switch between those on an SSH session (well, they can also open multiple SSH sessions if the need arises)

AND

they will never need "physical" (via keyboard+monitor or via remote console for a VM) access to the server

AND

no users have password-gated sudo access (i.e. they either don't have sudo access at all, or have sudo access with NOPASSWD)

I think you'll be good.

We have many servers at work configured like this (only some accounts need access to the VM via vmware remote console, the others connect only via SSH with pubkey auth).

  • 9
    I'd also add "you know the users will never have to access the system from remote systems that lack their private SSH key". And "You're willing to deal with users who run into a situation you didn't think of." – Andrew Henle Sep 4 '18 at 12:28
  • 7
    The first condition is IMO not necessary. Your users should create their keys themselves. You just authorize their public keys as they give them to you. If they loose a key, they'll just generate another one and you'll replace the old one on the server. – Christophe Drevet-Droguet Sep 4 '18 at 12:30
  • 1
    @AndrewHenle That is a good point, however if sshd has PasswordAuthentication no then it's a different problem (user would not be able to log in anyway). – lonix Sep 4 '18 at 12:32
  • 1
    "Never" is such a long time. Admin can easily add password authentication back, if need arises. – hyde Sep 4 '18 at 16:49
  • 2
    Well, the question clearly relates to accounts which definitely do not (and probably should not) log in, like system accounts used by specific services or sftp-only users. The question also states that the users have no login shell. For theses types of users I think it's advisable to explicitly disable login via password. – Christian Gawron Sep 4 '18 at 19:52
28

This question originally mentioned passwd --delete <username> which is unsafe: with that, the encrypted password field in /etc/shadow will be completely empty.

username::...

If you've configured your sshd to refuse password authentication, then that's safe with SSH... But if any other service on your system uses password authentication and is not configured to reject null passwords, this allows access without a password! You don't want this.


adduser --disabled-passwdwill produce an /etc/shadow entry where the encrypted password field is just an asterisk, i.e.

username:*:...

This is "an encrypted password that can never be successfully entered", i.e. this means the account is valid and technically allows logins, but it makes authentication by password impossible to succeed. So if you have any other password-authentication-based services on your server, this user is blocked from them.

Only authentication methods that use something other than standard account password (e.g. the SSH keys) will work for this user, for any service that uses the system password files in this system. When you need an user that can log in with SSH keys only, this is what you want.

If you need to set an existing account to this state, you can use this command:

echo 'username:*' | chpasswd -e

There is a third special value for encrypted password field: adduser --disabled-login, then the field will contain just a single exclamation mark.

username:!:...

Like the asterisk, this makes password authentication impossible to succeed, but it also has an additional meaning: it marks the the password as "locked" for some administration tools. passwd -l has much the same effect by prefixing the existing password hash with an exclamation mark, which again makes the password authentication impossible to use.

But here's a trap for the unwary: in year 2008, the version of passwd command that comes from the old shadow package was changed to re-define passwd -l from "locking the account" to just "locking the password". The stated reason is "for compatibility with other passwd version".

If you (like me) learned this a long time ago, it may come as a nasty surprise. It does not help matters that adduser(8) is apparently not yet aware of this distinction either.

The part that disables the account for all methods of authentication is actually setting an expiration date value of 1 for the account: usermod --expiredate 1 <username>. Before year 2008, passwd -l that originates from the shadow source kit used to do this in addition to prefixing the password with an exclamation mark - but does no longer do that.

Debian package changelog says:

  • debian/patches/494_passwd_lock-no_account_lock: Restore the previous behavior of passwd -l (which changed in #389183): only lock the user's password, not the user's account. Also explicitly document the differences. This restores a behavior common with the previous versions of passwd and with other implementations. Closes: #492307

The bug histories for Debian bug 492307 and bug 389183 may be helpful in understanding the thinking behind this.

  • Thanks for the warning... I'm gonna edit the question so no one makes that mistake! – lonix Sep 4 '18 at 12:55
  • Does your warning also apply to the case where I use adduser --disabled-passwd - so if some other service allows password authentication, then the user can login without a password? – lonix Sep 4 '18 at 13:01
  • 1
    No, adduser --disabled-password specifically makes password authentication impossible to succeed for that account. – telcoM Sep 4 '18 at 13:05
  • Because deleting the password seems so innocent but is so dangerous I suggest switching the paragraph about it with the paragraph about using * so it is the first thing people read. – Captain Man Sep 4 '18 at 22:47
  • 1
    Wow, that is a nasty surprise waiting to happen... and as usual, there is apparently a compatibility issue to blame for it. It appeared in passwd source code in 2008. Don't you love it when something you've once learned and then relied upon turns out to be not so any more? – telcoM Sep 6 '18 at 5:47

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.