Use sulogin Safely in Single-User Recovery

You will finish with a clear, safe way to use sulogin when a Linux system enters single-user mode: select the terminal, control how long it waits, choose the shell, and recognise the one option that can bypass a root password.

Allow about fifteen minutes to read and check the command. You need console or out-of-band access to the machine, the util-linux package, and a maintenance situation where entering a root shell is authorised. Do not run the interactive command on a normal multi-user terminal as a casual test. sulogin is designed to be called by init during single-user recovery.

The installed manpage is from util-linux 2.39.3. On this machine, sulogin --version reports util-linux 2.42.4, so verify the executable on the host you are repairing before relying on a detail that matters to your recovery procedure.

1. Check the installed command

Start with read-only checks. These do not need elevated privileges and do not start a shell:

$ command -v sulogin
/home/linuxbrew/.linuxbrew/sbin/sulogin
$ sulogin --version
sulogin from util-linux 2.42.4 (features: plymouth, keyboard mode, widechar, serial-info)
$ dpkg-query -W -f='${Package} ${Version}\n' util-linux
util-linux 2.39.3-9ubuntu6.6

Your path, package version and feature line may differ. The important checkpoint is that you know which binary and documentation describe the recovery environment. Ask for the built-in syntax too:

$ sulogin --help
Usage:
 sulogin [options] [tty device]

Single-user login.

Options:
 -p, --login-shell        start a login shell
 -t, --timeout <seconds>  max time to wait for a password (default: no limit)
 -e, --force              examine password files directly if getpwnam(3) fails

2. Confirm the recovery boundary before starting it

sulogin is normally invoked when init moves the system into single-user mode. It connects to the current terminal, or to a terminal device supplied as its optional argument, commonly /dev/console. The command then asks for the root password and offers a control-D path for normal startup.

This is the security checkpoint: only continue on a console that is physically protected or otherwise controlled by the people authorised to perform system maintenance. A successful login gives access to a root shell and can change the whole system. Do not paste a remote user's terminal path, and do not treat a serial or virtual console as trusted merely because it is inconvenient to reach.

When you are working through an approved recovery path, the ordinary invocation is:

# sulogin

The # prompt marks a command requiring an already privileged recovery context. In practice, init supplies that context. If you are writing a service or boot integration, keep the command in that controlled single-user path rather than adding it to an ordinary login profile.

3. Select a terminal only when the boot path needs it

With no argument, the program uses the current terminal. Pass a device only when the recovery design explicitly needs a different one:

# sulogin /dev/console

/dev/console is an example, not a universal requirement. Use the exact device presented by the boot or service manager. A wrong or unavailable device can leave an operator waiting at a terminal that is not visible, which looks like an authentication failure but is actually a connection problem.

Checkpoint: before launching, confirm the device exists and is the intended console. These checks inspect state only:

# test -c /dev/console && ls -l /dev/console
crw------- 1 root root 5, 1 ... /dev/console

The owner, permissions and device numbers are host-specific. Do not edit device permissions to make a recovery session work. Fix the boot or console configuration separately if the intended terminal is absent.

4. Bound the wait when unattended recovery must fail closed

By default, sulogin waits forever for input. That is reasonable for a person standing at a protected console, but risky in an automated boot path where an abandoned prompt can hold startup indefinitely. Set a finite number of seconds when the surrounding recovery design has a defined fallback:

# sulogin --timeout 300 /dev/console

This permits up to five minutes for the password prompt. Choose a value that fits the maintenance procedure rather than copying 300 blindly. If the wait expires, verify the behaviour on the exact installed build and boot manager before promising what happens next; the timeout limits input waiting, while the action taken after the program exits belongs to the caller.

Do not add a timeout to a rescue workflow unless the next state is understood. A short value can turn a slow but legitimate repair into an unattended boot, while an unlimited wait can leave a machine stuck because nobody is watching it.

5. Choose login-shell behaviour deliberately

Without extra options, the shell process is started normally. Use --login-shell when the recovery shell must be started as a login shell and the shell's login startup behaviour is part of the procedure:

# sulogin --login-shell /dev/console

A login shell can read different startup files from an interactive non-login shell. Those files may set environment variables, aliases or other behaviour that is unhelpful during repair. Record which shell and startup files your recovery process expects, and keep commands explicit. Do not assume that a familiar interactive prompt proves the environment is clean.

The shell selection has its own default chain. sulogin first checks SUSHELL or sushell. If neither is set, it tries the root account's shell from /etc/passwd, then falls back to /bin/sh. A boot environment can inherit variables, so inspect them before relying on an unexpected shell:

# if [ -n "${SUSHELL:-}" ]; then
>     printf 'SUSHELL=%s\n' "$SUSHELL"
> else
>     printf '%s\n' 'SUSHELL is unset'
> fi

Do not set SUSHELL to an unverified path in a boot script. If the chosen shell is unavailable or unsuitable, correct the controlled recovery configuration and test it on a non-production system first.

6. Treat force mode as a guarded emergency exception

The short option -e, also called --force, is not a general way to skip authentication. It tells sulogin to inspect /etc/passwd and /etc/shadow directly if obtaining the root password through getpwnam(3) fails.

There is a serious boundary here. If those files are damaged or missing, or if the root password begins with ! or * and is therefore locked, the manpage says that force mode starts a root shell without asking for a password. Use it only when you are certain that the console is physically protected against unauthorised access:

# sulogin --force --timeout 300 /dev/console

Before using this option, stop and verify the operator's authority, the console path and the physical or out-of-band access controls. If any of those are uncertain, do not use --force. Prefer repairing the account database or using the approved recovery method with normal password verification.

This option can expose the difference between an account problem and a broken recovery environment. Preserve copies and logs according to your incident process before repairing password files. Do not overwrite /etc/passwd or /etc/shadow from an internet example, and do not remove a lock marker merely to make a boot continue.

7. Exit cleanly and verify the next state

When the maintenance shell exits, or when the operator presses control-D at the prompt, the system continues booting. That makes the exit action service-disrupting: anything not saved is lost, and the machine may return to multi-user operation immediately.

Before leaving the shell, check the specific repair, save configuration deliberately, and record what changed. Then exit in the normal shell way:

# exit

Do not use a forced reboot as an undo operation. sulogin has no persistent setting to roll back in these examples; the command starts a recovery shell and the surrounding boot process decides what follows. If you changed a service configuration, restore the previous file from your approved backup and restart or reload the service according to that service's procedure.

After the machine is reachable again, verify the actual boot state from a normal administrative session. For example, check the relevant service rather than assuming that leaving the shell means every service recovered:

$ systemctl is-system-running
running

The exact result depends on the host and its boot target. A degraded result needs investigation; it is not proof that sulogin failed.