Ubuntu 22.04 Server / Log in as root locally and over SSH

On Ubuntu 22.04 Server, the usual way to work with root privileges is to sign in with a regular account and run sudo -i. Direct root login requires separate checks of the password and login policy; SSH also depends on PermitRootLogin and the enabled authentication methods.

Root privileges versus direct root login

Root is the account that administers the entire system. Ubuntu locks the root password by default and lets authorized regular users run sudo with their own credentials. The root account still exists. See the Ubuntu user-management documentation for this design.

If you only need an administrative shell, use the commands below. Authentication normally uses your regular account’s password, subject to sudo policy. Check that whoami prints root, then use exit when finished to return to your regular account. This does not enable the root password or change SSH policy.

sudo -i
whoami
exit

Set a root password separately only if you need password-based console login or switching with su -. The first sudo prompt is for your regular account; the next two entries set the new root password. Password characters are not displayed while you type.

sudo passwd root
su -
whoami
exit

su - uses the root password you just set. Setting a password does not automatically permit every login method: PAM (Pluggable Authentication Modules) and console or remote-access policies may impose restrictions. The Ubuntu 22.04 sudo manual explains sudo -i.

Check access and existing SSH policy first

The following procedure covers OpenSSH on an Ubuntu 22.04 server you administer. Keep your existing regular-account SSH session open and prepare a physical or cloud recovery console. For production, first consider SSH through a regular account followed by sudo. If direct root access is necessary, decide on public-key authentication and the permitted management network as well.

If the SSH server is missing, run sudo apt update followed by sudo apt install openssh-server. Check it with sudo systemctl status ssh.service. You need the server address and actual SSH port; firewall and cloud security rules must allow the intended management connection.

Back up the configuration and locate relevant directives before changing them. If a backup name already exists, choose another to avoid overwriting it. Keep backups outside directories loaded through *.conf, as shown below.

sudo cp -a /etc/ssh/sshd_config /etc/ssh/sshd_config.before-root-login
sudo cp -a /etc/ssh/sshd_config.d /etc/ssh/sshd_config.d.before-root-login
sudo grep -RnsE '^[[:space:]]*(Include|Match|PermitRootLogin|PasswordAuthentication|PubkeyAuthentication|AuthenticationMethods|AllowUsers|DenyUsers|AllowGroups|DenyGroups)' /etc/ssh/sshd_config /etc/ssh/sshd_config.d

