Disable user shell for security reasons












47














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.










share|improve this question



























    47














    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.










    share|improve this question

























      47












      47








      47


      24





      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.










      share|improve this question













      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






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked Nov 7 '12 at 16:28









      SumanSuman

      354148




      354148






















          6 Answers
          6






          active

          oldest

          votes


















          51














          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





          share|improve this answer



















          • 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 setting nologin
            – Javier
            Dec 11 '14 at 22:46






          • 2




            @jw013 Actually I have /usr/local/bin/maybe which /dev/urandomly selects between those two. Maybe I should use it :D
            – hegez
            Oct 4 '17 at 16:30





















          18














          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.






          share|improve this answer





















          • 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



















          4














          You edit the /etc/passwd file and change the users shell from /bin/bash, or /bin/sh to /sbin/nologin






          share|improve this answer



















          • 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 is vipw which prevents that kind of mistake.
            – eudoxos
            Apr 26 '17 at 14:29



















          2














          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





          share|improve this answer





























            2














            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.





            share|improve this answer



















            • 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





















            0














            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)






            share|improve this answer





















              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
              });


              }
              });














              draft saved

              draft discarded


















              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









              51














              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





              share|improve this answer



















              • 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 setting nologin
                – Javier
                Dec 11 '14 at 22:46






              • 2




                @jw013 Actually I have /usr/local/bin/maybe which /dev/urandomly selects between those two. Maybe I should use it :D
                – hegez
                Oct 4 '17 at 16:30


















              51














              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





              share|improve this answer



















              • 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 setting nologin
                – Javier
                Dec 11 '14 at 22:46






              • 2




                @jw013 Actually I have /usr/local/bin/maybe which /dev/urandomly selects between those two. Maybe I should use it :D
                – hegez
                Oct 4 '17 at 16:30
















              51












              51








              51






              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





              share|improve this answer














              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






              share|improve this answer














              share|improve this answer



              share|improve this answer








              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 setting nologin
                – Javier
                Dec 11 '14 at 22:46






              • 2




                @jw013 Actually I have /usr/local/bin/maybe which /dev/urandomly selects between those two. Maybe I should use it :D
                – hegez
                Oct 4 '17 at 16:30
















              • 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 setting nologin
                – Javier
                Dec 11 '14 at 22:46






              • 2




                @jw013 Actually I have /usr/local/bin/maybe which /dev/urandomly 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/urandomly 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/urandomly selects between those two. Maybe I should use it :D
              – hegez
              Oct 4 '17 at 16:30















              18














              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.






              share|improve this answer





















              • 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
















              18














              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.






              share|improve this answer





















              • 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














              18












              18








              18






              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.






              share|improve this answer












              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.







              share|improve this answer












              share|improve this answer



              share|improve this answer










              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


















              • 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











              4














              You edit the /etc/passwd file and change the users shell from /bin/bash, or /bin/sh to /sbin/nologin






              share|improve this answer



















              • 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 is vipw which prevents that kind of mistake.
                – eudoxos
                Apr 26 '17 at 14:29
















              4














              You edit the /etc/passwd file and change the users shell from /bin/bash, or /bin/sh to /sbin/nologin






              share|improve this answer



















              • 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 is vipw which prevents that kind of mistake.
                – eudoxos
                Apr 26 '17 at 14:29














              4












              4








              4






              You edit the /etc/passwd file and change the users shell from /bin/bash, or /bin/sh to /sbin/nologin






              share|improve this answer














              You edit the /etc/passwd file and change the users shell from /bin/bash, or /bin/sh to /sbin/nologin







              share|improve this answer














              share|improve this answer



              share|improve this answer








              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 is vipw which prevents that kind of mistake.
                – eudoxos
                Apr 26 '17 at 14:29














              • 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 is vipw 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











              2














              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





              share|improve this answer


























                2














                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





                share|improve this answer
























                  2












                  2








                  2






                  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





                  share|improve this answer












                  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






                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered Dec 18 '14 at 11:32









                  Let'sTalkLet'sTalk

                  1211




                  1211























                      2














                      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.





                      share|improve this answer



















                      • 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


















                      2














                      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.





                      share|improve this answer



















                      • 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
















                      2












                      2








                      2






                      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.





                      share|improve this answer














                      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.






                      share|improve this answer














                      share|improve this answer



                      share|improve this answer








                      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
















                      • 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













                      0














                      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)






                      share|improve this answer


























                        0














                        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)






                        share|improve this answer
























                          0












                          0








                          0






                          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)






                          share|improve this answer












                          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)







                          share|improve this answer












                          share|improve this answer



                          share|improve this answer










                          answered Dec 31 '18 at 15:03









                          keypresskeypress

                          991




                          991






























                              draft saved

                              draft discarded




















































                              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.




                              draft saved


                              draft discarded














                              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





















































                              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







                              Popular posts from this blog

                              Morgemoulin

                              Scott Moir

                              Souastre