A fresh Ubuntu 26.04 server ships with root SSH access, no regular user, and no firewall rules. That works for the first login, but it is not a safe state to leave running on a public VPS.

This guide walks through the first tasks to perform on a new Ubuntu 26.04 server: creating a sudo user, enabling SSH key authentication, locking down SSH, configuring UFW, setting the hostname and timezone, and applying package updates.

Quick Reference #

Prerequisites #

Before starting, make sure you have:

• A new Ubuntu 26.04 server with a public IP address.
• Root access over SSH, either with a password or a provider-supplied key.
• A local SSH key pair on your workstation. If you do not have one yet, see how to generate SSH keys on Linux .
• Access to the provider web console as a backup path in case SSH access stops working.

Keep your original root SSH session open until you have tested the new user login and the hardened SSH configuration.

Log In as Root #

Open a terminal on your local machine and connect to the server using the public IP address from your hosting provider:

ssh root@server_ip_address

Accept the host key when prompted and enter the root password if password authentication is still enabled. If your provider created the server with an SSH key, the connection should use that key automatically.

Create a New Sudo User #

Working as root for daily administration is risky because every command runs with full privileges. Create a regular user account and give it administrative access through the sudo group.

Replace username with the account name you want to use:

adduser username

The command prompts for a password and optional user details. Enter a strong password, then press Enter to skip any fields you do not need.

Add the new user to the sudo group:

usermod -aG sudo username

The account can now run administrative commands with sudo.

Set Up SSH Key Authentication #

SSH keys are safer than password logins and are easier to use once configured. The exact command depends on where your public key is currently stored.

If your public key is already present under the root account, copy the root SSH directory to the new user:

rsync --archive --chown=username:username /root/.ssh /home/username

If you need to copy a key from your local workstation, run this command from the local machine:

ssh-copy-id username@server_ip_address

Open a new terminal window and test the login before changing the SSH server configuration:

ssh username@server_ip_address

The connection should succeed as the new user. Keep both the root session and the new user session open while you continue.

Disable Root Login and Password Authentication #

After key-based login works, configure OpenSSH to reject direct root logins and password authentication. Ubuntu includes files from /etc/ssh/sshd_config.d/, which keeps local changes separate from the main SSH configuration file.

Create a hardening snippet:

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

Add the following lines:

PermitRootLogin no
PasswordAuthentication no

Save the file and test the SSH configuration syntax:

sudo sshd -t

If the command prints no output, the configuration is valid. Reload SSH to apply the change:

sudo systemctl reload ssh

Open another terminal and confirm that you can still log in as the regular user:

ssh username@server_ip_address

Do not close your existing sessions until this test succeeds.

Set Up the Firewall with UFW #

Ubuntu uses UFW (Uncomplicated Firewall) as a simple front-end for managing host firewall rules. Start by allowing SSH so the firewall does not block your current access:

sudo ufw allow OpenSSH

Enable the firewall:

sudo ufw enable

Confirm the prompt with y, then check the active rules:

sudo ufw status

The output should show that OpenSSH is allowed:

Status: active
To Action From
-- ------ ----
OpenSSH ALLOW Anywhere
OpenSSH (v6) ALLOW Anywhere (v6)

When you install services such as Nginx or Apache, open their profiles before expecting traffic to reach them. For example, an Nginx server that should accept HTTP and HTTPS traffic needs:

sudo ufw allow 'Nginx Full'

For more examples, see how to set up a firewall with UFW .

Set the Hostname #

A descriptive hostname makes logs, shell prompts, monitoring alerts, and dashboards easier to read. Set the hostname with hostnamectl:

sudo hostnamectl set-hostname server-name

Replace server-name with a short name that matches the server role, such as web-01 or db-01.

Check the result:

hostnamectl

You can update DNS records or your local SSH config separately if you want to connect by name instead of IP address.

Set the Timezone #

