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.

6 Answers 6


You can use the usermod command to change a user's login shell.

usermod -s /sbin/nologin myuser


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
  • 2
    /bin/false seems more common than /bin/true.
    – jw013
    Nov 7, 2012 at 17:19
  • @jw013 I update my answer, but both should work fine.
    – jordanm
    Nov 7, 2012 at 17:21
  • 1
    Note that on Debians, nologin actually is to be found at /usr/sbin/nologin
    – xebeche
    Nov 19, 2013 at 12:05
  • this was my first idea, unfortunately the 'valid' use of some user accounts are disabled when setting nologin
    – Javier
    Dec 11, 2014 at 22:46
  • 3
    @jw013 Actually I have /usr/local/bin/maybe which /dev/urandomly selects between those two. Maybe I should use it :D
    – hegez
    Oct 4, 2017 at 16:30

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, 2016 at 9:57
  • @Stphane you can take a look at rssh - manpages.ubuntu.com/manpages/trusty/man1/rssh.1.html
    – Hart Simha
    Apr 17, 2017 at 23:22

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, 2012 at 17:06
  • 5
    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, 2012 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, 2012 at 20:55
  • 2
    @jordanm: there is vipw which prevents that kind of mistake.
    – eudoxos
    Apr 26, 2017 at 14:29

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, 2012 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, 2012 at 13:27

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

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)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.