Skip to content
Hosting Operations10 min read

How to Fix SSH Connection Refused Ubuntu: Practical Guide

Step-by-step guide to diagnose and resolve SSH connection refused errors on Ubuntu servers with safe troubleshooting methods and verification steps.

Written by Abdul AbrorTechnical Hosting Support Engineer
Terminal screen showing SSH connection troubleshooting commands on Ubuntu server
On this page

TL;DR — Key takeaways

  • SSH connection refused on Ubuntu typically means the SSH service is not running, the firewall is blocking port 22, or the service is listening on a different port than expected.
  • Verify SSH service status with systemctl status ssh and check if it's listening on the correct port using ss -tlnp | grep ssh before making configuration changes.
  • Always test SSH configuration with sshd -t before restarting the service to avoid locking yourself out of a remote server.
  • Enable and configure UFW firewall rules for SSH before activating the firewall to prevent immediate lockout on remote systems.
  • Keep an active SSH session open when troubleshooting remote servers to maintain access if configuration changes cause connectivity issues.

The 'connection refused' error when connecting to an Ubuntu server via SSH means the client successfully reached the server, but no service accepted the connection on the target port. This differs from timeout errors, which indicate network-level blocking or an unreachable host.

This guide walks through systematic diagnosis and resolution of SSH connection refused errors on Ubuntu systems, covering service state verification, firewall configuration, port conflicts, and safe recovery procedures. Each step includes verification commands to confirm the fix before moving forward.

Understanding SSH Connection Refused Errors

When SSH returns 'connection refused', the TCP handshake reached the target machine but found no service listening on the specified port. The most common cause is that the SSH daemon (sshd) is not running. Other causes include firewall rules blocking the connection, the service listening on a non-standard port, or port conflicts with other services.

Ubuntu uses OpenSSH Server as its SSH implementation, managed through systemd. The default configuration listens on port 22 for all network interfaces. The service must be both installed and actively running to accept connections.

  • Connection refused: service not running or wrong port
  • Connection timeout: firewall blocking or network unreachable
  • Permission denied: service running but authentication failed
  • Network unreachable: routing or interface configuration issue

Verify SSH Service Installation and Status

Start by confirming that OpenSSH Server is installed and checking its current state. If you have console access (physical, KVM, or cloud provider console), use it for initial diagnosis to avoid dependency on SSH itself.

Check if the SSH package is installed with dpkg -l | grep openssh-server. If not present, install it with sudo apt update && sudo apt install openssh-server. After installation, the service should start automatically.

Verify the service state with systemctl status ssh. Look for 'active (running)' in the output. If the service shows as 'inactive (dead)', 'failed', or 'masked', it will not accept connections. Use sudo systemctl start ssh to start it and sudo systemctl enable ssh to ensure it starts on boot.

  • systemctl status ssh: check if service is active and running
  • sudo systemctl start ssh: start the service if stopped
  • sudo systemctl enable ssh: configure automatic start on boot
  • journalctl -u ssh -n 50: view recent service logs for error details

Check SSH Port and Network Listening State

Confirm which port sshd is listening on and which network interfaces it's bound to. The default is port 22 on all interfaces (0.0.0.0 for IPv4, :: for IPv6), but custom configurations may differ.

Use ss -tlnp | grep ssh or netstat -tlnp | grep ssh to see active listening sockets. The output shows the port number and bound address. If you see 127.0.0.1:22, the service only accepts local connections. If nothing appears, the service is not listening at all.

Verify the configured port in /etc/ssh/sshd_config by checking the Port directive. If this line is commented out or absent, SSH uses port 22 by default. If a custom port is set, clients must specify it with ssh -p PORT user@host.

  • ss -tlnp | grep ssh: show SSH listening ports and addresses
  • grep '^Port' /etc/ssh/sshd_config: check configured SSH port
  • sudo lsof -i :22: verify what process is using port 22
  • If custom port is used, test with: ssh -p CUSTOM_PORT user@host

Configure and Verify Firewall Rules

Ubuntu uses UFW (Uncomplicated Firewall) as a frontend for iptables. If UFW is active without an allow rule for SSH, incoming connections will be blocked. Before enabling UFW on a remote server, always configure the SSH allow rule first to prevent immediate lockout.

Check UFW status with sudo ufw status verbose. If it shows 'Status: active' but no rule for port 22 or your SSH port, add one with sudo ufw allow ssh (for port 22) or sudo ufw allow PORT/tcp for custom ports. Verify the rule appears in sudo ufw status numbered before relying on it.

If UFW is inactive but connections are still refused, check for active iptables rules with sudo iptables -L -n -v. Cloud providers may also enforce security groups or network ACLs outside the instance that require configuration through their control panel.

  • sudo ufw status verbose: check if firewall is active and view rules
  • sudo ufw allow ssh: allow SSH on default port 22
  • sudo ufw allow 2222/tcp: allow SSH on custom port 2222
  • sudo ufw enable: activate firewall after SSH rule is confirmed
  • For remote servers: keep existing SSH session open when testing firewall changes

Test and Reload SSH Configuration Safely

Configuration errors in /etc/ssh/sshd_config can prevent the SSH service from starting or cause it to bind to unexpected addresses. Always validate configuration syntax before restarting the service, especially on remote systems.

Run sudo sshd -t to test the configuration file for syntax errors. This command parses the config without starting the service. If errors are reported, correct them before proceeding. Common issues include typos in directive names, invalid values, or duplicate conflicting settings.