Set the server timezone so logs, cron jobs, and timestamps match the region you use for operations:

sudo timedatectl set-timezone Europe/Berlin

List available zones if you are unsure of the exact name:

timedatectl list-timezones

See how to set or change the timezone on Ubuntu for a deeper explanation.

Update the System #

Refresh the package index and install pending updates:

sudo apt update
sudo apt upgrade

If the upgrade installed a new kernel or core system libraries, reboot the server:

sudo reboot

After the reboot, reconnect as the regular sudo user:

ssh username@server_ip_address

Troubleshooting #

Locked out after disabling password authentication
Use your provider web console or recovery mode to log in. Edit /etc/ssh/sshd_config.d/99-hardening.conf, temporarily set PasswordAuthentication yes, run sudo sshd -t, reload SSH, and test key login again before disabling passwords.

usermod: group 'sudo' does not exist
Some minimal images may not include the sudo package. Install it with apt install sudo, then rerun usermod -aG sudo username.

sshd -t reports an error
Read the line number in the error message, fix the snippet in /etc/ssh/sshd_config.d/99-hardening.conf, and run sudo sshd -t again. Do not reload SSH until the syntax test passes.

UFW blocks an expected service
Check the active rules with sudo ufw status. Allow the needed service profile or port, such as sudo ufw allow 'Nginx Full' for Nginx web traffic, then test the connection again.

Conclusion #

You now have an Ubuntu 26.04 server with a sudo user, key-based SSH access, direct root logins disabled, a basic firewall, and current packages. A good next step is to enable automatic security updates before installing the rest of your stack.

The “Permission denied (publickey)” error occurs when the SSH server rejects your connection because it cannot verify your identity using public key authentication.

user@remote_host: Permission denied (publickey).

This is one of the most common SSH errors. In this guide, we will go through the most frequent causes and how to fix them.

Debugging the Connection #

Before trying specific fixes, run SSH in verbose mode to see exactly where the authentication fails:

ssh -v user@remote_host

For even more detail, use -vv or -vvv:

ssh -vvv user@remote_host

Look for lines like:

debug1: Offering public key: /home/user/.ssh/id_ed25519
debug1: Server accepts key: /home/user/.ssh/id_ed25519

or:

debug1: Trying private key: /home/user/.ssh/id_ed25519
debug1: No more authentication methods to try.

The verbose output tells you which keys are being tried and where the process fails.

Common Causes and Fixes #

1. Public Key Not on the Remote Server #

The most common cause is that your public key is not in the remote server’s ~/.ssh/authorized_keys file.

Copy your public key to the server:

ssh-copy-id user@remote_host

If ssh-copy-id is not available, copy it manually:

cat ~/.ssh/id_ed25519.pub | ssh user@remote_host "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

For more details, see our guide on how to copy SSH keys with ssh-copy-id .

2. Wrong File Permissions #

SSH is strict about file permissions. If the permissions are too open, the SSH server will reject the key.

On the remote server, set the correct permissions:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

On the local machine, set the correct permissions on your private key:

chmod 600 ~/.ssh/id_ed25519

The SSH server will also reject keys if the home directory is writable by others:

chmod 755 ~

These checks are enforced by the StrictModes yes setting in /etc/ssh/sshd_config, which is enabled by default. Do not disable it — fix the permissions instead.

3. Wrong User or Hostname #

Make sure you are connecting as the correct user. The key must be in that user’s authorized_keys file:

ssh deploy@remote_host

If you have a host alias in your SSH config file , verify it points to the correct hostname and user.

4. SSH Agent Not Running #

If your key is protected with a passphrase and the SSH agent is not running, the key will not be offered to the server.

Start the SSH agent and add your key:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

To list the keys currently loaded in the agent:

ssh-add -l

5. Wrong Key Being Used #

If you have multiple SSH keys, the client may be offering the wrong one. Specify the key explicitly:

