{{Header}} {{title|title= User Management }} {{#seo: |description=Guide to managing users, including creating new users, assigning permissions, and switching between user accounts in {{project_name_short}}. |image=User-management12312.jpg }} {{passwords_mininav}} [[File:User-management12312.jpg|thumb]] {{intro| This guide provides step-by-step instructions for managing user accounts in {{project_name_short}}, enhancing system security and facilitating multi-user environments. }} = Add a New User = Optional! To create a new user account named user2, execute the following command: Note: Replace user2 with the desired username for the new account. {{CodeSelect|code= sudo adduser user2 }} This command will prompt you to set a password and fill in additional information for the new user. Ensuring each user has a unique account helps maintain system security and organizes user-specific configurations. = Allow New User to Login to Virtual Console = Optional! This step is necessary only if the new user account should have access to the [[Desktop#Virtual_Consoles|Virtual Console]] for direct system interaction without a graphical interface. This can be useful for users that will also be members of the sudo group for purposes of [[recovery]]. (This is related to security feature [[Dev/Strong_Linux_User_Account_Isolation#Console_Lockdown|Console Lockdown]].) {{CodeSelect|code= sudo adduser user2 console }} = Allow New User Sudo Access = Optional! If you want user2 to perform administrative tasks with elevated privileges, add them to the sudo group. See also [[Root|Safely Use Root Commands]] for best practices when executing commands as root. {{CodeSelect|code= sudo adduser user2 sudo }} Adding user2 to the sudo group enables them to execute commands with root privileges by prefacing commands with sudo. Use this responsibly to prevent unintended system changes. = Switch User = To switch to the new user account, follow these steps: Start menu → Log Out or Switch User → login * '''Username''': user2 * '''Password''': The password set during the creation of user2. See also: * [[Login]] * [[Root#Substitute_User_.28su.29_Command|Substitute User (su) Command]] = User Restrictions = TODO: document topics not covered yet * restricted shell (any secure available?) * libpam-chroot (might be weak?) * /etc/security/limits.conf * file system quotas * snoopy * Logging off idle users = Meanings of Special Characters in the Password Field of /etc/shadow File = In case you are not using {{ project_name_long }}, it is advisable to consult your OS documentation, as special characters might be different and have different meanings depending on the build flags passed by the package maintainer or yourself when compiling OpenSSH server. The shadowed password file has fields delimited by :. The file stores user passwords in the second field, almost always hashed unless the user set the password manually with a tool that doesn't hash the password. Behind the scenes, shadow(5) interacts with crypt(3) for password manipulation. crypt(3) generates the hashed password, which is always entirely printable ASCII and does not contain whitespace, !, *, :, ;, or \. These characters are reserved for special meanings to be used by interacting tools such as passwd(5) and shadow(5). The usage of ; and \ in the shadow password field is undocumented and possibly dependent on the passwd(5) implementation, using them is discouraged, as programs that read the shadowed password file might not understand their meaning and ignore or break the login. == Table: /etc/shadow Special Characters Comparison Table == {| class="wikitable" |+ Special Characters in the Password Field ! Symbol ! Field ! Meaning ! Explanation |- | ! | First character | Locked password | The account is locked, and the user cannot authenticate using a password. SSHD prohibits all forms of authentication when sshd_config has UsePAM yes. |- | * | First character or after ! | Disabled password | The account is disabled, and the user cannot authenticate using a password. SSHD permits authentication when it is not by password. |- | $PREF$PASS | After password state symbols if present | Hashing scheme and hashed passphrase | The example uses PREF for the hashing scheme and PASS for the hashed passphrase. |- |} There is no standard meaning of the states of locking and disabling a password, their interpretation depends on the tool that is being used for authentication. Not all operating systems have both modes, some only have the locking mode. Fields can coexist and evaluation of characters is done left to right. Here are some examples: {{CodeSelect|code= ! # password empty, locked !! # password empty, never set (Red Hat syntax), unlocked !* # password empty, locked and disabled * # password empty, disabled $PREF$PASS # password set !$PREF$PASS # password set, locked !*$PREF$PASS # password set, locked and disabled *$PREF$PASS # password set, disabled }} The combination !* is the sum of ! and *, which appears on the password field of system users polkitd and systemd-coredump. By default, systemd-sysusers creates accounts disabled using the aforementioned combination. There is no documentation on why this combination is used besides the phrase in sysusers.d(5): ''The account will be created disabled, so that logins are not allowed''. We consider it as a way to emphasize the account shouldn't be ever considered of being logon to. The combination !! is done automatically on some Red Hat's developed operating systems when the user account was created but no password was set, as a way to emphasize for programs reading the shadowed password file that a password should/must still be set and possibly notify the user from time to time to set a password. On other Linux systems, the presence of at least one ! symbol considers the password locked and more than one shouldn't cause any problems or benefits. Different operating systems consider different symbols for locking. This is a non-exhaustive table of discrepancies of locking symbols per operating system: {| class="wikitable" |+ Symbol of Locked Password per Operating System ! Symbol ! OS |- | ! | linux, k*bsd*-gnu and kopensolaris*-gnu |- | * | openbsd |- | *LOCKED* | freebsd |- | *LK* | solaris, irix5, irix6, sysv4.2 and sysv5 |- | Nologin | dec-osf |- |} == Tools to Manage an Account's Password State == Do not edit the /etc/shadow file directly. Instead, use proper tools to interact with it, relevant ones will be listed below by order of recommendation accompanied by their disadvantages. Please note that different operating systems have different options, the options below were only tested on {{project_name_long}}. The recommended tools to use to manage the shadow file is accountctl, developed by {{project_name_long}}, as it avoids common pitfalls that are present in standard utilities. === Locking a Password === "Locking a password". Does that mean the user cannot change their password anymore? No. It means, the user cannot login anymore using the password. The user might still be able to login if a SSH server is installed and the user has set up public key authentication. See also [[SSH]] wiki page chapter [[SSH#SSH_Login_Comparison_Table|SSH Login Comparison Table]]. {| class="wikitable" |+ Locking a Password ! Tool ! Disadvantages |- | accountctl USER lock-pass | Only available in [[{{project_name_long}}]] and its [[derivatives]]. |- | passwd -l,--lock | None. |- | usermod -L,--lock | None. |- | usermod -p '!' | Substitutes everything for !. |- | printf '%s' "USER:!" | chpasswd -c NONE | Substitutes everything for !. |- | useradd | Cannot modify existing user's password. Only works when no password is set with -p,--password PASSWORD. |- | adduser --disabled-login | Cannot modify existing user's password. May also change the shell to /usr/sbin/nologin if --system is used. |- |} === Unlocking a Password === {| class="wikitable" |+ Unlocking a Password ! Tool ! Disadvantages |- | accountctl USER unlock-pass | Account will become passwordless if only the lock symbol is present. Only available in [[{{project_name_long}}]] and its [[derivatives]]. |- | passwd -u,--unlock | Cannot unlock when password is empty. |- | usermod -U,--unlock | Cannot unlock when password is empty. |- |} To unlock an account with a locked password, it's required to first set a password. After setting the password, the user might opt-in to === Disabling a Password === {| class="wikitable" |+ Disabling a Password ! Tool ! Disadvantages |- | accountctl USER disable-pass | Only available in [[{{project_name_long}}]] and its [[derivatives]]. |- | usermod -p '*' | Substitutes everything for *. |- | printf '%s' "USER:*" | chpasswd -c NONE | Substitutes everything for *. |- | adduser --disabled-password | Cannot modify existing user's password. |- |} === Enabling a Password === {| class="wikitable" |+ Enabling a Password ! Tool ! Disadvantages |- | accountctl USER enable-pass | Account will become passwordless if only the lock symbol is present. Only available in [[{{project_name_long}}]] and its [[derivatives]]. |- |} === Setting a Password === For detailed and simple user instructions, see [[Post_Install_Advice#Change_Password|Post Install Advice, Change Password]]. The following table is rather for advanced users and academic interest. '''Table:''' ''Overview of Password Setting Utilities'' {| class="wikitable" |+ Setting a Password ! Tool ! Disadvantages |- | printf '%s' "USER:PASS" | chpasswd | None. |- | passwd | Requires a terminal (unless it has the --stdin option). |- | adduser | Cannot modify existing user's password. Requires interaction. |- | useradd -p,--password PASSWORD | Cannot modify existing user's password. Expect the password to be already encrypted. Password will be visible in the process list. Cannot lock and set a password with a single command. |- | usermod -p,--password PASSWORD | Expect the password to be already encrypted. Password will be visible in the process list. Cannot lock and set a password with a single command. |- | pwchange | Interactive. Only available in [[{{project_name_long}}]] and its [[derivatives]]. Part of usability-misc package and in the future will probably be moved to helper-scripts package. |- |} === Empty Password === * '''Set a new password if necessary:''' In situations where the password is locked and empty, you must set a new password for the account to ensure its security. * '''Deleting a password may be risky:''' Deleting the password entirely will leave the password field empty. This may be dangerous in some situations as it allows passwordless login using only the account name. If enabling or unlocking a password, always set a password first to avoid race conditions. ** '''SSH:''' Should be secure, because [[SSH]] does not enable PermitEmptyPasswords by default. See also: [[SSH#SSH_Login_Comparison_Table|SSH Login Comparison Table]] ** '''Logins:''' In case [[Protection_Against_Physical_Attacks|Protection against Physical Attacks]] is part of the user's threat model, [[login]] into {{cli}} [[Desktop#Virtual_Consoles|Virtual Consoles]] or {{gui}} [[Protection_Against_Physical_Attacks#Login_Screen|Login Screen]] is at risk in context of: *** [[Protection_Against_Physical_Attacks#Virtual_Consoles|Protection against Physical Attacks, Virtual Consoles]], *** [[Protection_Against_Physical_Attacks#Login_Screen|Login Screen]], and *** [[Protection_Against_Physical_Attacks#Screen_Lock|Screen Lock]]. ** '''Servers''': For remote server use, it is essential to either set user account passwords or disable accounts to block logins via the virtual console. Refer to [[Server_Security_Guide#User_Account_Password_Security|Server Security Guide, User Account Password Security]]. ** '''See also:''' This is also elaborated on the [[Default_Passwords|Default Passwords]] wiki page. = User login shell = Setting the user accounts's shell to nologin might be a good additional measurement for preventing logins to get a shell. This can be done with the following command. Note: Replace with the actual account name. {{CodeSelect|code= sudo chsh --shell /usr/sbin/nologin }} Please note that preventing shell login does not prevent all types of logins. SSH login with AllowTCPForwarding yes (optionally with PermitOpen or PermitListen) for example, would allow login, TCP forwarding communication between the client and the server but no shell. = Resources = * https://wiki.debian.org/UserAccounts * https://wiki.debian.org/UserAccountsPhilosophy * https://wiki.debian.org/UserPrivateGroups = Attribution = {{sdebian |link=https://www.debian.org/doc/manuals/securing-debian-manual/ch04s11.en.html#user-limits |text=Limiting resource usage: the limits.conf file }} {{sdebian |link=https://www.debian.org/doc/manuals/securing-debian-manual/ch04s11.en.html#user-restrict |text=Restricting users's access }} {{sdebian |link=https://www.debian.org/doc/manuals/securing-debian-manual/ch04s11.en.html#idm1440 |text=User auditing }} {{sdebian |link=https://www.debian.org/doc/manuals/securing-debian-manual/ch04s17.en.html |text=File system limits and control, Using quotas }} {{reflist|close=1}} {{Footer}} [[Category:Documentation]]