How to switch user in Linux: su, su - and sudo -i, with the errors fixed

su - alice                    # become alice, full login (her password)
su -                          # become root, full login (root's password)
sudo -i                       # root shell with YOUR password (Ubuntu default)
sudo -iu alice                # alice's login shell with YOUR password
exit                          # back to the account you came from

Everything below was checked against the su, sudo and sudoers man pages and run on one of our Debian 12 servers (util-linux 2.38.1, sudo 1.9.13p3). The su on Debian 13 and Ubuntu 24.04 is the same util-linux program in a newer version; Debian 13 (util-linux 2.41) adds one option, -T/--no-pty. The “Switch User” entry in the GNOME or KDE menu is a different thing: it opens a second graphical login and leaves your desktop session running. This guide is about the terminal.

su syntax and options

The full form from the man page is su [options] [-] [user [argument...]]. Without a user, su means root. It asks for the password of the account you switch to, not your own, which is the single biggest difference from sudo. Root can switch to any account without a password.

Two details the man page states and most tutorials skip. First, -p is ignored when you also give - or --login. Second, -s only works as a normal user if the target account has a real shell: when its shell is not listed in /etc/shells (for example /usr/sbin/nologin), --shell is ignored unless you are root. That is why su -s /bin/bash www-data works from a root shell and nowhere else.

su returns the exit status of the command it ran, so su - alice -c './backup.sh' fails a script when the backup fails. A command that does not exist gives 127, one that cannot be executed gives 126, and a problem in su itself (wrong password, unknown user) gives 1.

su vs su -: what the dash changes

Without the dash, su changes who you are and almost nothing else. The man page says it keeps the current directory and sets only HOME and SHELL (plus USER and LOGNAME for a non-root target), and it recommends always using the login form. We switched to the www-data account both ways with a variable FOO=bar set in the calling shell:

$ su -s /bin/bash -c 'pwd; echo "HOME=$HOME USER=$USER"; echo "FOO=$FOO"; echo "$0"' www-data
~/su-test                          # same directory as before
HOME=/var/www USER=www-data
FOO=bar                            # your variables come along
bash

$ su - -s /bin/bash -c 'pwd; echo "HOME=$HOME USER=$USER"; echo "PATH=$PATH"; echo "FOO=$FOO"; echo "$0"' www-data
/var/www                           # the target's home
HOME=/var/www USER=www-data
PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
FOO=                               # environment cleared
-bash                              # leading dash = login shell

The PATH is where the difference bites. Plain su keeps your PATH, and on Debian a normal user’s PATH has no /usr/sbin. So you become root, type usermod or reboot, and get “command not found” although you are root. Our test gave the root shell a normal user’s PATH first:

$ su -c 'command -v usermod || echo "usermod: not on PATH"'
usermod: not on PATH

$ su - -c 'command -v usermod'
/usr/sbin/usermod

With the dash, su sets PATH from /etc/login.defs: ENV_SUPATH for root (on Debian 12 /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin) and ENV_PATH for everyone else. The login shell then reads /etc/profile, which on Debian 12 sets PATH again to the same two values, and after that the target’s ~/.profile, which may add more. The other side effect of plain su is subtler: files you create can end up in your old directory, and programs that read your own config through variables like EDITOR or XDG_CONFIG_HOME now run with root rights. Use su - unless you have a reason not to.

su -p goes the other way and keeps everything. In our test, su -p -s /bin/bash www-data ran as www-data but still reported HOME=/root and USER=root, so any program that writes to $HOME tries to write into root’s home and fails. Keep -p for the rare case where you need exactly that, and use -w VAR1,VAR2 when you only want to carry a variable or two into a login.

su vs sudo: which command does what

su asks for the target’s password and gives you their account until you exit. sudo asks for your password, checks /etc/sudoers for what you may do, logs each command, and by default does not ask again for 15 minutes. The table compares the five forms people actually type, measured on Debian 12:

sudo su - still works and gives the same root login as sudo -i; it just runs one extra program, and the sudo log shows su as the command instead of the shell. To become another user without knowing their password, sudo -iu alice is the direct form of sudo su - alice. Both need an account with sudo rights; if yours has none, sudo answers that you are not in the sudoers file.

One trap with sudo -s and sudo -i

