Logging in as root on Ubuntu: su, sudo -i, and when you actually need it

You rent a VPS from WeaselCloud, and right there in the panel, on the server's page, it already tells you: login root, and a real password next to it. Log in with that and you're already root, no separate user, no sudo. Convenient, but that exact convenience is what causes the confusion: half the tutorials online are written for a different world, one where your VPS ships with a regular user and a locked-out root, where commands like su - behave nothing like they do for you. Here's what root actually is, how sudo, sudo -i, sudo su -, and su - differ, and why su - fails outright on many other providers while it just works for you.

Takeaways. Root is a user account with UID 0 and the widest administrative rights on the system, not a "mode" you flip on somewhere. On a WeaselCloud VPS, root SSH login is on from day one - the login and password are shown right in the panel, and su - or ssh root@ will work with that same password. That's convenient to get started, but it doesn't mean you should live in a root shell full-time: every command runs immediately, with no distinction between "ordinary" and "privileged" actions. sudo gives root privileges for one command and doesn't open a separate session. sudo -i and sudo su - land you in the same place on a typical Ubuntu box - an interactive root session with /root as home - but the mechanics differ, covered below. If you'd rather work more safely, set up a separate sudo user and only switch to root when you actually need it - covered below too.

What root actually is

Root is a regular Linux account, structured the same way as any other user, except its user ID is 0. You can check this yourself:

head -1 /etc/passwd

You'll see a line like root:x:0:0:root:/root:/bin/bash. The two zeros right after root:x: are the UID and GID, the numeric IDs the kernel actually uses internally. root is the superuser: UID 0, with the widest administrative rights an ordinary system grants - it can read and write any file, kill any process, change network configuration, mount and unmount disks. That's not an "admin mode" toggle somewhere in the system. It's one specific account you log into, the same way you'd log into any other, if you have the password or the key for it.

Why you already have root - and why not everyone does

This is where WeaselCloud differs from a lot of big cloud providers, and the difference explains most of the confusion about root online. The standard Ubuntu cloud image (the one nearly every provider builds on, WeaselCloud included) locks root by default: no password, no SSH login for root at the daemon level, one regular user created instead. But when WeaselCloud provisions a server on top of that image, it sets a real root password and opens direct SSH access with it, then shows you that password right in the panel, on the server's page. It's a deliberate choice for a smoother first login - no need to learn sudo and user accounts just to get onto a server you just created.

That's exactly why tutorials disagree with each other. A guide written for, say, DigitalOcean or a plain cloud image will honestly tell you "create a sudo user first, root has no password by default" - and that's true for that environment. On WeaselCloud, the same su - command just works, with the real root password, because the provider already turned on what you'd otherwise have to enable by hand elsewhere.

That convenience has a cost: if you always work as root, a mistake in one command runs immediately, with no confirmation step the way sudo has. Anyone who guesses or steals the root password gets full access outright, not one privileged command with a log entry behind it. The rest of this article covers how to use this safely, and how to set up a separate sudo user instead of living in a root shell full-time, if that's what you'd rather do.

Checking whether you actually have root access

Before you worry about which login method to use, confirm your user actually has sudo rights in the first place. This command lists the groups your current user belongs to:

groups

Look for sudo in the output - if it's there, your account is at least eligible to escalate. This second command is more precise, it shows exactly what you're allowed to run:

sudo -l

• a fully-privileged user shows a line like (ALL : ALL) ALL, meaning "can run any command as any user";
• a restricted user shows a specific list of allowed commands instead;
• if your user isn't in sudoers at all, you'll get Sorry, user ubuntu may not run sudo on host, and every command below this point is off the table until someone with root access adds you to the sudo group.

The very first time you run sudo in a session, Ubuntu typically prints a short one-time notice that your actions are being logged. That's expected behavior, not an error, and it won't repeat for the rest of the session.

sudo command - a one-time pass, not a session