After confirming the configuration is valid, reload the service with sudo systemctl reload ssh (preserves existing connections) or sudo systemctl restart ssh (terminates active sessions). On remote servers, open a second SSH session to test connectivity before closing your original session. If the new session connects successfully, the changes are safe.

  • sudo sshd -t: validate SSH configuration syntax without restarting
  • sudo systemctl reload ssh: apply config changes without dropping connections
  • sudo systemctl restart ssh: full restart (will drop active sessions)
  • Test from a second terminal: ssh user@server before closing original session
  • Keep configuration backup: sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.backup

Diagnose Port Conflicts and Advanced Issues

If SSH is configured to listen on port 22 but another service is already using that port, sshd will fail to start. Use sudo lsof -i :22 to identify which process is bound to the port. If a different service is listed, either stop that service or reconfigure SSH to use an alternative port.

For network interface binding issues, check the ListenAddress directive in sshd_config. If set to a specific IP that no longer exists on the system, the service will fail to start. Comment out or update ListenAddress to 0.0.0.0 (all IPv4) or remove it to accept the default behavior.

Check system logs with journalctl -u ssh --since '10 minutes ago' for detailed error messages. Common advanced issues include SELinux or AppArmor policy blocks, insufficient system resources, corrupted SSH host keys, or permission issues on /var/run/sshd. Logs will indicate the specific failure reason.

  • sudo lsof -i :22: identify process using SSH port
  • journalctl -u ssh -f: follow live SSH service logs
  • sudo ss -tlnp: show all listening TCP services and their ports
  • Check host key permissions: ls -la /etc/ssh/ssh_host_* (should be root-owned, 600 for private keys)
  • For SELinux issues: check audit logs with sudo ausearch -m avc -ts recent

Recovery Procedures and Prevention

If you lose SSH access to a remote server after configuration changes, use the provider's console access (VNC, serial console, or cloud shell) to diagnose and restore service. Boot into recovery mode if necessary to edit sshd_config or restore a backup configuration.

Prevent future lockouts by keeping a backup SSH session active when testing changes on remote systems. Use screen or tmux to create persistent sessions that survive disconnections. Test configuration changes with sudo sshd -t before applying them.

Document your SSH configuration, especially custom ports, allowed users, and firewall rules. Store this documentation outside the server in case emergency access is needed. For production systems, configure a secondary access method such as a bastion host, VPN, or console access before making SSH configuration changes.

  • Always test with sshd -t before restarting SSH service remotely
  • Keep a backup of working sshd_config in version control or separate location
  • Use screen or tmux for persistent sessions during maintenance
  • Configure cloud provider console access before troubleshooting SSH
  • Set up monitoring alerts for SSH service status on critical systems
  • For sudo issues: ensure user is in sudo group with groups username

Quick troubleshooting checklist

  • Confirm OpenSSH Server is installed: dpkg -l | grep openssh-server
  • Verify SSH service is running: systemctl status ssh
  • Check which port SSH is listening on: ss -tlnp | grep ssh
  • Review SSH configuration for port and address settings: cat /etc/ssh/sshd_config
  • Validate configuration syntax: sudo sshd -t
  • Check UFW firewall status and rules: sudo ufw status verbose
  • Allow SSH through firewall before enabling: sudo ufw allow ssh
  • Test from second terminal before closing original SSH session
  • Review service logs for errors: journalctl -u ssh -n 50
  • Verify no port conflicts exist: sudo lsof -i :22
  • Ensure SSH service is enabled on boot: sudo systemctl is-enabled ssh
  • Document working configuration and custom port settings

FAQ

What does SSH connection refused mean on Ubuntu?

SSH connection refused on Ubuntu means the client reached the server but no SSH service was listening on the target port. This typically occurs because the SSH daemon is not running, the firewall is blocking the connection, or SSH is configured to listen on a different port than the client is trying to connect to.

How do I start SSH service on Ubuntu?

Start the SSH service on Ubuntu with the command sudo systemctl start ssh. To ensure it starts automatically on boot, run sudo systemctl enable ssh. Verify the service is running with systemctl status ssh, which should show 'active (running)' in the output.

How do I check if SSH is listening on Ubuntu?

Check if SSH is listening on Ubuntu with the command ss -tlnp | grep ssh or netstat -tlnp | grep ssh. The output shows which port SSH is bound to and which network addresses it accepts connections from. If nothing appears, the SSH service is not running or not listening on any port.

How do I allow SSH through UFW firewall?

Allow SSH through UFW with the command sudo ufw allow ssh for the default port 22, or sudo ufw allow PORT/tcp for a custom port. Before enabling UFW on a remote server, always add the SSH allow rule first with these commands, then enable the firewall with sudo ufw enable to prevent lockout.

How do I test SSH configuration without restarting the service?

Test SSH configuration syntax without restarting the service using the command sudo sshd -t. This validates the /etc/ssh/sshd_config file for errors without affecting running SSH connections. If the command returns no output, the configuration is valid. Any errors will be displayed with line numbers for correction.

Why does SSH connection refuse even though the service is running?

SSH may refuse connections even when running if the firewall blocks port 22, SSH is configured to listen only on localhost (127.0.0.1) instead of all interfaces, SSH is listening on a non-standard port that the client is not using, or another service has taken control of port 22. Use ss -tlnp | grep ssh to verify the listening address and port, and check firewall rules with sudo ufw status.

Related articles