Disable user shell for security reasons
We have several user accounts that we create for automated tasks that require fine-grained permissions, such as file transfer across systems, monitoring, etc.
How do we lock down these user accounts so that these "users" have no shell and are not able to login? We want to prevent the possibility that someone can SSH in as one of these user accounts.
shell ssh users login
add a comment |
We have several user accounts that we create for automated tasks that require fine-grained permissions, such as file transfer across systems, monitoring, etc.
How do we lock down these user accounts so that these "users" have no shell and are not able to login? We want to prevent the possibility that someone can SSH in as one of these user accounts.
shell ssh users login
add a comment |
We have several user accounts that we create for automated tasks that require fine-grained permissions, such as file transfer across systems, monitoring, etc.
How do we lock down these user accounts so that these "users" have no shell and are not able to login? We want to prevent the possibility that someone can SSH in as one of these user accounts.
shell ssh users login
We have several user accounts that we create for automated tasks that require fine-grained permissions, such as file transfer across systems, monitoring, etc.
How do we lock down these user accounts so that these "users" have no shell and are not able to login? We want to prevent the possibility that someone can SSH in as one of these user accounts.
shell ssh users login
shell ssh users login
asked Nov 7 '12 at 16:28
SumanSuman
354148
354148
add a comment |
add a comment |
6 Answers
6
active
oldest
votes
You can use the usermod
command to change a user's login shell.
usermod -s /sbin/nologin myuser
or
usermod -s /usr/sbin/nologin myuser
If your OS does not provide /sbin/nologin, you can set the shell to a NOOP command such as /bin/false:
usermod -s /bin/false myuser
1
/bin/false
seems more common than/bin/true
.
– jw013
Nov 7 '12 at 17:19
@jw013 I update my answer, but both should work fine.
– jordanm
Nov 7 '12 at 17:21
1
Note that on Debians,nologin
actually is to be found at/usr/sbin/nologin
– xebeche
Nov 19 '13 at 12:05
this was my first idea, unfortunately the 'valid' use of some user accounts are disabled when settingnologin
– Javier
Dec 11 '14 at 22:46
2
@jw013 Actually I have/usr/local/bin/maybe
which/dev/urandom
ly selects between those two. Maybe I should use it :D
– hegez
Oct 4 '17 at 16:30
|
show 1 more comment
Changing the login shell does not necessarily prevent users from authenticating (except in some services that check if the user's shell is mentioned in /etc/shells
).
People may still be able to authenticate to the various services that your system provides to unix users, and may still be authorized to perform some actions albeit probably not run arbitrary commands directly.
Changing the shell to /bin/false
or /usr/sbin/nologin
will only prevent them from running commands on those services that can be used to run commands (console login, ssh, telnet, rlogin, rexec...), so affect authorisation for some services only.
For ssh
for instance, that still allows them to do port forwarding.
passwd -l
will disable password authentication, but the user may still be allowed to use other authentication methods (like authorized_keys
with ssh
).
With pam
on Linux at least, you can use the pam_shells
module to restrict authentication or authorisation to users with an allowed shell (those mentioned in /etc/shells
). For ssh
, you'll want to do it at authorisation (account
) level as for authentication sshd
uses pam
in addition to other authentication methods (like authorized_keys
), or you can do it with sshd_config
directives in /etc/ssh/sshd_config
(like AllowUsers
and friends).
Beware though that adding some restrictions in global pam authorisation will potentially prevent running cron
jobs as those users.
Thank you. Then what would you recommend given the following schema: I need to create a user who need access to his home folder through sftp or sshfs, but he must not be able to login with a shell. Is that even possible ? I fell like PAM modules may be the goto solution but I do not understand it all:|
– Stphane
Dec 7 '16 at 9:57
@Stphane you can take a look at rssh - manpages.ubuntu.com/manpages/trusty/man1/rssh.1.html
– Hart Simha
Apr 17 '17 at 23:22
add a comment |
You edit the /etc/passwd
file and change the users shell from /bin/bash
, or /bin/sh
to /sbin/nologin
8
The answer is correct, but hand-editing /etc/passwd should never be recommended.
– jordanm
Nov 7 '12 at 17:06
3
Why? This is something we've been doing for as long as I've been a professional sys admin. (about 20 years now) In fact, not all linux/unix distros have tools for modifying /etc/passwd or /etc/group .. Unless you use something like Yast or Smit, which are tools that cache the settings and over-write them there is no harm in hand editing.
– Mark Cohen
Nov 7 '12 at 20:34
6
It's much easier to make a "breaks everyone's login" mistake by hand-editing, rather than a single user.
– jordanm
Nov 7 '12 at 20:55
2
@jordanm: there isvipw
which prevents that kind of mistake.
– eudoxos
Apr 26 '17 at 14:29
add a comment |
You can use chsh command:
~# chsh myuser
Enter new shell details when requested:
Login Shell [/bin/sh]: /bin/nologin
Or shorter version:
~# chsh myuser -s /bin/nologin
add a comment |
First, disable the password, using passwd -l username
.
Also note in the man
page for passwd
for option -l
:
-l, --lock
Lock the password of the named account. This option disables a password by changing it to a value which matches no
possible encrypted value (it adds a ´!´ at the beginning of the password).
Note that this does not disable the account. The user may still be able to login using another authentication token
(e.g. an SSH key). To disable the account, administrators should use usermod --expiredate 1 (this set the account's
expire date to Jan 2, 1970).
Users with a locked password are not allowed to change their password.
1
This may not be desirable. They may need a password on their system account to access email for example.
– jordanm
Nov 7 '12 at 17:43
1
Some email systems allow use of their own password mechanisms. I use Dovecot and Exim with an email only password. This allows use of webmail on servers I would not use my system password. Virtual email domains require their own password as they aren't coupled to the servers password system.
– BillThor
Nov 8 '12 at 13:27
add a comment |
To prevent user from logging and even authentication over ssh that enables port forwarding (as is described here Stephane), I modify the user to be similar to system's nobody
user:
- blocked password authentication in
/etc/shadow
(with*
or!!
at proper field) - disabled shell in
/etc/passwd
(e.g./sbin/nologin
at proper field) - read-only home dir in
/etc/passwd
(e.g./
at proper field)
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%2f55106%2fdisable-user-shell-for-security-reasons%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
6 Answers
6
active
oldest
votes
6 Answers
6
active
oldest
votes
active
oldest
votes
active
oldest
votes
You can use the usermod
command to change a user's login shell.
usermod -s /sbin/nologin myuser
or
usermod -s /usr/sbin/nologin myuser
If your OS does not provide /sbin/nologin, you can set the shell to a NOOP command such as /bin/false:
usermod -s /bin/false myuser
1
/bin/false
seems more common than/bin/true
.
– jw013
Nov 7 '12 at 17:19
@jw013 I update my answer, but both should work fine.
– jordanm
Nov 7 '12 at 17:21
1
Note that on Debians,nologin
actually is to be found at/usr/sbin/nologin
– xebeche
Nov 19 '13 at 12:05
this was my first idea, unfortunately the 'valid' use of some user accounts are disabled when settingnologin
– Javier
Dec 11 '14 at 22:46
2
@jw013 Actually I have/usr/local/bin/maybe
which/dev/urandom
ly selects between those two. Maybe I should use it :D
– hegez
Oct 4 '17 at 16:30
|
show 1 more comment
You can use the usermod
command to change a user's login shell.
usermod -s /sbin/nologin myuser
or
usermod -s /usr/sbin/nologin myuser
If your OS does not provide /sbin/nologin, you can set the shell to a NOOP command such as /bin/false:
usermod -s /bin/false myuser
1
/bin/false
seems more common than/bin/true
.
– jw013
Nov 7 '12 at 17:19
@jw013 I update my answer, but both should work fine.
– jordanm
Nov 7 '12 at 17:21
1
Note that on Debians,nologin
actually is to be found at/usr/sbin/nologin
– xebeche
Nov 19 '13 at 12:05
this was my first idea, unfortunately the 'valid' use of some user accounts are disabled when settingnologin
– Javier
Dec 11 '14 at 22:46
2
@jw013 Actually I have/usr/local/bin/maybe
which/dev/urandom
ly selects between those two. Maybe I should use it :D
– hegez
Oct 4 '17 at 16:30
|
show 1 more comment
You can use the usermod
command to change a user's login shell.
usermod -s /sbin/nologin myuser
or
usermod -s /usr/sbin/nologin myuser
If your OS does not provide /sbin/nologin, you can set the shell to a NOOP command such as /bin/false:
usermod -s /bin/false myuser
You can use the usermod
command to change a user's login shell.
usermod -s /sbin/nologin myuser
or
usermod -s /usr/sbin/nologin myuser
If your OS does not provide /sbin/nologin, you can set the shell to a NOOP command such as /bin/false:
usermod -s /bin/false myuser
edited Jun 17 '17 at 20:46
UTF-8
1,2271826
1,2271826
answered Nov 7 '12 at 17:07
jordanmjordanm
30.3k28492
30.3k28492
1
/bin/false
seems more common than/bin/true
.
– jw013
Nov 7 '12 at 17:19
@jw013 I update my answer, but both should work fine.
– jordanm
Nov 7 '12 at 17:21
1
Note that on Debians,nologin
actually is to be found at/usr/sbin/nologin
– xebeche
Nov 19 '13 at 12:05
this was my first idea, unfortunately the 'valid' use of some user accounts are disabled when settingnologin
– Javier
Dec 11 '14 at 22:46
2
@jw013 Actually I have/usr/local/bin/maybe
which/dev/urandom
ly selects between those two. Maybe I should use it :D
– hegez
Oct 4 '17 at 16:30
|
show 1 more comment
1
/bin/false
seems more common than/bin/true
.
– jw013
Nov 7 '12 at 17:19
@jw013 I update my answer, but both should work fine.
– jordanm
Nov 7 '12 at 17:21
1
Note that on Debians,nologin
actually is to be found at/usr/sbin/nologin
– xebeche
Nov 19 '13 at 12:05
this was my first idea, unfortunately the 'valid' use of some user accounts are disabled when settingnologin
– Javier
Dec 11 '14 at 22:46
2
@jw013 Actually I have/usr/local/bin/maybe
which/dev/urandom
ly selects between those two. Maybe I should use it :D
– hegez
Oct 4 '17 at 16:30
1
1
/bin/false
seems more common than /bin/true
.– jw013
Nov 7 '12 at 17:19
/bin/false
seems more common than /bin/true
.– jw013
Nov 7 '12 at 17:19
@jw013 I update my answer, but both should work fine.
– jordanm
Nov 7 '12 at 17:21
@jw013 I update my answer, but both should work fine.
– jordanm
Nov 7 '12 at 17:21
1
1
Note that on Debians,
nologin
actually is to be found at /usr/sbin/nologin
– xebeche
Nov 19 '13 at 12:05
Note that on Debians,
nologin
actually is to be found at /usr/sbin/nologin
– xebeche
Nov 19 '13 at 12:05
this was my first idea, unfortunately the 'valid' use of some user accounts are disabled when setting
nologin
– Javier
Dec 11 '14 at 22:46
this was my first idea, unfortunately the 'valid' use of some user accounts are disabled when setting
nologin
– Javier
Dec 11 '14 at 22:46
2
2
@jw013 Actually I have
/usr/local/bin/maybe
which /dev/urandom
ly selects between those two. Maybe I should use it :D– hegez
Oct 4 '17 at 16:30
@jw013 Actually I have
/usr/local/bin/maybe
which /dev/urandom
ly selects between those two. Maybe I should use it :D– hegez
Oct 4 '17 at 16:30
|
show 1 more comment
Changing the login shell does not necessarily prevent users from authenticating (except in some services that check if the user's shell is mentioned in /etc/shells
).
People may still be able to authenticate to the various services that your system provides to unix users, and may still be authorized to perform some actions albeit probably not run arbitrary commands directly.
Changing the shell to /bin/false
or /usr/sbin/nologin
will only prevent them from running commands on those services that can be used to run commands (console login, ssh, telnet, rlogin, rexec...), so affect authorisation for some services only.
For ssh
for instance, that still allows them to do port forwarding.
passwd -l
will disable password authentication, but the user may still be allowed to use other authentication methods (like authorized_keys
with ssh
).
With pam
on Linux at least, you can use the pam_shells
module to restrict authentication or authorisation to users with an allowed shell (those mentioned in /etc/shells
). For ssh
, you'll want to do it at authorisation (account
) level as for authentication sshd
uses pam
in addition to other authentication methods (like authorized_keys
), or you can do it with sshd_config
directives in /etc/ssh/sshd_config
(like AllowUsers
and friends).
Beware though that adding some restrictions in global pam authorisation will potentially prevent running cron
jobs as those users.
Thank you. Then what would you recommend given the following schema: I need to create a user who need access to his home folder through sftp or sshfs, but he must not be able to login with a shell. Is that even possible ? I fell like PAM modules may be the goto solution but I do not understand it all:|
– Stphane
Dec 7 '16 at 9:57
@Stphane you can take a look at rssh - manpages.ubuntu.com/manpages/trusty/man1/rssh.1.html
– Hart Simha
Apr 17 '17 at 23:22
add a comment |
Changing the login shell does not necessarily prevent users from authenticating (except in some services that check if the user's shell is mentioned in /etc/shells
).
People may still be able to authenticate to the various services that your system provides to unix users, and may still be authorized to perform some actions albeit probably not run arbitrary commands directly.
Changing the shell to /bin/false
or /usr/sbin/nologin
will only prevent them from running commands on those services that can be used to run commands (console login, ssh, telnet, rlogin, rexec...), so affect authorisation for some services only.
For ssh
for instance, that still allows them to do port forwarding.
passwd -l
will disable password authentication, but the user may still be allowed to use other authentication methods (like authorized_keys
with ssh
).
With pam
on Linux at least, you can use the pam_shells
module to restrict authentication or authorisation to users with an allowed shell (those mentioned in /etc/shells
). For ssh
, you'll want to do it at authorisation (account
) level as for authentication sshd
uses pam
in addition to other authentication methods (like authorized_keys
), or you can do it with sshd_config
directives in /etc/ssh/sshd_config
(like AllowUsers
and friends).
Beware though that adding some restrictions in global pam authorisation will potentially prevent running cron
jobs as those users.
Thank you. Then what would you recommend given the following schema: I need to create a user who need access to his home folder through sftp or sshfs, but he must not be able to login with a shell. Is that even possible ? I fell like PAM modules may be the goto solution but I do not understand it all:|
– Stphane
Dec 7 '16 at 9:57
@Stphane you can take a look at rssh - manpages.ubuntu.com/manpages/trusty/man1/rssh.1.html
– Hart Simha
Apr 17 '17 at 23:22
add a comment |
Changing the login shell does not necessarily prevent users from authenticating (except in some services that check if the user's shell is mentioned in /etc/shells
).
People may still be able to authenticate to the various services that your system provides to unix users, and may still be authorized to perform some actions albeit probably not run arbitrary commands directly.
Changing the shell to /bin/false
or /usr/sbin/nologin
will only prevent them from running commands on those services that can be used to run commands (console login, ssh, telnet, rlogin, rexec...), so affect authorisation for some services only.
For ssh
for instance, that still allows them to do port forwarding.
passwd -l
will disable password authentication, but the user may still be allowed to use other authentication methods (like authorized_keys
with ssh
).
With pam
on Linux at least, you can use the pam_shells
module to restrict authentication or authorisation to users with an allowed shell (those mentioned in /etc/shells
). For ssh
, you'll want to do it at authorisation (account
) level as for authentication sshd
uses pam
in addition to other authentication methods (like authorized_keys
), or you can do it with sshd_config
directives in /etc/ssh/sshd_config
(like AllowUsers
and friends).
Beware though that adding some restrictions in global pam authorisation will potentially prevent running cron
jobs as those users.
Changing the login shell does not necessarily prevent users from authenticating (except in some services that check if the user's shell is mentioned in /etc/shells
).
People may still be able to authenticate to the various services that your system provides to unix users, and may still be authorized to perform some actions albeit probably not run arbitrary commands directly.
Changing the shell to /bin/false
or /usr/sbin/nologin
will only prevent them from running commands on those services that can be used to run commands (console login, ssh, telnet, rlogin, rexec...), so affect authorisation for some services only.
For ssh
for instance, that still allows them to do port forwarding.
passwd -l
will disable password authentication, but the user may still be allowed to use other authentication methods (like authorized_keys
with ssh
).
With pam
on Linux at least, you can use the pam_shells
module to restrict authentication or authorisation to users with an allowed shell (those mentioned in /etc/shells
). For ssh
, you'll want to do it at authorisation (account
) level as for authentication sshd
uses pam
in addition to other authentication methods (like authorized_keys
), or you can do it with sshd_config
directives in /etc/ssh/sshd_config
(like AllowUsers
and friends).
Beware though that adding some restrictions in global pam authorisation will potentially prevent running cron
jobs as those users.
answered Dec 18 '14 at 13:07
Stéphane ChazelasStéphane Chazelas
300k54564916
300k54564916
Thank you. Then what would you recommend given the following schema: I need to create a user who need access to his home folder through sftp or sshfs, but he must not be able to login with a shell. Is that even possible ? I fell like PAM modules may be the goto solution but I do not understand it all:|
– Stphane
Dec 7 '16 at 9:57
@Stphane you can take a look at rssh - manpages.ubuntu.com/manpages/trusty/man1/rssh.1.html
– Hart Simha
Apr 17 '17 at 23:22
add a comment |
Thank you. Then what would you recommend given the following schema: I need to create a user who need access to his home folder through sftp or sshfs, but he must not be able to login with a shell. Is that even possible ? I fell like PAM modules may be the goto solution but I do not understand it all:|
– Stphane
Dec 7 '16 at 9:57
@Stphane you can take a look at rssh - manpages.ubuntu.com/manpages/trusty/man1/rssh.1.html
– Hart Simha
Apr 17 '17 at 23:22
Thank you. Then what would you recommend given the following schema: I need to create a user who need access to his home folder through sftp or sshfs, but he must not be able to login with a shell. Is that even possible ? I fell like PAM modules may be the goto solution but I do not understand it all
:|
– Stphane
Dec 7 '16 at 9:57
Thank you. Then what would you recommend given the following schema: I need to create a user who need access to his home folder through sftp or sshfs, but he must not be able to login with a shell. Is that even possible ? I fell like PAM modules may be the goto solution but I do not understand it all
:|
– Stphane
Dec 7 '16 at 9:57
@Stphane you can take a look at rssh - manpages.ubuntu.com/manpages/trusty/man1/rssh.1.html
– Hart Simha
Apr 17 '17 at 23:22
@Stphane you can take a look at rssh - manpages.ubuntu.com/manpages/trusty/man1/rssh.1.html
– Hart Simha
Apr 17 '17 at 23:22
add a comment |
You edit the /etc/passwd
file and change the users shell from /bin/bash
, or /bin/sh
to /sbin/nologin
8
The answer is correct, but hand-editing /etc/passwd should never be recommended.
– jordanm
Nov 7 '12 at 17:06
3
Why? This is something we've been doing for as long as I've been a professional sys admin. (about 20 years now) In fact, not all linux/unix distros have tools for modifying /etc/passwd or /etc/group .. Unless you use something like Yast or Smit, which are tools that cache the settings and over-write them there is no harm in hand editing.
– Mark Cohen
Nov 7 '12 at 20:34
6
It's much easier to make a "breaks everyone's login" mistake by hand-editing, rather than a single user.
– jordanm
Nov 7 '12 at 20:55
2
@jordanm: there isvipw
which prevents that kind of mistake.
– eudoxos
Apr 26 '17 at 14:29
add a comment |
You edit the /etc/passwd
file and change the users shell from /bin/bash
, or /bin/sh
to /sbin/nologin
8
The answer is correct, but hand-editing /etc/passwd should never be recommended.
– jordanm
Nov 7 '12 at 17:06
3
Why? This is something we've been doing for as long as I've been a professional sys admin. (about 20 years now) In fact, not all linux/unix distros have tools for modifying /etc/passwd or /etc/group .. Unless you use something like Yast or Smit, which are tools that cache the settings and over-write them there is no harm in hand editing.
– Mark Cohen
Nov 7 '12 at 20:34
6
It's much easier to make a "breaks everyone's login" mistake by hand-editing, rather than a single user.
– jordanm
Nov 7 '12 at 20:55
2
@jordanm: there isvipw
which prevents that kind of mistake.
– eudoxos
Apr 26 '17 at 14:29
add a comment |
You edit the /etc/passwd
file and change the users shell from /bin/bash
, or /bin/sh
to /sbin/nologin
You edit the /etc/passwd
file and change the users shell from /bin/bash
, or /bin/sh
to /sbin/nologin
edited Nov 7 '12 at 20:36
answered Nov 7 '12 at 16:43
Mark CohenMark Cohen
1,141712
1,141712
8
The answer is correct, but hand-editing /etc/passwd should never be recommended.
– jordanm
Nov 7 '12 at 17:06
3
Why? This is something we've been doing for as long as I've been a professional sys admin. (about 20 years now) In fact, not all linux/unix distros have tools for modifying /etc/passwd or /etc/group .. Unless you use something like Yast or Smit, which are tools that cache the settings and over-write them there is no harm in hand editing.
– Mark Cohen
Nov 7 '12 at 20:34
6
It's much easier to make a "breaks everyone's login" mistake by hand-editing, rather than a single user.
– jordanm
Nov 7 '12 at 20:55
2
@jordanm: there isvipw
which prevents that kind of mistake.
– eudoxos
Apr 26 '17 at 14:29
add a comment |
8
The answer is correct, but hand-editing /etc/passwd should never be recommended.
– jordanm
Nov 7 '12 at 17:06
3
Why? This is something we've been doing for as long as I've been a professional sys admin. (about 20 years now) In fact, not all linux/unix distros have tools for modifying /etc/passwd or /etc/group .. Unless you use something like Yast or Smit, which are tools that cache the settings and over-write them there is no harm in hand editing.
– Mark Cohen
Nov 7 '12 at 20:34
6
It's much easier to make a "breaks everyone's login" mistake by hand-editing, rather than a single user.
– jordanm
Nov 7 '12 at 20:55
2
@jordanm: there isvipw
which prevents that kind of mistake.
– eudoxos
Apr 26 '17 at 14:29
8
8
The answer is correct, but hand-editing /etc/passwd should never be recommended.
– jordanm
Nov 7 '12 at 17:06
The answer is correct, but hand-editing /etc/passwd should never be recommended.
– jordanm
Nov 7 '12 at 17:06
3
3
Why? This is something we've been doing for as long as I've been a professional sys admin. (about 20 years now) In fact, not all linux/unix distros have tools for modifying /etc/passwd or /etc/group .. Unless you use something like Yast or Smit, which are tools that cache the settings and over-write them there is no harm in hand editing.
– Mark Cohen
Nov 7 '12 at 20:34
Why? This is something we've been doing for as long as I've been a professional sys admin. (about 20 years now) In fact, not all linux/unix distros have tools for modifying /etc/passwd or /etc/group .. Unless you use something like Yast or Smit, which are tools that cache the settings and over-write them there is no harm in hand editing.
– Mark Cohen
Nov 7 '12 at 20:34
6
6
It's much easier to make a "breaks everyone's login" mistake by hand-editing, rather than a single user.
– jordanm
Nov 7 '12 at 20:55
It's much easier to make a "breaks everyone's login" mistake by hand-editing, rather than a single user.
– jordanm
Nov 7 '12 at 20:55
2
2
@jordanm: there is
vipw
which prevents that kind of mistake.– eudoxos
Apr 26 '17 at 14:29
@jordanm: there is
vipw
which prevents that kind of mistake.– eudoxos
Apr 26 '17 at 14:29
add a comment |
You can use chsh command:
~# chsh myuser
Enter new shell details when requested:
Login Shell [/bin/sh]: /bin/nologin
Or shorter version:
~# chsh myuser -s /bin/nologin
add a comment |
You can use chsh command:
~# chsh myuser
Enter new shell details when requested:
Login Shell [/bin/sh]: /bin/nologin
Or shorter version:
~# chsh myuser -s /bin/nologin
add a comment |
You can use chsh command:
~# chsh myuser
Enter new shell details when requested:
Login Shell [/bin/sh]: /bin/nologin
Or shorter version:
~# chsh myuser -s /bin/nologin
You can use chsh command:
~# chsh myuser
Enter new shell details when requested:
Login Shell [/bin/sh]: /bin/nologin
Or shorter version:
~# chsh myuser -s /bin/nologin
answered Dec 18 '14 at 11:32
Let'sTalkLet'sTalk
1211
1211
add a comment |
add a comment |
First, disable the password, using passwd -l username
.
Also note in the man
page for passwd
for option -l
:
-l, --lock
Lock the password of the named account. This option disables a password by changing it to a value which matches no
possible encrypted value (it adds a ´!´ at the beginning of the password).
Note that this does not disable the account. The user may still be able to login using another authentication token
(e.g. an SSH key). To disable the account, administrators should use usermod --expiredate 1 (this set the account's
expire date to Jan 2, 1970).
Users with a locked password are not allowed to change their password.
1
This may not be desirable. They may need a password on their system account to access email for example.
– jordanm
Nov 7 '12 at 17:43
1
Some email systems allow use of their own password mechanisms. I use Dovecot and Exim with an email only password. This allows use of webmail on servers I would not use my system password. Virtual email domains require their own password as they aren't coupled to the servers password system.
– BillThor
Nov 8 '12 at 13:27
add a comment |
First, disable the password, using passwd -l username
.
Also note in the man
page for passwd
for option -l
:
-l, --lock
Lock the password of the named account. This option disables a password by changing it to a value which matches no
possible encrypted value (it adds a ´!´ at the beginning of the password).
Note that this does not disable the account. The user may still be able to login using another authentication token
(e.g. an SSH key). To disable the account, administrators should use usermod --expiredate 1 (this set the account's
expire date to Jan 2, 1970).
Users with a locked password are not allowed to change their password.
1
This may not be desirable. They may need a password on their system account to access email for example.
– jordanm
Nov 7 '12 at 17:43
1
Some email systems allow use of their own password mechanisms. I use Dovecot and Exim with an email only password. This allows use of webmail on servers I would not use my system password. Virtual email domains require their own password as they aren't coupled to the servers password system.
– BillThor
Nov 8 '12 at 13:27
add a comment |
First, disable the password, using passwd -l username
.
Also note in the man
page for passwd
for option -l
:
-l, --lock
Lock the password of the named account. This option disables a password by changing it to a value which matches no
possible encrypted value (it adds a ´!´ at the beginning of the password).
Note that this does not disable the account. The user may still be able to login using another authentication token
(e.g. an SSH key). To disable the account, administrators should use usermod --expiredate 1 (this set the account's
expire date to Jan 2, 1970).
Users with a locked password are not allowed to change their password.
First, disable the password, using passwd -l username
.
Also note in the man
page for passwd
for option -l
:
-l, --lock
Lock the password of the named account. This option disables a password by changing it to a value which matches no
possible encrypted value (it adds a ´!´ at the beginning of the password).
Note that this does not disable the account. The user may still be able to login using another authentication token
(e.g. an SSH key). To disable the account, administrators should use usermod --expiredate 1 (this set the account's
expire date to Jan 2, 1970).
Users with a locked password are not allowed to change their password.
edited Dec 18 '14 at 12:17
Tejas
1,81721839
1,81721839
answered Nov 7 '12 at 17:29
mdpcmdpc
4,94321836
4,94321836
1
This may not be desirable. They may need a password on their system account to access email for example.
– jordanm
Nov 7 '12 at 17:43
1
Some email systems allow use of their own password mechanisms. I use Dovecot and Exim with an email only password. This allows use of webmail on servers I would not use my system password. Virtual email domains require their own password as they aren't coupled to the servers password system.
– BillThor
Nov 8 '12 at 13:27
add a comment |
1
This may not be desirable. They may need a password on their system account to access email for example.
– jordanm
Nov 7 '12 at 17:43
1
Some email systems allow use of their own password mechanisms. I use Dovecot and Exim with an email only password. This allows use of webmail on servers I would not use my system password. Virtual email domains require their own password as they aren't coupled to the servers password system.
– BillThor
Nov 8 '12 at 13:27
1
1
This may not be desirable. They may need a password on their system account to access email for example.
– jordanm
Nov 7 '12 at 17:43
This may not be desirable. They may need a password on their system account to access email for example.
– jordanm
Nov 7 '12 at 17:43
1
1
Some email systems allow use of their own password mechanisms. I use Dovecot and Exim with an email only password. This allows use of webmail on servers I would not use my system password. Virtual email domains require their own password as they aren't coupled to the servers password system.
– BillThor
Nov 8 '12 at 13:27
Some email systems allow use of their own password mechanisms. I use Dovecot and Exim with an email only password. This allows use of webmail on servers I would not use my system password. Virtual email domains require their own password as they aren't coupled to the servers password system.
– BillThor
Nov 8 '12 at 13:27
add a comment |
To prevent user from logging and even authentication over ssh that enables port forwarding (as is described here Stephane), I modify the user to be similar to system's nobody
user:
- blocked password authentication in
/etc/shadow
(with*
or!!
at proper field) - disabled shell in
/etc/passwd
(e.g./sbin/nologin
at proper field) - read-only home dir in
/etc/passwd
(e.g./
at proper field)
add a comment |
To prevent user from logging and even authentication over ssh that enables port forwarding (as is described here Stephane), I modify the user to be similar to system's nobody
user:
- blocked password authentication in
/etc/shadow
(with*
or!!
at proper field) - disabled shell in
/etc/passwd
(e.g./sbin/nologin
at proper field) - read-only home dir in
/etc/passwd
(e.g./
at proper field)
add a comment |
To prevent user from logging and even authentication over ssh that enables port forwarding (as is described here Stephane), I modify the user to be similar to system's nobody
user:
- blocked password authentication in
/etc/shadow
(with*
or!!
at proper field) - disabled shell in
/etc/passwd
(e.g./sbin/nologin
at proper field) - read-only home dir in
/etc/passwd
(e.g./
at proper field)
To prevent user from logging and even authentication over ssh that enables port forwarding (as is described here Stephane), I modify the user to be similar to system's nobody
user:
- blocked password authentication in
/etc/shadow
(with*
or!!
at proper field) - disabled shell in
/etc/passwd
(e.g./sbin/nologin
at proper field) - read-only home dir in
/etc/passwd
(e.g./
at proper field)
answered Dec 31 '18 at 15:03
keypresskeypress
991
991
add a comment |
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.
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%2f55106%2fdisable-user-shell-for-security-reasons%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