The most common and safest way to touch root privileges is running a single command as root without opening a separate session at all. sudo doesn't start a new login: it runs only the command you gave it with elevated privileges and immediately hands control back to your regular shell. Your current working directory usually stays put, but the command's own environment gets filtered by sudo's rules - that's not quite the same thing as "nothing changes."

sudo apt update
sudo systemctl restart nginx

sudo typically asks for your own password, not root's, on the first privileged command in a session, then reuses that cached authorization for a while - 15 minutes by default on Ubuntu, unless an admin changed the timeout. So the second command right after, like restarting nginx here, usually won't prompt again - that's expected, not a bug. Run sudo -k if you want to drop the cached credential right away. Either way, each command only applies to itself: the moment it finishes, you're back to being a plain user, with no lingering root session anywhere. For most day-to-day server work this is all you need: installing a package, restarting a service, reading a system file with sudo cat.

sudo -i - a full root login

Once you need several root-level commands in a row - editing multiple config files, digging through logs across directories, running a maintenance script - typing sudo before every line gets tedious. That's what sudo -i is for: the -i flag stands for "simulate initial login," and it opens a genuine root session, as if you'd logged in as root from scratch.

sudo -i

After you enter your own password, the prompt changes: what was ubuntu@host:~$ becomes root@host:~#. The switch from $ to # is Ubuntu's standard visual cue for a root session - don't rely on color alone to notice it. The working directory changes too: $HOME is now /root, not your old home directory, and a bare cd will drop you there. Root's own shell profile loads, with root's own environment variables, not yours.

To leave the root session and go back to your own user, type exit or press Ctrl+D. The prompt returns to $.

sudo su - vs sudo -i - what actually differs

Older tutorials tend to write sudo su - instead of sudo -i. The end state looks similar, but the mechanism is genuinely different, not just "historically" different. sudo -i runs the target user's shell itself as a login shell and builds the environment by its own rules. sudo su - does it in two steps: sudo first elevates you to root just enough to run the su command, then su - itself (the trailing dash matters) builds a fresh login environment again, by its own rules, through PAM. That extra layer means PATH, environment variables, and what ends up in audit logs can, in theory, differ a little between the two.

sudo su -

On a typical Ubuntu box both get you to the same place in practice: an interactive root session with /root as home, and for everyday work the difference rarely matters. But sudo -i does it directly, which makes it more predictable; sudo su - runs an extra su process on top and doesn't buy you anything sudo -i doesn't already give you, so there's no real reason to switch to it on purpose. If sudo su - is what your fingers already type and it's caused no issues, there's no reason to unlearn it either.

su - without sudo - why it just works on WeaselCloud

This is the part that trips up almost everyone who's read about Linux somewhere else first. Run su - on its own, without sudo in front of it, and it asks for a password, but not yours. It wants the password of the account you're switching into, root.

su -

On a lot of Ubuntu cloud images this won't work, because the root account ships password-locked with no usable password to authenticate against - that's not a universal guarantee, a given provider or admin could have changed it, but it's the typical state for a stock cloud image. On WeaselCloud, it works, as long as you type the root password shown in the panel on your server's page: the prompt switches to root@host:~# and you're in. So don't confuse "su - doesn't work" (typical elsewhere) with "su - works but wants a password I don't recognize" - you're in the second case, and the fix is just pulling the password from the panel, not resetting anything.

