How To Restrict Log In Capabilities of Users on Ubuntu

Updated on January 3, 2023
How To Restrict Log In Capabilities of Users on Ubuntu


A fundamental part of system administration is configuring and managing users and groups. Part of this task involves monitoring the log in capabilities of all system entities.

In this guide, we will introduce the ideas behind user management and authentication logging.

We will be exploring these concepts on a Ubuntu 22.04 server, but you can follow along on any modern Linux distribution. You can set up a Ubuntu 22.04 server for this tutorial by following our guide to Initial Server Setup on Ubuntu 22.04.

As mentioned in the previous tutorial in this series, some of the users on your server may be associated with services, and are not intended to be used as regular accounts.

In this section, you will review how to restrict the login capabilities of these users in a number of ways.

How To Restrict Access With /etc/passwd

One method of restricting the login capabilities is to set the account’s login shell to a special value.

An example of this is the messagebus user, which you can use grep to search for within the /etc/passwd file:

  1. less /etc/passwd | grep messagebus

The final value is the shell or the command that is run when the login is successful. In this case, the value is set to /usr/sbin/nologin.

If you try to switch to the messagebus user using sudo su, it will fail:

  1. sudo su messagebus
This account is currently not available.

You receive this message because the shell for messagebus is set to /usr/sbin/nologin.

You can use the usermod tool to change a user’s default login shell (usually /bin/bash) to a nonexistent shell like nologin when you need to prevent them from logging in.

  1. sudo usermod -s /usr/sbin/nologin username

How To Restrict Access With /etc/shadow

Another, similar method of restricting access is to use the /etc/shadow file. This file contains the hashed password values of every user on the system.

You can use less to view the entire file:

  1. sudo less /etc/shadow
. . . uuidd:*:19105:0:99999:7::: tcpdump:*:19105:0:99999:7::: sshd:*:19105:0:99999:7::: pollinate:*:19105:0:99999:7::: landscape:*:19105:0:99999:7::: lxd:!:19180:::::: sammy:$y$j9T$4gyOQ5ieEWdx1ZdggX3Nj1$AbEA9FsG03aTsQhl.ZVMXatwCAvnxFbE/GHUKpjf9u6:19276:0:99999:7:::

The second field (the one starting with $y$j9T$4gyO… in the last line) contains the hashed password value.

The system accounts have an asterisk (*) instead of a complex hash value. Accounts with an asterisk in the second field have not had a password set and are not able to authenticate by password without changing this.

You can disable a password value (in effect, making an account with a password equivalent to the asterisk value), by preceding the hash value with an exclamation point (!).

Two tools can do this by “locking” the specified account.

The passwd command can be locked with the -l flag and unlocked with the -u flag:

  1. sudo passwd -l sammy
  1. sudo less /etc/shadow | grep sammy

As you can see, the hashed password is retained, but made invalid by placing a ! in front of it.

The account can be unlocked again by typing:

  1. sudo passwd -u sammy

Equivalent operations are available using the usermod command. The corresponding flags are -L for locking, and -U for unlocking:

  1. sudo usermod -L sammy
  2. sudo usermod -U sammy

Note: While this method of restricting access will function correctly for all password-based logins, methods of logging in without a password (for example, with ssh keys) will still remain available.

How To Restrict Access With /etc/nologin

There may be some situations when you need to disable all account logins, other than root.

This could be because of in-depth maintenance, or because one or more of your user accounts has been compromised.

In any case, this can be accomplished by creating a file at /etc/nologin:

  1. sudo touch /etc/nologin

This will prevent any account from logging in that does not have superuser privileges.

With an empty /etc/nologin file, this just dumps the user back to their local shell without any explanation.

What is really happening is that the contents of the file are returned to the user. If you add a message, users will receive an explanation for the login failure:

  1. sudo sh -c 'echo "Planned maintenance. Log in capabilities will be restored at 1545 UTC" > /etc/nologin'

Now when you try to log in with a password, you will receive this message:

  1. ssh sammy@host
sammy@host's password: Planned maintenance. Log in capabilities will be restored at 1545 UTC Connection closed by host

Root users can still log in normally. Remove the “/etc/nologin” file to reverse the login restriction:

  1. sudo rm /etc/nologin


User authentication on Linux is a relatively flexible area of system management. There are many ways of accomplishing the same objective with widely available tools.

You should now know how to restrict usage through various methods.

In the next part of this tutorial series, you will review how to monitor user logins.

Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases.

Learn more about us

About the authors

Default avatar

Senior DevOps Technical Writer

Still looking for an answer?

Ask a questionSearch for more help

Was this helpful?

This textbox defaults to using Markdown to format your answer.

You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!

Good article, thanks!


Kamal Nasser
DigitalOcean Employee
DigitalOcean Employee badge
August 9, 2014

@narin: Yes, it’ll make the Remote Console unusable as you wouldn’t be able to log in as root. You can disable root SSH login by setting PermitRootLogin to No or without-password (SSH key-login only) in /etc/ssh/sshd_config and restarting ssh:

sudo service ssh restart

Suppose I am always access the host as root via the Console Access within digitalocean.com

Is it okay to set /user/sbin/nologin to root in order to prevent anyone attempted to root access via other means such as ssh? Will this also make the Console Access not usable?

I want to try this out but not yet dare to, since I might not be able to root access anymore if incorrectly done.

Thanks Narin

Try DigitalOcean for free

Click below to sign up and get $200 of credit to try our products over 60 days!

Sign up

Join the Tech Talk
Success! Thank you! Please check your email for further details.

Please complete your information!

Get our biweekly newsletter

Sign up for Infrastructure as a Newsletter.

Hollie's Hub for Good

Working on improving health and education, reducing inequality, and spurring economic growth? We'd like to help.

Become a contributor

Get paid to write technical tutorials and select a tech-focused charity to receive a matching donation.

Welcome to the developer cloud

DigitalOcean makes it simple to launch in the cloud and scale up as you grow — whether you're running one virtual machine or ten thousand.

Learn more
DigitalOcean Cloud Control Panel