DEV Community

Big Mazzy
Big Mazzy

Posted on

Fix SSH Connection Refused on Ubuntu 24.04: Start SSH

#linux #ubuntu #tutorial #devops

TL;DR: From the VM console, install OpenSSH Server and enable its socket so SSH can listen on port 22.

The problem

A client may report “Connection refused” when you try to SSH into an Ubuntu 24.04 server. In this lab, the connection to 203.0.113.10 on port 22 is refused, and the hostname does not come back. The key clue is that the service is not accepting connections on the server.

ssh: connect to host 203.0.113.10 port 22: Connection refused
Enter fullscreen mode Exit fullscreen mode

The recovery needs to happen from the virtual machine’s console. If SSH is unavailable, an SSH session cannot be used to restore the service. Open the VM console through your hosting or virtualization environment, then run the server-side steps there.

Why it happens

For this lab, the cause is a stopped SSH listener. Ubuntu’s SSH setup can use socket activation: the SSH socket listens for incoming connections and starts the SSH service when a connection arrives. If that socket and the service are stopped, nothing is listening on the default SSH port, 22.

The port check in this reproduction shows only its column headers, with no listening entry beneath them:

State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
Enter fullscreen mode Exit fullscreen mode

That absence is the useful signal. The fix is to install the OpenSSH server package, then enable and start the SSH socket. Enabling it makes the socket start at boot; starting it now restores listening immediately. Leave firewall rules unchanged for this scenario: the problem is the stopped listener. Enabling SSH makes it available to networks allowed by the existing rules, potentially including the public internet.

Step-by-step fix

  1. From the client, try the connection and hostname lookup to confirm the symptom. SERVER is an example address; replace it with the server’s IP when using your own machine. The account name user is also an example. 
SERVER=203.0.113.10
ssh user@$SERVER hostname
Enter fullscreen mode Exit fullscreen mode

A refused connection means the client reached the address, but no process accepted the connection on port 22. Continue from the VM console rather than relying on SSH for recovery.

  1. On the VM console, stop both the socket and service to reproduce the lab’s starting condition. This step is for reproducing the issue; if you have already confirmed that the listener is stopped, proceed to the port check and repair. 
sudo systemctl stop ssh.socket ssh.service
Enter fullscreen mode Exit fullscreen mode
  1. Check whether anything is listening on port 22. 
sudo ss -ltnp sport = :22
Enter fullscreen mode Exit fullscreen mode

In this lab, the sample result contains only the column headers. That indicates there is no listening entry for port 22.

  1. Install OpenSSH Server and enable and start the SSH socket. Run the two lines together as shown. 
sudo apt-get install -y openssh-server && \
sudo systemctl enable --now ssh.socket
Enter fullscreen mode Exit fullscreen mode

The package provides the SSH server. Enabling and starting the socket restores the listener now and configures it to start at boot. With socket activation, incoming connections can start the SSH service.

How to verify

  1. On the VM, check for a listener on port 22 and print a confirmation if one is present. 
sudo ss -H -ltn 'sport = :22' | \
grep -q '^LISTEN' && echo 'LISTEN on port 22'
Enter fullscreen mode Exit fullscreen mode

Expected output:

LISTEN on port 22
Enter fullscreen mode Exit fullscreen mode
  1. Return to the client and reconnect, then request the server’s hostname. 
SERVER=203.0.113.10
ssh user@$SERVER hostname
Enter fullscreen mode Exit fullscreen mode

Expected output:

lab-01
Enter fullscreen mode Exit fullscreen mode

The address, account, hostname, and any IP, PID, or session numbers shown in examples are placeholders. Use the actual server address and account for your environment; lab-01 is the sample hostname returned by this lab. A successful hostname response confirms that SSH accepted the connection and ran the request.

Common mistakes

  • Running the repair on the client instead of on the VM. When SSH itself is unavailable, use the VM console to restore the listener.
  • Checking the port but overlooking that only the headers appeared. In this lab, no listening row means nothing is accepting connections on port 22.
  • Changing firewall rules when the stated cause is a stopped listener. Keep the existing rules unchanged for this fix; the socket will be reachable by networks those rules already allow.
  • Expecting SSH to accept connections if the socket has not been enabled and started. The repair command does both.
  • Treating the example address or account as universal. Replace 203.0.113.10 and user with values for your server.
  • Forgetting that enabling SSH exposes it to networks permitted by your rules, which may include the public internet. Consider which networks those existing rules allow.

If you want a clean Ubuntu box to practice on, PowerVPS is a reasonable choice: https://powervps.net/?from=32

Watch more fixes on Server Lab: https://www.youtube.com/channel/UCov7rfWAnS4c2wF5E9V1Yag

Top comments (0)