1. Overview

Managing access boundaries for non-root users is a crucial task for system administrators. Without proper knowledge in this regard, we can put our system at grave risk. Thus, for security purposes, it’s good practice to restrict users from logging into our server.

In this tutorial, we’ll see how to configure new Linux users without a login feature. In particular, we’ll explore the following options:

  • when is the nologin shell assigned
  • adduser with the –disabled-login flag
  • creating a user with the false shell

Let’s go through each.

2. The nologin Shell

When checking the entries in the /etc/shells file, it’s possible to see the nologin (/usr/sbin/nologin) shell. In reality, nologin is not a shell, but it mostly works as a placeholder for users that are disabled.

If a user’s shell is nologin, they’re restricted from starting a command-line session. However, these users can still be used for other purposes:

A nologin shell is a good solution for a user that requires only FTP access to a host. However, this user won’t be able to connect to the system via SSH. Of course, processes can still execute with this user’s ID.

In some distributions, many standard users are configured with the nologin shell. We can extract the complete list of such users from the /etc/passwd file:

$ cat /etc/passwd | grep nologin

Here, we filter accounts with nologin shells via the grep command. The last field of each line in /etc/passwd contains the login shell.

2.1. Creating a nologin System User

Basically, system users exist to run non-interactive background processes. Since we don’t need to log in as system users, they don’t need passwords.

First, let’s create a system user systemuser1 and check their default assigned shell:

$ sudo adduser systemuser1 --system
Adding system user `systemuser1' (UID 113) ...
Adding new user `systemuser1' (UID 113) with group `nogroup' ...
Creating home directory `/home/systemuser1' ...

In this command, adduser (similar to useradd) creates the specified user of the system type via the –system option. System users have a UID below 1000. Again, we don’t need to assign a password.

Now, let’s see what /etc/passwd contains about our new user:

$ cat /etc/passwd | grep systemuser1

As we see, systemuser1, like other system users, has the /usr/sbin/nologin shell by default, which means they can’t log in:

$ su systemuser1
This account is currently not available.

Evidently, we can’t su to a nologin user.

2.2. Creating a nologin Normal User

Let’s now create a normal user with the nologin shell, i.e., /usr/sbib/nologin:

$ sudo adduser testuser1 --shell /usr/sbin/nologin
Adding user `testuser1' ...
Adding new group `testuser1' (1002) ...
Adding new user `testuser1' (1002) with group `testuser' ...
Creating home directory `/home/testuser1' ...
Copying files from `/etc/skel' ...
New password: 

Here, we have to assign the respective shell via the –shell option. Consequently, testuser1 will not be able to log in because of the nologin shell. In fact, we’ll see the same error from su:

$ su testuser1
This account is currently not available.

Naturally, the user’s line in /etc/passwd contains our shell assignment.

3. Using adduser With the –disabled-login Flag

Let’s now create a non-system user testuser2 with a disabled login. To do that, we’ll use the –disabled-login option of the adduser command:

$ sudo adduser testuser2 --disabled-login
Adding user `testuser2' ...
Adding new group `testuser2' (1001) ...
Adding new user `testuser2' (1001) with group `testuser2' ...
Creating home directory `/home/testuser2' ...
Copying files from `/etc/skel' ...

The user creation is almost the same as for a system user, but with the –disabled-login flag. The latter ensures no password-setting utility (like passwd) runs as part of the user creation process. Thus, until a password’s provided to the account, it won’t be active.

Let’s see what happens when we try to switch to this user:

$ su - testuser2

Clearly, we can’t log in with our user testuser2 since we have no password. Critically, we can simply use any standard tool to assign a password.

Again, let’s check the /etc/passwd file for testuser2:

$ cat /etc/passwd | grep 'testuser2'

Although we aren’t able to log in, the shell for our user is still /bin/bash.

Naturally, we can also completely disable an account or restrict existing users from logging in using the usermod command.

4. The false Shell

Indeed, Debian systems like Ubuntu use the /usr/sbin/nologin shell for non-login users. However, some built-in accounts also work with /bin/false.

Similar to nologin, false is not really a shell but a command. To see the list of users with /bin/false as a shell, we can again turn to /etc/passwd:

$ cat /etc/passwd | grep /bin/false
tss:x:106:111:TPM software stack,,,:/var/lib/tpm:/bin/false

The entry for each such user ends with the location of false/bin/false.

Of course, users with /bin/false as a shell aren’t able to log in as usual. However, they can still get emails and work with other utilities.

Let’s create a user with the /bin/false shell:

$ sudo adduser testuser3 --shell=/bin/false
Adding user `testuser3' ...
Adding new group `testuser3' (1001) ...
Adding new user `testuser3' (1001) with group `testuser3' ...
Creating home directory `/home/testuser3' ...

Here, the –shell or -s flag sets the login shell for the user. After we’ve entered the information for the user, let’s try a switch:

$ su - testuser3

Here, we’ll notice that there will be no login screen and we’ll just return to our current terminal session. Importantly, if we don’t provide any password to a user, they won’t be able to login in via the terminal.

The same is true when we try to ssh with this user:

ssh testuser3@lhb
testuser3@lhb's password:
Connection to lhb closed.

Consequently, the connection will terminate automatically.

5. Conclusion

In this article, we learned how to create a user without the ability to log in. We explored three methods and checked the consequences of each in detail.

Using these simple methods, we can create users with a no-login feature.

Comments are open for 30 days after publishing a post. For any issues past this date, use the Contact form on the site.