Should I delete users' passwords once I set up public key authentication for SSH?
Clash Royale CLAN TAG#URR8PPP
up vote
19
down vote
favorite
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?
ubuntu ssh security password sftp
asked Sep 4 at 12:15
lonix
18519
add a comment |Â
up vote
19
down vote
favorite
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?
ubuntu ssh security password sftp
asked Sep 4 at 12:15
lonix
18519
3
So long as these are not real users' accounts, or they don't need their password forsudoaccess (either by virtue of not having sudo permissions at all, or by having sudo permission withNOPASSWD), 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 at 16:24
add a comment |Â
up vote
19
down vote
favorite
up vote
19
down vote
favorite
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?
ubuntu ssh security password sftp
asked Sep 4 at 12:15
lonix
18519
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?
ubuntu ssh security password sftp
ubuntu ssh security password sftp
asked Sep 4 at 12:15
lonix
18519
asked Sep 4 at 12:15
lonix
18519
edited Sep 4 at 12:55
asked Sep 4 at 12:15
lonix
18519
asked Sep 4 at 12:15
lonix
18519
asked Sep 4 at 12:15
lonix
18519
18519
3
So long as these are not real users' accounts, or they don't need their password forsudoaccess (either by virtue of not having sudo permissions at all, or by having sudo permission withNOPASSWD), 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 at 16:24
add a comment |Â
3
So long as these are not real users' accounts, or they don't need their password forsudoaccess (either by virtue of not having sudo permissions at all, or by having sudo permission withNOPASSWD), 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 at 16:24
3
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 at 16:24
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 at 16:24
add a comment |Â
2 Answers
2
active
oldest
votes
up vote
36
down vote
accepted
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).
edited Sep 4 at 16:24
Doktor J
1,1722913
answered Sep 4 at 12:23
Mr Shunz
2,18711617
8
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 at 12:28
6
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 at 12:30
1
@AndrewHenle That is a good point, however if sshd hasPasswordAuthentication nothen it's a different problem (user would not be able to log in anyway).
– lonix
Sep 4 at 12:32
1
"Never" is such a long time. Admin can easily add password authentication back, if need arises.
– hyde
Sep 4 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 at 19:52
 |Â
show 5 more comments
up vote
28
down vote
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.
answered Sep 4 at 12:48
telcoM
11.5k11333
Thanks for the warning... I'm gonna edit the question so no one makes that mistake!
– lonix
Sep 4 at 12:55
Does your warning also apply to the case where I useadduser --disabled-passwd- so if some other service allows password authentication, then the user can login without a password?
– lonix
Sep 4 at 13:01
1
No,adduser --disabled-passwordspecifically makes password authentication impossible to succeed for that account.
– telcoM
Sep 4 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 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 inpasswdsource 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 at 5:47
 |Â
show 2 more comments
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
36
down vote
accepted
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).
edited Sep 4 at 16:24
Doktor J
1,1722913
answered Sep 4 at 12:23
Mr Shunz
2,18711617
8
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 at 12:28
6
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 at 12:30
1
@AndrewHenle That is a good point, however if sshd hasPasswordAuthentication nothen it's a different problem (user would not be able to log in anyway).
– lonix
Sep 4 at 12:32
1
"Never" is such a long time. Admin can easily add password authentication back, if need arises.
– hyde
Sep 4 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 at 19:52
 |Â
show 5 more comments
up vote
36
down vote
accepted
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).
edited Sep 4 at 16:24
Doktor J
1,1722913
answered Sep 4 at 12:23
Mr Shunz
2,18711617
8
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 at 12:28
6
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 at 12:30
1
@AndrewHenle That is a good point, however if sshd hasPasswordAuthentication nothen it's a different problem (user would not be able to log in anyway).
– lonix
Sep 4 at 12:32
1
"Never" is such a long time. Admin can easily add password authentication back, if need arises.
– hyde
Sep 4 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 at 19:52
 |Â
show 5 more comments
up vote
36
down vote
accepted
up vote
36
down vote
accepted
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).
edited Sep 4 at 16:24
Doktor J
1,1722913
answered Sep 4 at 12:23
Mr Shunz
2,18711617
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).
edited Sep 4 at 16:24
Doktor J
1,1722913
answered Sep 4 at 12:23
Mr Shunz
2,18711617
edited Sep 4 at 16:24
Doktor J
1,1722913
edited Sep 4 at 16:24
Doktor J
1,1722913
edited Sep 4 at 16:24
Doktor J
1,1722913
1,1722913
answered Sep 4 at 12:23
Mr Shunz
2,18711617
answered Sep 4 at 12:23
Mr Shunz
2,18711617
answered Sep 4 at 12:23
Mr Shunz
2,18711617
2,18711617
8
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 at 12:28
6
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 at 12:30
1
@AndrewHenle That is a good point, however if sshd hasPasswordAuthentication nothen it's a different problem (user would not be able to log in anyway).
– lonix
Sep 4 at 12:32
1
"Never" is such a long time. Admin can easily add password authentication back, if need arises.
– hyde
Sep 4 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 at 19:52
 |Â
