Short answer: sudo apt install openssh-server installs the SSH service; on Ubuntu 22.10 and newer it starts and enables itself on install, so there is usually nothing left to run. If it is already installed but not answering, the fix is sudo systemctl enable --now ssh and, if a firewall is active, sudo ufw allow OpenSSH.
Ubuntu Server already has it; Ubuntu Desktop does not
Ubuntu Server’s installer offers to install OpenSSH server as a checkbox during setup, and almost everyone ticks it, which is why a fresh Ubuntu Server VPS already accepts SSH connections from the first boot with no extra step. Ubuntu Desktop never installs it, on the (reasonable) assumption that a desktop machine does not need to accept remote logins by default, so turning on SSH there is where this actually comes up.
- 1Install openssh-server
Ubuntu (any version) sudo apt update sudo apt install -y openssh-serverThis installs the
sshservice (its systemd unit name) and thesshddaemon itself. Confirm it is there at all:Ubuntu dpkg -l | grep openssh-server - 2Check it is running
Ubuntu systemctl status sshactive (running)means it already works; nothing further to do. If it saysinactive (dead)orcould not be found, continue to the next step. - 3Enable and start it
Ubuntu sudo systemctl enable --now sshenablemakes it start at every boot from now on;--nowalso starts it immediately, so you do not have to reboot to find out whether it worked. - 4Open the firewall, if one is active
Ubuntu with ufw sudo ufw status sudo ufw allow OpenSSHOpenSSHhere is an application profile name ufw ships with, not a literal package name to type — it resolves to TCP port 22. Ifufw statussaysinactive, there is nothing to open and this step does nothing, which is fine. - 5Connect
from another machine ssh yourusername@SERVER_IPKeep your current session (console, or whatever got you onto the machine in the first place) open until this succeeds, in case step 4 missed a rule somewhere else — a cloud provider’s separate network firewall or security group, which ufw knows nothing about.
ssh, sshd or ssh.socket: Ubuntu version matters
| Ubuntu version | Service name | Notes |
|---|---|---|
| 22.04 and earlier | ssh | sshd listens on the port itself, starts at boot via the service |
| 22.10 to 23.10 | ssh.service and ssh.socket | Transition period; both exist, service usually still does the listening |
| 24.04 and newer | ssh.socket | Socket-activated: systemd listens on the port and starts sshd on the first connection |
On 24.04 and newer, a port change or a configuration reload needs sudo systemctl daemon-reload && sudo systemctl restart ssh.socket rather than restarting ssh itself, or the old setting quietly keeps answering — the exact trap covered in changing the SSH port. For simply enabling the service for the first time, systemctl enable --now ssh still works on every version: systemd resolves the alias to whichever unit actually applies.
Confirming sshd is actually listening
sudo ss -tlnp | grep ssh
sudo sshd -T | grep -i ^portss shows what is really bound to a port right now, regardless of what systemctl status claims; sshd -T dumps the effective configuration sshd would use, which also catches a second, forgotten Port line in a drop-in file under /etc/ssh/sshd_config.d/ that reopens port 22 even after you meant to change it.
Password login is on by default — turn it off once key auth works
A fresh openssh-server install accepts password logins, which is fine for the first connection but not something to leave on for long on a server reachable from the whole internet. Set up a key first:
ssh-keygen -t ed25519 -C "you@example"
ssh-copy-id yourusername@SERVER_IPThen disable password logins on the server, in /etc/ssh/sshd_config or a drop-in file:
PasswordAuthentication nosudo sshd -t && sudo systemctl restart ssh # 24.04: restart ssh.socket insteadTest the key login in a new terminal before closing the one you are already connected through — the same rule as changing the port, for the same reason. The full hardening checklist beyond this one setting, including fail2ban and disabling root login, is in securing SSH access.
Installed and running, but connections still fail
| Symptom | Likely cause | See |
|---|---|---|
| Connection refused | Firewall between you and the server, or sshd bound to the wrong address | SSH: Connection refused |
| Connection timed out | Nothing answers at all — a network-level firewall or wrong IP | SSH connection timed out |
| Permission denied (publickey) | Key auth is on, but the key is not installed or not offered | Permission denied (publickey) |
| It works, but on another port | Something changed the port previously; check sshd -T | SSH port 22 |
A note on WSL and containers
Everything above is for a real Ubuntu server or VM. Inside WSL or a Docker container, systemctl may not work at all, since neither necessarily runs systemd as PID 1 — sudo service ssh start is the fallback there, and it is rarely worth running an SSH server inside a container in the first place, since the host already offers a way in.
Frequently asked
How do I enable SSH on Ubuntu?
sudo apt install -y openssh-server installs and, on Ubuntu 22.10 and newer, automatically starts and enables it. If it is already installed but not running, sudo systemctl enable --now ssh starts it and sets it to start at every future boot.
Does Ubuntu Server already have SSH enabled?
Usually yes — the Ubuntu Server installer offers to install OpenSSH server as a checkbox during setup, and most people select it, so a fresh server VPS already accepts SSH connections from the first boot. Ubuntu Desktop never installs it by default.
I enabled SSH but still cannot connect — why?
Check, in order: that the service is actually running (systemctl status ssh), that a local firewall allows it (sudo ufw allow OpenSSH), and that a network-level firewall or security group outside the server itself is not blocking port 22 before it ever reaches ufw.
On Ubuntu 24.04, what is ssh.socket and does it change how I enable SSH?
Since Ubuntu 22.10, and by default on 24.04, systemd itself listens on port 22 through ssh.socket and starts sshd only on the first connection. systemctl enable --now ssh still works to turn it on initially, since systemd resolves the alias; it matters afterward, when a configuration change needs systemctl restart ssh.socket rather than restarting ssh itself.