ssh -i ~/.ssh/id_ed25519 user@remote_host

Or configure it in your ~/.ssh/config:

Host remote_host
 HostName 192.168.1.10
 User deploy
 IdentityFile ~/.ssh/id_ed25519

6. Public Key Authentication Disabled on the Server #

If public key authentication is disabled on the server, key-based login will not work regardless of your key setup. Check /etc/ssh/sshd_config on the server:

PasswordAuthentication no
PubkeyAuthentication yes

If PubkeyAuthentication is set to no, key-based login will not work. Change it to yes and restart SSH:

sudo systemctl restart sshd

7. Key Type Not Accepted #

Some servers are configured to accept only certain key types. If your key type is not allowed, the server will reject it.

Check the PubkeyAcceptedAlgorithms setting in /etc/ssh/sshd_config:

PubkeyAcceptedAlgorithms +ssh-rsa

If you are using an older RSA key, the server may require you to explicitly allow it. This should be a last resort because ssh-rsa is deprecated on modern OpenSSH. A better solution is to generate a new Ed25519 key:

ssh-keygen -t ed25519

8. SELinux Blocking Access #

On systems with SELinux enabled (RHEL, CentOS, Fedora), SELinux may prevent the SSH server from reading the authorized_keys file.

Check for SELinux denials:

sudo ausearch -m avc -ts recent

Restore the correct SELinux context:

sudo restorecon -R ~/.ssh

9. Home Directory on Network Storage #

If the user’s home directory is on NFS or another network filesystem, the SSH server may not be able to read the authorized_keys file before the filesystem is mounted.

You can configure an alternative location for authorized keys in /etc/ssh/sshd_config:

AuthorizedKeysFile /etc/ssh/authorized_keys/%u

Then place the user’s keys in /etc/ssh/authorized_keys/username.

Troubleshooting #

Server-Side Debugging #

If you have access to the server, check the authentication log for error details:

On Ubuntu and Debian:

sudo tail -f /var/log/auth.log

On CentOS, RHEL, and Fedora:

sudo tail -f /var/log/secure

You can also run the SSH server in debug mode temporarily on a different port:

sudo /usr/sbin/sshd -d -p 2222

Then connect to it from the client:

ssh -p 2222 user@remote_host

The server will print detailed authentication information to the terminal.

Quick Reference #

FAQ #

Why does SSH care about file permissions?
SSH refuses to use keys with overly permissive file permissions because other users on the system could read your private key or modify your authorized_keys file. This is a security feature, not a bug.

I copied my key but it still doesn’t work. What should I check?
Check the permissions on the remote ~/.ssh directory (700), the authorized_keys file (600), and the home directory (755 or stricter). Also verify you are connecting as the correct user.

How do I check which keys the SSH client is trying?
Run ssh -v user@host and look for lines starting with debug1: Offering public key or debug1: Trying private key. This shows which keys are being offered to the server.

Does this error always mean a key problem?
Not always. If the server has PasswordAuthentication no and PubkeyAuthentication no, all authentication methods are disabled and you will see this error regardless.

Can I temporarily enable password login to fix the key?
Yes. If you have console access, set PasswordAuthentication yes in /etc/ssh/sshd_config, restart SSH, copy your key with ssh-copy-id, then disable password authentication again.

I get this error on an AWS, GCP, or Azure instance. What should I check?
Cloud instances use a specific key pair set during provisioning. Make sure you are using that key: ssh -i ~/.ssh/my-cloud-key.pem user@host. The default username also varies by provider (e.g., ec2-user on Amazon Linux, ubuntu on Ubuntu instances, azureuser on Azure). Check your provider’s documentation for the correct username.

Conclusion #

The “Permission denied (publickey)” error is almost always caused by a missing key, wrong file permissions, or the SSH client offering the wrong key. Start by running ssh -v to identify the problem, then work through the fixes above.

If you have any questions, feel free to leave a comment below.