How to Enable SSH on Ubuntu

Ubuntu Server answers on port 22 from the moment it first boots. Ubuntu Desktop hasn’t got the SSH server installed at all, which is the difference that sends most people looking for this page.

We’ll install it, confirm it’s listening, and put the firewall rule in before it’s needed rather than after.

Before You Start

• A machine running Ubuntu 26.04, 24.04 or 22.04, with sudo access, that you can currently reach some other way (a console, a keyboard, or your provider’s web terminal)
• Its IP address on the network you’ll be connecting from
• A key to log in with, ideally. Creating an SSH key takes a minute and beats typing a password every time

Step 1: Install the OpenSSH Server

sudo apt update

sudo apt install -y openssh-server

On Ubuntu Desktop this is the step that does the work. On Ubuntu Server, and on any cloud image, openssh-server is already there and apt will say so rather than doing anything.

Ubuntu starts it and sets it to come back after a reboot as part of the install, so there’s no separate systemctl enable to run afterwards. That command is in most guides and it hasn’t been needed for years.

Step 2: Check It’s Listening

sudo ss -tlnp | grep -E ':22\b'

LISTEN 0 4096 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=1049,fd=3),("systemd",pid=1,fd=60))
LISTEN 0 4096    [::]:22    [::]:* users:(("sshd",pid=1049,fd=4),("systemd",pid=1,fd=61))

Two lines, one for IPv4 and one for IPv6. If nothing comes back at all, nothing is listening and there’s no point going near the firewall yet.

Step 3: See Which Unit Is Running It

systemctl list-unit-files ssh.service ssh.socket

UNIT FILE   STATE    PRESET
ssh.service disabled enabled
ssh.socket  enabled  enabled

That’s Ubuntu 24.04 and 26.04, where sshd is started on demand by ssh.socket and ssh.service sits disabled until a connection arrives. It looks broken and isn’t. On 22.04 the two are the other way round: ssh.service enabled, ssh.socket disabled.

This is worth knowing before you go looking for a fault that isn’t there. It also decides which unit you’d point a systemctl command at, so check here first rather than assuming.

Step 4: Add the Firewall Rule

sudo ufw app list

Available applications:
  OpenSSH

ufw comes with Ubuntu but starts out inactive, so on a fresh machine it isn’t blocking anything yet.

sudo ufw allow OpenSSH

Add this now even though the firewall is off. Turning ufw on over an SSH session with no SSH rule in place ends the session and your way back in at the same moment, and it’s a miserable way to learn the lesson.

Verify It Worked

Everything so far was the server’s opinion of itself. Run this one on your own machine instead, so it has to cross the network to get an answer:

timeout 5 bash -c 'exec 3<>/dev/tcp/yourserverip/22; head -1 <&3'

SSH-2.0-OpenSSH_9.6p1 Ubuntu-3ubuntu13.18

Bash can open a TCP connection by itself, so that asks port 22 for its version banner without needing an account, a key or an ssh client. Getting the string back means the daemon is running, the firewall is letting you through, and the address is right.

Then the real thing:

ssh yourusername@yourserverip

You should get a password prompt, or go straight in if your key is already on the box. The login itself needs a second machine, so it’s the one check the run behind the badge on this page can’t make for you.

Conclusion

You’ve got sshd listening, a firewall rule waiting for the day you switch ufw on, and a way to test the port that doesn’t need credentials. The sensible next move is to stop using passwords over it, which is the second half of adding a user and giving them sudo.

If SSH won’t come up on your machine after this, do drop me a line at [email protected] with the Ubuntu version and whether it’s a desktop or a server install, and I’ll get it retested.