show 5 more comments
8
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 at 12:28
6
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 at 12:30
1
@AndrewHenle That is a good point, however if sshd hasPasswordAuthentication nothen it's a different problem (user would not be able to log in anyway).
– lonix
Sep 4 at 12:32
1
"Never" is such a long time. Admin can easily add password authentication back, if need arises.
– hyde
Sep 4 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 at 19:52
8
8
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 at 12:28
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 at 12:28
6
6
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 at 12:30
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 at 12:30
1
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 at 12:32
@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 at 12:32
1
1
"Never" is such a long time. Admin can easily add password authentication back, if need arises.
– hyde
Sep 4 at 16:49
"Never" is such a long time. Admin can easily add password authentication back, if need arises.
– hyde
Sep 4 at 16:49
2
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 at 19:52
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 at 19:52
 |Â
show 5 more comments
up vote
28
down vote
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.
answered Sep 4 at 12:48
telcoM
11.5k11333
Thanks for the warning... I'm gonna edit the question so no one makes that mistake!
– lonix
Sep 4 at 12:55
Does your warning also apply to the case where I useadduser --disabled-passwd- so if some other service allows password authentication, then the user can login without a password?
– lonix
Sep 4 at 13:01
1
No,adduser --disabled-passwordspecifically makes password authentication impossible to succeed for that account.
– telcoM
Sep 4 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 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 inpasswdsource 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 at 5:47
 |Â
show 2 more comments
up vote
28
down vote
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.
answered Sep 4 at 12:48
telcoM
11.5k11333
Thanks for the warning... I'm gonna edit the question so no one makes that mistake!
– lonix
Sep 4 at 12:55
Does your warning also apply to the case where I useadduser --disabled-passwd- so if some other service allows password authentication, then the user can login without a password?
– lonix
Sep 4 at 13:01
1
No,adduser --disabled-passwordspecifically makes password authentication impossible to succeed for that account.
– telcoM
Sep 4 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 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 inpasswdsource 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 at 5:47
 |Â
show 2 more comments
up vote
28
down vote
up vote
28
down vote
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.
answered Sep 4 at 12:48
telcoM
11.5k11333
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.
answered Sep 4 at 12:48
telcoM
11.5k11333
edited Sep 6 at 6:40
answered Sep 4 at 12:48
telcoM
11.5k11333
answered Sep 4 at 12:48
telcoM
11.5k11333
answered Sep 4 at 12:48
telcoM
11.5k11333
11.5k11333
Thanks for the warning... I'm gonna edit the question so no one makes that mistake!
– lonix
Sep 4 at 12:55
Does your warning also apply to the case where I useadduser --disabled-passwd- so if some other service allows password authentication, then the user can login without a password?
– lonix
Sep 4 at 13:01
1
No,adduser --disabled-passwordspecifically makes password authentication impossible to succeed for that account.
– telcoM
Sep 4 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 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 inpasswdsource 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 at 5:47
 |Â
show 2 more comments
Thanks for the warning... I'm gonna edit the question so no one makes that mistake!
– lonix
Sep 4 at 12:55
Does your warning also apply to the case where I useadduser --disabled-passwd- so if some other service allows password authentication, then the user can login without a password?
– lonix
Sep 4 at 13:01
1
No,adduser --disabled-passwordspecifically makes password authentication impossible to succeed for that account.
– telcoM
Sep 4 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 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 inpasswdsource 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 at 5:47
Thanks for the warning... I'm gonna edit the question so no one makes that mistake!
– lonix
Sep 4 at 12:55
Thanks for the warning... I'm gonna edit the question so no one makes that mistake!
– lonix
Sep 4 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 at 13:01
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 at 13:01
1
1
No,
adduser --disabled-password specifically makes password authentication impossible to succeed for that account.– telcoM
Sep 4 at 13:05
No,
adduser --disabled-password specifically makes password authentication impossible to succeed for that account.– telcoM
Sep 4 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 at 22:47
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 at 22:47
1
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 at 5:47
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 at 5:47
 |Â
show 2 more comments
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f466770%2fshould-i-delete-users-passwords-once-i-set-up-public-key-authentication-for-ssh%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
3
So long as these are not real users' accounts, or they don't need their password for
sudoaccess (either by virtue of not having sudo permissions at all, or by having sudo permission withNOPASSWD), 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 at 16:24