The server file is sshd_config, distinct from the client’s ssh_config. Ubuntu 22.04 normally loads /etc/ssh/sshd_config.d/*.conf first. Most directives use the first obtained value, so appending a setting to the main file may not override an earlier one. Inspect Include order, Match conditions and cloud-generated settings, then verify the effective values.

In the Ubuntu 22.04 sshd_config manual, PermitRootLogin yes permits root when other authentication requirements are met. prohibit-password disables password and keyboard-interactive authentication for root while potentially allowing public keys. no prohibits root SSH login. A commented default line alone does not establish the server’s effective policy.

Configure root SSH login with a password

This method exposes root password authentication, so select it only where the management requirements justify it. Set a password with sudo passwd root, then edit the effective server configuration using sudoedit /etc/ssh/sshd_config or the relevant snippet. The following is an example policy, not an instruction to append these lines blindly.

PermitRootLogin yes
PasswordAuthentication yes

PermitRootLogin yes alone is insufficient. Password authentication must be enabled, and AuthenticationMethods, user or group restrictions, PAM and account status must also permit access. A global PasswordAuthentication yes can affect other users; check whether it broadens the existing policy. Do not disable the firewall or remove multifactor requirements to follow this guide.

Saving a file does not complete activation. Follow the validation and reload procedure below before testing from the client. Replace the example 192.0.2.20 with the real server address. For a port other than the default 22, add ssh -p PORT with the actual number.

ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password root@192.0.2.20

This test selects password authentication instead of public keys. A password alone will not work if the server requires additional authentication. Verify the host-key fingerprint through a trusted server-management channel; do not disable verification to bypass a changed-key warning.

Use a public key for root SSH login

With public-key authentication, the client keeps the private key and only the corresponding public key is registered on the server. Enabling root password login is not a prerequisite. You can install the key through an existing administrator session or console, without first enabling root password SSH access.

If the client has no suitable key, generate one with ssh-keygen -t ed25519. Choose a new filename rather than overwrite an existing key, and protect the private key with a passphrase. Register the single line from the public-key file ~/.ssh/id_ed25519.pub. Never copy the private key without the .pub suffix to the server.

In the existing administrator session on the server, prepare the directory and file permissions as below, then append the client’s public-key line in the editor. Preserve existing keys and do not add duplicates. If you chose another key filename, use its corresponding public key.

sudo install -d -m 700 -o root -g root /root/.ssh
sudo touch /root/.ssh/authorized_keys
sudo chown root:root /root/.ssh/authorized_keys
sudo chmod 600 /root/.ssh/authorized_keys
sudoedit /root/.ssh/authorized_keys

This example uses the default authorized-key path. Check the actual path if AuthorizedKeysFile specifies something different. Choose the following policy to disallow root password authentication, resolve conflicting earlier settings, then validate.

PermitRootLogin prohibit-password
PubkeyAuthentication yes

After validating and applying the server settings, connect from the client as follows. If asked for the private-key passphrase, enter the client key’s passphrase, not the root account password. Public-key access must still satisfy PAM, account and access policies.

ssh -i ~/.ssh/id_ed25519 -o IdentitiesOnly=yes root@192.0.2.20

Validate settings and test a new session

1. First check syntax and host-key sanity on the server. A successful -t check normally prints nothing. If it reports errors, fix the indicated file and line before reloading. -T prints effective configuration; with -C, it evaluates Match rules for the specified connection.

sudo /usr/sbin/sshd -t
sudo /usr/sbin/sshd -T -C user=root,addr=192.0.2.10,host=admin.example | grep -E '^(permitrootlogin|passwordauthentication|pubkeyauthentication|authenticationmethods|authorizedkeysfile|allowusers|denyusers|allowgroups|denygroups) '

Replace 192.0.2.10 with the administrator client address as seen by the server and admin.example with the client hostname to evaluate. If you use Match LocalAddress or LocalPort, also supply laddr and lport in -C. Unexpected output calls for investigating precedence and conditions first. The Ubuntu 22.04 sshd manual explains these options.

2. Once syntax checks pass and effective values match the intended policy, reload the service. Keep the existing management session open and use another client window to test the password or key method above.

sudo systemctl reload ssh.service
sudo systemctl is-active ssh.service

3. An active service does not guarantee successful new authentication. In the new root session, check that whoami prints root and id -u prints 0. Also test a fresh regular-account login and sudo. User, key, network and account conditions can still deny access.

Diagnose failures and reverse direct root access

For Permission denied, investigate authentication, account and access policy. For timeouts or refused connections, investigate address, port, service and firewall separately. Inspect recent server events with sudo journalctl -u ssh.service -n 50 --no-pager and client authentication with ssh -v root@192.0.2.20. Redact sensitive details such as addresses and usernames before sharing logs.

To block root SSH again, set the effective PermitRootLogin to no, check sshd -t and connection-specific sshd -T, then run sudo systemctl reload ssh.service. Restore any temporarily changed password policy too. Revert only the files and entries you changed, rather than blindly overwriting the entire snippet directory.

After confirming SSH and sudo work through a separate regular account, lock the root password if you enabled it for this task and no longer need it. As the passwd manual explains, -l locks the password; it does not block every access method, including public keys. Verify the separate SSH prohibition with PermitRootLogin no.

sudo passwd -l root

Locking a password or changing SSH settings does not automatically end existing root sessions. Finish the required work and close root shells you opened with exit. If recovery is needed, use the still-open regular-account session or recovery console to restore settings from the backups and change record.