↓Skip to main content
Alemasone

How to Securely Install and Configure SSH on Ubuntu

Learn how to install OpenSSH, generate Ed25519 keys, disable root login, and protect your Ubuntu server from brute-force attacks.

6 min read Updated on
Terminal showing an active SSH connection to an Ubuntu server
On this page
An SSH server reachable from the internet receives automated login attempts just minutes after being turned on. Two settings eliminate almost all the risk: key-only access and disabling root login. It takes five minutes, and these should be done before anything else.

SSH is the encrypted channel used to manage a Linux computer remotely: terminal access, file transfers, or tunnels for other services. On Ubuntu Desktop, the SSH server is not installed by default, whereas it usually is on server images. In this guide, you will install it, connect from your computer using a key, and secure it.

Installation #

sudo apt update
sudo apt install openssh-server

The service starts automatically. Check the status:

sudo systemctl status ssh

Ubuntu Terminal showing the output of systemctl status ssh with the service marked as active running
The line to check is the one with active (running)

On Ubuntu 24.04, don’t be alarmed if, before the first connection, the status shows inactive with the line TriggeredBy: ssh.socket: starting from Ubuntu 22.10, SSH is started by the socket upon the first connection attempt, and sudo systemctl status ssh.socket must show as active. To completely disable remote access, for example during maintenance, use sudo systemctl disable --now ssh.socket ssh.

If the UFW firewall is active, authorize SSH before closing the session you are currently working in:

sudo ufw allow OpenSSH
sudo ufw enable
Do not enable UFW before allowing OpenSSH. Your current connection will close and you will be locked out. On a remote server that you cannot physically access, this is the most expensive mistake you can make.

From another computer, connect using:

ssh nomeutente@indirizzo-ip

The command works the same way on Linux, macOS, and Windows 10 and 11, which have the SSH client pre-installed: just open Windows Terminal or PowerShell. Upon your first connection, you will be asked to confirm the server’s fingerprint: type yes.

Keys: how they work #

A key pair consists of a private part, which stays on your computer and must never be shared with anyone, and a public part, which you copy to the server. When you connect, the server verifies that you have the correct private key without anything secret being sent over the network.

It is more secure than a password because a key cannot be guessed: brute-force attacks, which try millions of combinations, are useless.

Generating the key pair #

On your computer, not on the server:

ssh-keygen -t ed25519 -C "il-mio-portatile"

Terminal with ssh-keygen -t ed25519: passphrase, path to the two files, and the key fingerprint
The command creates two files: the private key and the public key with a .pub extension

Ed25519 is the recommended algorithm today: short keys, fast verification, high security. Use RSA only if you need to connect to older systems that do not recognize Ed25519, and in that case, use at least 4096 bits.

When asked for a passphrase, enter one: it protects the key if someone gets their hands on your computer. To avoid typing it every time, the SSH agent handles it by remembering it until the end of your session.

Copying the public key to the server #

ssh-copy-id nomeutente@indirizzo-ip

It asks for your password only once and sets the correct permissions. On Windows ssh-copy-id there is no: open the file C:\Users\<nome>\.ssh\id_ed25519.pub, copy its content, and paste it at the bottom of the file ~/.ssh/authorized_keys on the server.

Immediately test the connection with the key from a second window while keeping the first one open. Only once it works should you proceed to disable password logins.

Securing the configuration #

The server settings are located in /etc/ssh/sshd_config. On recent versions of Ubuntu, it is better not to touch that file and instead create your own file inside /etc/ssh/sshd_config.d/, which will be read in addition:

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

Recommended content:

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
X11Forwarding no
MaxAuthTries 3

What each line does:

SettingEffect
PermitRootLogin noNo one can log in directly as root: you log in with your user and use sudo
PasswordAuthentication noAccess is only allowed via keys; passwords are rejected
KbdInteractiveAuthentication noCloses another path that would allow password access
MaxAuthTries 3Limits attempts per connection
X11Forwarding noDisables X11 forwarding, which almost no one uses

Before applying, check that the syntax is correct:

sudo sshd -t

If nothing is printed, everything is fine, and you can reload the service:

sudo systemctl reload ssh
Keep your current session open while applying changes, and test the new login from another window. If you made a mistake, you still have an active connection to fix it.

Defending against automated attacks #

Changing the port from 22 to a high number doesn’t make the server more secure, but it significantly reduces log noise because almost all automated scans only try the standard port. This is set with Port 2222 in your configuration file; remember to open the new port on your firewall (sudo ufw allow 2222/tcp). From Ubuntu 22.10 onwards, including 24.04, you also need sudo systemctl daemon-reload and sudo systemctl restart ssh.socket after making the change, otherwise the server will continue listening on port 22.

Fail2ban temporarily blocks addresses that fail multiple times in a row:

sudo apt install fail2ban

With the default configuration, it already protects SSH. You can see blocked addresses with sudo fail2ban-client status sshd.

Limiting which users can log in is simple and effective: with AllowUsers nomeutente in the configuration, no other accounts can connect, even with valid credentials.

The client configuration file #

On the computer you are connecting from, the ~/.ssh/config file saves you from having to remember addresses and ports:

Host server-casa
    HostName 192.168.1.50
    User alessandro
    Port 2222
    IdentityFile ~/.ssh/id_ed25519

From then on, all you need is ssh server-casa. The name also works with scp and rsync.

Transferring files via #

scp documento.pdf server-casa:/home/alessandro/

For entire folders or frequent copies, use rsync, which only transfers what has changed:

rsync -avz --progress cartella/ server-casa:/percorso/di/destinazione/

If you prefer a GUI-based program, FileZilla and WinSCP connect via SFTP using the same credentials and the same key.

FAQ #

If I disable passwords and lose my private key, will I be locked out? #

Yes, and that is a risk you must manage beforehand. Two precautions: add the public keys of all devices you will connect from to the server, and keep a copy of your private key in a safe place, such as in your password manager. If the server is a virtual machine with a provider, there is usually an emergency console available in the web panel.

Ed25519 or RSA? #

Use Ed25519 whenever possible: it’s more modern, the keys are shorter, and verification is faster. Use 4096-bit RSA only for older systems that do not support Ed25519.

Does changing the port actually help? #

It doesn’t increase security, because a targeted scan will find the service anyway. However, it significantly reduces automated attempts and makes your logs readable: when an attempt appears, you know it deserves attention.

How do I connect if my home IP address changes? #

Use a dynamic DNS service, which associates a fixed name with your address and updates it automatically whenever it changes. Many routers already support this in their settings. Alternatively, a VPN like Tailscale allows you to reach the server without opening any ports on your router.

What does the “host key changed” warning mean? #

It means the server’s identity no longer matches the one saved during the first connection. This can be normal if you have reinstalled the system or changed machines, but it could also be a sign of someone attempting to intercept your connection. Understand the reason before proceeding; only then should you remove the old entry using ssh-keygen -R indirizzo-ip.

Read next