Worth keeping that password handy but not typing it constantly: sudo -i or sudo su - from your own user (once you've set one up, see below) solve the same problem with your own password instead of root's - one less secret that can leak.

ssh root@server - works immediately, think twice anyway

On WeaselCloud, connecting straight in as root over SSH just works - it's literally what the panel shows as the primary way to connect: login root, password right next to it.

ssh [email protected]

Enter the password from the panel and you're in a root session immediately, no intermediate user involved. On many other providers the same command answers Permission denied (publickey) instead, because password login for root is disabled there and SSH only offers key auth - but that message on its own just means the authentication methods available on this connection didn't succeed. The cause could be root being disallowed, the right key missing from authorized_keys, the wrong key, bad file permissions, a different AuthorizedKeysFile, a Match block, and so on - the actual reason only shows up in the effective sshd config and the logs. WeaselCloud has no such block, which makes this both the fastest way onto the server and the widest one: if the root password leaks to anyone else, they get everything, with no additional barrier in the way. The rest of this article covers how to tighten that up once the server is doing more than a quick test.

Making login safer once a server sticks around

For a test that lasts a couple of hours, WeaselCloud's default - root login and password right in the panel - is fine as-is. For a server that's going to sit online for weeks or months, it's worth narrowing that down. root is a username every Linux server on the planet has, which puts it first in line for every automated password-guessing attempt out there - bots knock on root@your_ip around the clock, not just when you happen to be thinking about it.

Two independent steps, do either one or both. First, set up a separate sudo user instead of living in a root shell full-time - the same setup that's standard on most other providers by default:

sudo adduser deploy
sudo usermod -aG sudo deploy

Now you log in as deploy and reach for sudo -i when you actually need root. That doesn't make a stray rm -rf itself any less dangerous - if you're already inside a root session via sudo -i, it runs immediately, exactly as it would if you'd logged in as root directly. The real payoff of a separate sudo user is different: everyday work happens without UID 0, and escalating to root is a deliberate step you take only where you actually need it - that cuts the odds of running an ordinary command with root privileges purely because you happened to already be root. And running sudo does leave a clearer log trail of individual privilege escalations than a long-lived session does - open a root shell with sudo -i, and the commands you type inside it afterward don't become separate sudo log entries on their own; a real audit trail of what ran inside that session needs something extra, like sudo I/O logging or auditd.

Second, take password-based root login out of SSH entirely and leave only key auth, or turn off direct root SSH access altogether. Don't edit the main /etc/ssh/sshd_config directly: Ubuntu includes every file under /etc/ssh/sshd_config.d/*.conf right at the top of it, and for most directives OpenSSH keeps the first value it encounters. If some earlier drop-in already sets PermitRootLogin - shipped with the image, or left over from an earlier setup - that's the one that actually wins, not your edit further down in the main file, and you'd walk away thinking root is locked down when it isn't. The right move is your own drop-in with a name that sorts early:

sudo nano /etc/ssh/sshd_config.d/00-hardening.conf

PermitRootLogin prohibit-password

That value lets root in only with a key, zero password guesses possible over SSH. If you don't need root over SSH at all - your deploy user already has sudo -i - set PermitRootLogin no instead. The 00- prefix sorts before the other drop-ins, which is exactly what makes it the "first value encountered." Before restarting anything, check the syntax and confirm what value actually won in the effective config:

sudo sshd -t
sudo sshd -T | grep -i permitrootlogin

Once sshd -t passes clean and sshd -T shows the value you set, apply it with a config reload, not a full restart:

sudo systemctl reload ssh

• on Ubuntu the systemd unit is named ssh, not sshd like on some other distributions - that's correct, not a typo;
• reload is the right call here for the same reason it is with nginx - the config gets re-read without dropping connections that are already open;
• keep your current SSH session open until a new connection under the deploy user actually works. A config typo can lock you out of the server entirely otherwise.

Permission denied vs command not found - two unrelated problems

These two get confused constantly, even though their causes have nothing to do with each other.

If you mistype a command name - sudp instead of sudo, say - the shell responds with bash: sudp: command not found. That's it: no program exists under that name. Permissions never entered into it.

If your user simply isn't in the sudo group, trying to run anything with sudo produces a completely different message: ubuntu is not in the sudoers file. This incident will be reported. That's a permissions problem, and you genuinely lack access - you can't add yourself to the sudo group from inside this account, you need someone who already has root access to do it.

And if the password itself is simply wrong, whether for sudo, su -, or an SSH login using password auth, the response looks like Sorry, try again. or su: Authentication failure. The command exists, access is allowed in principle, the credentials you supplied just didn't match, or, in the su - without a root password case, couldn't have matched anything to begin with.

How do I log in as root on Ubuntu?

On WeaselCloud, directly - login root and the password shown in the panel, via ssh root@your_ip or su -. On most other providers there's no direct path: you log in as a regular user and use sudo -i or sudo su -, because root starts out with no password and no SSH access allowed.

What's the actual difference between sudo su - and sudo -i?

In terms of where you end up on a typical Ubuntu box, barely any: both open an interactive root session with /root as home. The mechanism differs - sudo -i builds the login environment itself by sudo's rules, sudo su - does the same in two steps through an extra su -, which can make PATH and what lands in audit logs differ slightly. sudo -i is simpler and more predictable; there's no real reason to switch to sudo su - on purpose.

Why does su - want a password I never set?

su - asks for root's password, not yours. On WeaselCloud that password already exists and is shown right in the panel on the server's page - enter that one, not your SSH login password. On most other providers root has no password at all by default, the account is locked, and there su - answers Authentication failure no matter what you enter - normal behavior for that environment, just not for WeaselCloud.

How do I enable root login over SSH on Ubuntu?

On WeaselCloud it's already on - login root and the password are shown in the panel. To set it up by hand on another server or image, prefer key-only root over password root: create /etc/ssh/sshd_config.d/00-hardening.conf with PermitRootLogin prohibit-password. PermitRootLogin yes with password authentication enabled also opens password-based root login, which for a regular internet-facing VPS is almost never something you actually want - it just widens the attack surface. After the edit, always run sudo sshd -t, then sudo sshd -T | grep -i permitrootlogin to confirm the effective value, then sudo systemctl reload ssh. Test the new connection in a separate session before closing your current one.

What does Permission denied mean when I try ssh root@server?

On WeaselCloud it usually means the password was wrong, or someone already tightened the server's security settings (say, set PermitRootLogin no). On other providers, the same message often means password login for root is disabled and the server only offers key auth - but the message itself only tells you the authentication methods available on this connection didn't succeed. Check the effective config (sudo sshd -T | grep -i permitrootlogin) and the logs rather than guessing from one line.

Takeaways

• Root is the superuser: UID 0, with the widest administrative rights an ordinary system grants - not a separate system mode.
• On WeaselCloud, root SSH login is on from day one - login and password are shown in the panel; on many other providers root is locked by default.
• sudo command runs only the command you gave it with elevated rights; sudo typically prompts on the first command in a session, then reuses cached authorization for about 15 minutes - that's expected, not a hole.
• sudo -i and sudo su - land you in a similar place on a typical Ubuntu box - a root session with /root as home - but the mechanism differs (sudo -i directly, sudo su - through an extra su -); there's no real reason to switch to sudo su - on purpose.
• su - without sudo asks for root's own password - on WeaselCloud it exists and works, on many Ubuntu cloud images root is password-locked and there's no password to enter at all.
• The real value of a separate sudo user isn't a pause before rm -rf (there isn't one if you're already in a root session) - it's that everyday work happens without UID 0, and escalation to root is a deliberate step.
• For a server staying in production long-term, set up a separate sudo user and narrow root's SSH access through your own drop-in at /etc/ssh/sshd_config.d/00-hardening.conf - to a key (PermitRootLogin prohibit-password) or off entirely (no), checked with sshd -t / sshd -T before reloading.

What's next

If you also need to change your own password, another user's password, or root's password, the guide to changing passwords on Ubuntu covers all three cases separately. To set up SSH access to a server from macOS or Linux from scratch, there's a dedicated knowledge base article on connecting over SSH from macOS and Linux. If your actual problem is a missing command rather than root access, see the breakdown of command not found on Ubuntu. And for a broader list of common issues on a fresh Linux server, there's the common Linux server problems hub.