What differences are between ways to prevent a user from logging in, by passwd and shadow files?
From https://unix.stackexchange.com/a/314732/674
In contrast to user accounts, service accounts often don't have a "proper" login shell, i.e. they have /usr/sbin/nologin as login shell (or, back in the old days, /bin/false). Moreover, service accounts are typically locked, i.e. it is not possible to login (for traditional /etc/passwd and /etc/shadow this can be achieved by setting the password hash to arbitrary values such as * or x).
It seems to give several ways to prevent a user from login.
the shell field of
/etc/passwd
:nologin
,/bin/false
, /bin/true,
/dev/null`;the password field of
/etc/shadow
:*
orx
What are the differences between their purposes? Do they all achieve the same purpose?
Thanks.
linux users
add a comment |
From https://unix.stackexchange.com/a/314732/674
In contrast to user accounts, service accounts often don't have a "proper" login shell, i.e. they have /usr/sbin/nologin as login shell (or, back in the old days, /bin/false). Moreover, service accounts are typically locked, i.e. it is not possible to login (for traditional /etc/passwd and /etc/shadow this can be achieved by setting the password hash to arbitrary values such as * or x).
It seems to give several ways to prevent a user from login.
the shell field of
/etc/passwd
:nologin
,/bin/false
, /bin/true,
/dev/null`;the password field of
/etc/shadow
:*
orx
What are the differences between their purposes? Do they all achieve the same purpose?
Thanks.
linux users
If the purpose is to prevent the user from logging in then yes, they all achieve the same purpose.
– Jesse_b
4 hours ago
add a comment |
From https://unix.stackexchange.com/a/314732/674
In contrast to user accounts, service accounts often don't have a "proper" login shell, i.e. they have /usr/sbin/nologin as login shell (or, back in the old days, /bin/false). Moreover, service accounts are typically locked, i.e. it is not possible to login (for traditional /etc/passwd and /etc/shadow this can be achieved by setting the password hash to arbitrary values such as * or x).
It seems to give several ways to prevent a user from login.
the shell field of
/etc/passwd
:nologin
,/bin/false
, /bin/true,
/dev/null`;the password field of
/etc/shadow
:*
orx
What are the differences between their purposes? Do they all achieve the same purpose?
Thanks.
linux users
From https://unix.stackexchange.com/a/314732/674
In contrast to user accounts, service accounts often don't have a "proper" login shell, i.e. they have /usr/sbin/nologin as login shell (or, back in the old days, /bin/false). Moreover, service accounts are typically locked, i.e. it is not possible to login (for traditional /etc/passwd and /etc/shadow this can be achieved by setting the password hash to arbitrary values such as * or x).
It seems to give several ways to prevent a user from login.
the shell field of
/etc/passwd
:nologin
,/bin/false
, /bin/true,
/dev/null`;the password field of
/etc/shadow
:*
orx
What are the differences between their purposes? Do they all achieve the same purpose?
Thanks.
linux users
linux users
asked 4 hours ago
Tim
26.1k74246455
26.1k74246455
If the purpose is to prevent the user from logging in then yes, they all achieve the same purpose.
– Jesse_b
4 hours ago
add a comment |
If the purpose is to prevent the user from logging in then yes, they all achieve the same purpose.
– Jesse_b
4 hours ago
If the purpose is to prevent the user from logging in then yes, they all achieve the same purpose.
– Jesse_b
4 hours ago
If the purpose is to prevent the user from logging in then yes, they all achieve the same purpose.
– Jesse_b
4 hours ago
add a comment |
2 Answers
2
active
oldest
votes
They are somewhat different. A user with a “bad” password hash may still log in if something allows him to log in without a password, for example with SSH and an authorized key. But that’s impossible without a valid shell.
On the other hand, there are some situations were a user may be granted some access without a shell (I’m thinking about an IMAP or SMTP server). Then, a user with a “good” password hash may use the service, even is he has no valid login shell.
add a comment |
Just because there are multiple ways to do things, does not mean there was a real purpose as to why. There are some minor differences between system users and normal users.
/usr/sbin/nologin
is a simple "shell" that was designed to deny access by exiting immediately. Any program can be run as a shell (as long as it is listed in /etc/shells), and if the program simply exits right away then the user will have no access to the system. This is why something like /bin/false
also works.
Using an asterisk for a password in the shadow file is just how linux represents a locked account password. If you run passwd -l username
as root, it will lock the account using this method.
Another method is to expire the account by setting the expire date to 1. This can be done by running this:
usermod -L -e 1 username
New contributor
1
Note for any program to be used as a shell, it must be listed in/etc/shells
– ivanivan
3 hours ago
@ivanivan updated post to inlude this, thanks
– Jeff A
3 hours ago
You do not need to list a shell in/etc/shells
for it to be used. Some applications may look in there and not present it as an option, but/usr/local/bin/foobarbaz
can be used as a login shell without it being listed. Indeed, there are use cases where you don't want it; eg some FTP servers will only permit access if the login shell is listed, so puttingnologin
in/etc/shells
may preventssh
access but permit FTP access!
– Stephen Harris
3 hours ago
Note that*
in the crypt field means "no valid password". An!
means locked; fromman 5 shadow
... A password field which starts with a exclamation mark means that the password is locked. The remaining characters on the line represent the password field before the password was locked
– Stephen Harris
3 hours ago
@StephenHarris I guess I should've specified - shell must be in/etc/shells
if you change to it usingchsh
. If theroot
user is simply editing/etc/passwd
then you are correct, doesn't need to be in the shells file.
– ivanivan
2 hours ago
add a comment |
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',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
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
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f492112%2fwhat-differences-are-between-ways-to-prevent-a-user-from-logging-in-by-passwd-a%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
They are somewhat different. A user with a “bad” password hash may still log in if something allows him to log in without a password, for example with SSH and an authorized key. But that’s impossible without a valid shell.
On the other hand, there are some situations were a user may be granted some access without a shell (I’m thinking about an IMAP or SMTP server). Then, a user with a “good” password hash may use the service, even is he has no valid login shell.
add a comment |
They are somewhat different. A user with a “bad” password hash may still log in if something allows him to log in without a password, for example with SSH and an authorized key. But that’s impossible without a valid shell.
On the other hand, there are some situations were a user may be granted some access without a shell (I’m thinking about an IMAP or SMTP server). Then, a user with a “good” password hash may use the service, even is he has no valid login shell.
add a comment |
They are somewhat different. A user with a “bad” password hash may still log in if something allows him to log in without a password, for example with SSH and an authorized key. But that’s impossible without a valid shell.
On the other hand, there are some situations were a user may be granted some access without a shell (I’m thinking about an IMAP or SMTP server). Then, a user with a “good” password hash may use the service, even is he has no valid login shell.
They are somewhat different. A user with a “bad” password hash may still log in if something allows him to log in without a password, for example with SSH and an authorized key. But that’s impossible without a valid shell.
On the other hand, there are some situations were a user may be granted some access without a shell (I’m thinking about an IMAP or SMTP server). Then, a user with a “good” password hash may use the service, even is he has no valid login shell.
answered 4 hours ago
user2233709
663310
663310
add a comment |
add a comment |
Just because there are multiple ways to do things, does not mean there was a real purpose as to why. There are some minor differences between system users and normal users.
/usr/sbin/nologin
is a simple "shell" that was designed to deny access by exiting immediately. Any program can be run as a shell (as long as it is listed in /etc/shells), and if the program simply exits right away then the user will have no access to the system. This is why something like /bin/false
also works.
Using an asterisk for a password in the shadow file is just how linux represents a locked account password. If you run passwd -l username
as root, it will lock the account using this method.
Another method is to expire the account by setting the expire date to 1. This can be done by running this:
usermod -L -e 1 username
New contributor
1
Note for any program to be used as a shell, it must be listed in/etc/shells
– ivanivan
3 hours ago
@ivanivan updated post to inlude this, thanks
– Jeff A
3 hours ago
You do not need to list a shell in/etc/shells
for it to be used. Some applications may look in there and not present it as an option, but/usr/local/bin/foobarbaz
can be used as a login shell without it being listed. Indeed, there are use cases where you don't want it; eg some FTP servers will only permit access if the login shell is listed, so puttingnologin
in/etc/shells
may preventssh
access but permit FTP access!
– Stephen Harris
3 hours ago
Note that*
in the crypt field means "no valid password". An!
means locked; fromman 5 shadow
... A password field which starts with a exclamation mark means that the password is locked. The remaining characters on the line represent the password field before the password was locked
– Stephen Harris
3 hours ago
@StephenHarris I guess I should've specified - shell must be in/etc/shells
if you change to it usingchsh
. If theroot
user is simply editing/etc/passwd
then you are correct, doesn't need to be in the shells file.
– ivanivan
2 hours ago
add a comment |
Just because there are multiple ways to do things, does not mean there was a real purpose as to why. There are some minor differences between system users and normal users.
/usr/sbin/nologin
is a simple "shell" that was designed to deny access by exiting immediately. Any program can be run as a shell (as long as it is listed in /etc/shells), and if the program simply exits right away then the user will have no access to the system. This is why something like /bin/false
also works.
Using an asterisk for a password in the shadow file is just how linux represents a locked account password. If you run passwd -l username
as root, it will lock the account using this method.
Another method is to expire the account by setting the expire date to 1. This can be done by running this:
usermod -L -e 1 username
New contributor
1
Note for any program to be used as a shell, it must be listed in/etc/shells
– ivanivan
3 hours ago
@ivanivan updated post to inlude this, thanks
– Jeff A
3 hours ago
You do not need to list a shell in/etc/shells
for it to be used. Some applications may look in there and not present it as an option, but/usr/local/bin/foobarbaz
can be used as a login shell without it being listed. Indeed, there are use cases where you don't want it; eg some FTP servers will only permit access if the login shell is listed, so puttingnologin
in/etc/shells
may preventssh
access but permit FTP access!
– Stephen Harris
3 hours ago
Note that*
in the crypt field means "no valid password". An!
means locked; fromman 5 shadow
... A password field which starts with a exclamation mark means that the password is locked. The remaining characters on the line represent the password field before the password was locked
– Stephen Harris
3 hours ago
@StephenHarris I guess I should've specified - shell must be in/etc/shells
if you change to it usingchsh
. If theroot
user is simply editing/etc/passwd
then you are correct, doesn't need to be in the shells file.
– ivanivan
2 hours ago
add a comment |
Just because there are multiple ways to do things, does not mean there was a real purpose as to why. There are some minor differences between system users and normal users.
/usr/sbin/nologin
is a simple "shell" that was designed to deny access by exiting immediately. Any program can be run as a shell (as long as it is listed in /etc/shells), and if the program simply exits right away then the user will have no access to the system. This is why something like /bin/false
also works.
Using an asterisk for a password in the shadow file is just how linux represents a locked account password. If you run passwd -l username
as root, it will lock the account using this method.
Another method is to expire the account by setting the expire date to 1. This can be done by running this:
usermod -L -e 1 username
New contributor
Just because there are multiple ways to do things, does not mean there was a real purpose as to why. There are some minor differences between system users and normal users.
/usr/sbin/nologin
is a simple "shell" that was designed to deny access by exiting immediately. Any program can be run as a shell (as long as it is listed in /etc/shells), and if the program simply exits right away then the user will have no access to the system. This is why something like /bin/false
also works.
Using an asterisk for a password in the shadow file is just how linux represents a locked account password. If you run passwd -l username
as root, it will lock the account using this method.
Another method is to expire the account by setting the expire date to 1. This can be done by running this:
usermod -L -e 1 username
New contributor
edited 3 hours ago
New contributor
answered 4 hours ago
Jeff A
3115
3115
New contributor
New contributor
1
Note for any program to be used as a shell, it must be listed in/etc/shells
– ivanivan
3 hours ago
@ivanivan updated post to inlude this, thanks
– Jeff A
3 hours ago
You do not need to list a shell in/etc/shells
for it to be used. Some applications may look in there and not present it as an option, but/usr/local/bin/foobarbaz
can be used as a login shell without it being listed. Indeed, there are use cases where you don't want it; eg some FTP servers will only permit access if the login shell is listed, so puttingnologin
in/etc/shells
may preventssh
access but permit FTP access!
– Stephen Harris
3 hours ago
Note that*
in the crypt field means "no valid password". An!
means locked; fromman 5 shadow
... A password field which starts with a exclamation mark means that the password is locked. The remaining characters on the line represent the password field before the password was locked
– Stephen Harris
3 hours ago
@StephenHarris I guess I should've specified - shell must be in/etc/shells
if you change to it usingchsh
. If theroot
user is simply editing/etc/passwd
then you are correct, doesn't need to be in the shells file.
– ivanivan
2 hours ago
add a comment |
1
Note for any program to be used as a shell, it must be listed in/etc/shells
– ivanivan
3 hours ago
@ivanivan updated post to inlude this, thanks
– Jeff A
3 hours ago
You do not need to list a shell in/etc/shells
for it to be used. Some applications may look in there and not present it as an option, but/usr/local/bin/foobarbaz
can be used as a login shell without it being listed. Indeed, there are use cases where you don't want it; eg some FTP servers will only permit access if the login shell is listed, so puttingnologin
in/etc/shells
may preventssh
access but permit FTP access!
– Stephen Harris
3 hours ago
Note that*
in the crypt field means "no valid password". An!
means locked; fromman 5 shadow
... A password field which starts with a exclamation mark means that the password is locked. The remaining characters on the line represent the password field before the password was locked
– Stephen Harris
3 hours ago
@StephenHarris I guess I should've specified - shell must be in/etc/shells
if you change to it usingchsh
. If theroot
user is simply editing/etc/passwd
then you are correct, doesn't need to be in the shells file.
– ivanivan
2 hours ago
1
1
Note for any program to be used as a shell, it must be listed in
/etc/shells
– ivanivan
3 hours ago
Note for any program to be used as a shell, it must be listed in
/etc/shells
– ivanivan
3 hours ago
@ivanivan updated post to inlude this, thanks
– Jeff A
3 hours ago
@ivanivan updated post to inlude this, thanks
– Jeff A
3 hours ago
You do not need to list a shell in
/etc/shells
for it to be used. Some applications may look in there and not present it as an option, but /usr/local/bin/foobarbaz
can be used as a login shell without it being listed. Indeed, there are use cases where you don't want it; eg some FTP servers will only permit access if the login shell is listed, so putting nologin
in /etc/shells
may prevent ssh
access but permit FTP access!– Stephen Harris
3 hours ago
You do not need to list a shell in
/etc/shells
for it to be used. Some applications may look in there and not present it as an option, but /usr/local/bin/foobarbaz
can be used as a login shell without it being listed. Indeed, there are use cases where you don't want it; eg some FTP servers will only permit access if the login shell is listed, so putting nologin
in /etc/shells
may prevent ssh
access but permit FTP access!– Stephen Harris
3 hours ago
Note that
*
in the crypt field means "no valid password". An !
means locked; from man 5 shadow
... A password field which starts with a exclamation mark means that the password is locked. The remaining characters on the line represent the password field before the password was locked– Stephen Harris
3 hours ago
Note that
*
in the crypt field means "no valid password". An !
means locked; from man 5 shadow
... A password field which starts with a exclamation mark means that the password is locked. The remaining characters on the line represent the password field before the password was locked– Stephen Harris
3 hours ago
@StephenHarris I guess I should've specified - shell must be in
/etc/shells
if you change to it using chsh
. If the root
user is simply editing /etc/passwd
then you are correct, doesn't need to be in the shells file.– ivanivan
2 hours ago
@StephenHarris I guess I should've specified - shell must be in
/etc/shells
if you change to it using chsh
. If the root
user is simply editing /etc/passwd
then you are correct, doesn't need to be in the shells file.– ivanivan
2 hours ago
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
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
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f492112%2fwhat-differences-are-between-ways-to-prevent-a-user-from-logging-in-by-passwd-a%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
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
Required, but never shown
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
Required, but never shown
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
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
If the purpose is to prevent the user from logging in then yes, they all achieve the same purpose.
– Jesse_b
4 hours ago