Both pass a command to the shell, but they first escape every character except letters, digits, underscores, hyphens and dollar signs. A quoted command line therefore arrives as one long word (with $HOME already filled in) and fails:

$ sudo -s 'pwd; echo $HOME'
/bin/bash: line 1: pwd; echo /root: No such file or directory

$ sudo -u www-data bash -c 'whoami; echo $HOME'
www-data
/var/www

For more than one command, call the shell yourself (sudo -u USER bash -c '...') or use su - USER -c '...', where the quoted string is handed to the shell unchanged.

su: Authentication failure (and other su errors)

su: Authentication failure is PAM’s standard message for a password that did not work. The common cause on a fresh Ubuntu install is not a typo: Ubuntu disables the root account by giving it a password hash that matches no possible password, so su and su - fail for root no matter what you type. Debian does the same when you leave the root password empty in the installer: root is disabled, sudo is installed and the first user gets sudo rights.

Every failed attempt is logged: su writes it to the btmp file (read it with sudo lastb), and PAM records it in the system log (journalctl or /var/log/auth.log), so a burst of failures from a teammate guessing the root password shows up there. And if sudo itself is missing on a minimal Debian install, su - with the root password is the way in; sudo: command not found walks through installing it from there.

Switch to a service account with no shell

Accounts such as www-data, postgres or nobody exist to run one service. Most have /usr/sbin/nologin as their shell, so a plain switch prints the nologin message and exits with status 1:

$ grep '^www-data:' /etc/passwd
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin

$ su - www-data
This account is currently not available.

$ sudo -u www-data -i
This account is currently not available.

You usually do not need a shell at all, only a command run as that user, for example to test whether the web server can read a file. Any of these does it:

sudo -u www-data cat /var/www/site/config.php      # from a sudo user
sudo -u www-data bash -c 'whoami; ls -l ~'          # several commands
su -s /bin/bash -c 'whoami' www-data                # as root, without sudo
runuser -u www-data id                              # as root, in scripts

For an interactive shell as the service user, sudo -u www-data -s starts your own shell (from the SHELL variable) under that account, and su - -s /bin/bash www-data does the same from a root shell. Both worked in our test. Accounts without a real home, like nobody with /nonexistent, add a harmless warning: su: warning: cannot change directory to /nonexistent: No such file or directory.

Two cautions. Do not change a service account’s shell to /bin/bash with usermod -s to make switching easier: nologin is part of what stops that account from logging in, and anyone who later gets the web server to run a command would land in a full shell. And for scripts that root runs, the man page recommends runuser over su: it does not ask for a password and has its own PAM configuration, so cron jobs and systemd units do not depend on su’s settings. When the account you want to switch to is one whose name you do not know yet, getent passwd lists every account with its shell in the last field.

Go back to your user: exit

su does not replace your session; it starts a new shell on top of it. Leave that shell with exit, logout (login shells only) or Ctrl+D, and you are back in the shell you started from, as the user you were, in the directory you were in. Each su adds a layer, so after su - alice and then su - you need two exits to get back to yourself. whoami tells you who you are at the moment.

whoami          # alice
su -            # root's password
whoami          # root
exit
whoami          # alice again

Running one command with -c needs no exit at all: su runs it, returns its exit status and you are back. That is also the safer habit on a shared server, because a root shell left open in a forgotten tmux window is root for anyone who reaches that terminal.

Which one should you use on a server?

• Ubuntu, or any server where your account has sudo: sudo -i for root, sudo -iu USER for another account, sudo -u USER cmd for one command. Every command is logged with your name, and nobody needs the root password.
• Debian installed with a root password and no sudo: su -. Always with the dash.
• Inside root-run scripts, cron and systemd: runuser -u USER or su - USER -c '...'; in a unit file, prefer User= over either.
• Service accounts with nologin: sudo -u USER cmd, or su -s /bin/bash USER as root. Leave their shell alone.

If you set up a new box and still log in as root, the first ten minutes on a new VPS covers creating your own account and giving it sudo, after which sudo -i is all you need. On our Standard KVM plans you get full root on every Linux image, and if a PAM or sudoers change ever locks you out of both su and sudo, the VNC console in the panel still gives you a login prompt on the server.

Frequently asked