How to fix ssh connection refused ubuntu: Troubleshooting Checklist
Step-by-step guide to diagnose and fix SSH connection refused errors on Ubuntu. Practical checklist for server admins and hosting support engineers.
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 or interface.
- Verify SSH service status with systemctl status ssh or systemctl status sshd, then check firewall rules using ufw status or iptables -L before testing network connectivity.
- Always backup your SSH configuration before making changes and test new configurations with sshd -t to prevent lockouts from your server.
- Connection refused differs from connection timeout: refused means the port is actively rejecting connections, while timeout suggests firewall blocking or network issues.
SSH connection refused errors on Ubuntu prevent remote access to your server, disrupting workflows and administration tasks. This error occurs when your SSH client successfully reaches the server but the connection is actively rejected, typically indicating service or configuration issues rather than network problems.
This guide provides a systematic troubleshooting approach for Ubuntu SSH connection refused errors, organized from the most common causes to edge cases. Each section includes diagnostic commands and concrete fixes that preserve your existing configuration where possible.
Understanding Connection Refused vs Other SSH Errors
Connection refused is a specific TCP error (ECONNREFUSED) that means your client reached the server, but nothing is listening on the target port. This differs from connection timeout, which suggests network filtering or firewall blocking, and permission denied, which indicates authentication problems.
When you see connection refused, the server's network stack is actively rejecting your connection attempt. This typically points to SSH service issues, incorrect port configuration, or the service listening on the wrong interface. Understanding this distinction helps you focus your troubleshooting on service and configuration layers rather than network connectivity.
- Connection refused: Service not running or not listening on the expected port/interface
- Connection timeout: Firewall blocking traffic or network routing issues
- Permission denied: Authentication failures (wrong credentials, keys, or SSH config)
- Network unreachable: Client-side network or DNS resolution problems
Check SSH Service Status
The first diagnostic step is verifying whether the SSH service is running. Ubuntu uses systemd to manage services, and the SSH daemon may be named either ssh or sshd depending on your Ubuntu version and installation method.
Run systemctl status ssh to check the service state. If the command returns 'Unit ssh.service could not be found', try systemctl status sshd instead. Look for 'active (running)' in green text. If the service is inactive, stopped, or failed, this is your primary issue.
- Check service status: systemctl status ssh or systemctl status sshd
- Start the service if stopped: sudo systemctl start ssh
- Enable automatic startup: sudo systemctl enable ssh
- View recent logs: sudo journalctl -u ssh -n 50
- Check for configuration errors: sudo sshd -t
Verify SSH is Listening on the Correct Port and Interface
Even if the SSH service shows as running, it may be listening on a non-standard port or bound to a specific interface that doesn't match your connection attempt. The default SSH port is 22, but administrators often change this for security reasons.
Use ss -tlnp | grep ssh or netstat -tlnp | grep ssh to see which ports and interfaces SSH is bound to. The output shows the local address and port. If you see 127.0.0.1:22, SSH is only accepting local connections. If you see 0.0.0.0:22 or :::22, it's listening on all interfaces, which is correct for remote access.
- Check listening ports: sudo ss -tlnp | grep ssh
- Alternative command: sudo netstat -tlnp | grep ssh
- Expected output for remote access: 0.0.0.0:22 or :::22 (IPv6)
- If bound to 127.0.0.1 only, edit /etc/ssh/sshd_config and check ListenAddress directive
- After configuration changes: sudo systemctl restart ssh
Review and Configure Firewall Rules
Ubuntu uses UFW (Uncomplicated Firewall) as a front-end for iptables. A misconfigured firewall is a common cause of SSH connection refused errors, especially after fresh installations or security hardening.
Check if UFW is active with sudo ufw status. If UFW is active but SSH is not listed in the allowed services, your firewall is blocking the connection. Before modifying firewall rules on a remote server, ensure you have alternative access (console, KVM, or recovery mode) to prevent complete lockout.
- Check UFW status: sudo ufw status verbose
- Allow SSH on default port: sudo ufw allow ssh or sudo ufw allow 22/tcp
- Allow SSH on custom port: sudo ufw allow 2222/tcp (replace with your port)
- Enable UFW if disabled: sudo ufw enable
- Check iptables rules directly: sudo iptables -L -n -v
- For VPS users: Verify cloud provider's security groups also allow SSH traffic
Inspect SSH Configuration File
Configuration errors in /etc/ssh/sshd_config can prevent SSH from starting or cause it to listen incorrectly. Common misconfigurations include wrong port numbers, restrictive ListenAddress settings, or syntax errors.
Before editing this file, create a backup: sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.backup. After making changes, always test the configuration with sudo sshd -t before restarting the service. This command validates syntax without affecting the running service.
- Backup configuration: sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.backup
- Edit configuration: sudo nano /etc/ssh/sshd_config
- Key directives to verify: Port (default 22), ListenAddress (use 0.0.0.0 or comment out for all interfaces), PermitRootLogin, PasswordAuthentication
- Test configuration: sudo sshd -t (no output means success)
- Apply changes: sudo systemctl restart ssh
- Restore from backup if needed: sudo cp /etc/ssh/sshd_config.backup /etc/ssh/sshd_config
Verify Network Connectivity and Port Accessibility
If the SSH service is running and firewall rules appear correct, test whether the port is actually accessible from your client location. Network-level filtering, cloud security groups, or ISP restrictions can block SSH traffic.
From another system or your local machine, use telnet or nc (netcat) to test basic TCP connectivity to the SSH port. If the connection succeeds, you'll see the SSH version banner. If it fails or times out, the issue is network-level rather than SSH-specific.
- Test from client: telnet your-server-ip 22 or nc -zv your-server-ip 22
- Successful test shows: SSH protocol version string (e.g., SSH-2.0-OpenSSH_8.9)
- If connection times out instead of refused: Check cloud provider security groups, network ACLs, or upstream firewall
- Test local connectivity from server: telnet localhost 22 (should succeed if SSH is running)
- For cloud VPS: Review provider's firewall/security group settings in control panel
Handle Edge Cases and Advanced Issues
Some SSH connection refused scenarios involve less common causes like resource exhaustion, failed service dependencies, or corrupted SSH keys. These typically appear after successful SSH operation, indicating a change in system state.
Check system logs for resource limits, disk space issues, or security violations. SSH may fail to start if /var is full, if too many authentication failures triggered fail2ban, or if SELinux or AppArmor policies block the service.
- Check disk space: df -h (SSH needs space in /var for logs and runtime files)
- Review system logs: sudo journalctl -xe | grep ssh
- Check for fail2ban blocks: sudo fail2ban-client status sshd
- Verify SSH host keys exist: ls -l /etc/ssh/ssh_host_*_key (regenerate if missing: sudo ssh-keygen -A)
- Check MaxStartups and MaxSessions in sshd_config if server is under load
- For AppArmor issues: sudo aa-status | grep ssh
Quick troubleshooting checklist
- Verify SSH service is running: systemctl status ssh or systemctl status sshd
- Check SSH is listening on correct port and interface: sudo ss -tlnp | grep ssh
- Confirm firewall allows SSH traffic: sudo ufw status or sudo iptables -L
- Test SSH configuration syntax: sudo sshd -t
- Verify network connectivity from client: telnet server-ip 22 or nc -zv server-ip 22
- Review SSH logs for specific errors: sudo journalctl -u ssh -n 50
- Check disk space availability: df -h
- Ensure SSH host keys exist: ls -l /etc/ssh/ssh_host_*_key
- Verify cloud security groups allow SSH (for VPS)
- Test from local server first: telnet localhost 22
FAQ
What does SSH connection refused mean on Ubuntu?
SSH connection refused means your client successfully reached the Ubuntu server over the network, but the SSH service actively rejected the connection. This typically occurs because the SSH daemon is not running, is not listening on the port you're trying to connect to, or is bound only to localhost instead of external interfaces.
How do I check if SSH is running on Ubuntu?
Run systemctl status ssh or systemctl status sshd in the terminal. The output shows whether the service is active (running), inactive (stopped), or failed. If you see 'active (running)' in green, the service is running. You can also verify SSH is listening on port 22 with sudo ss -tlnp | grep ssh.
Why is my firewall blocking SSH on Ubuntu?
Ubuntu's UFW firewall blocks all incoming connections by default unless explicitly allowed. If SSH was not enabled in UFW, all connection attempts to port 22 will be blocked. Fix this by running sudo ufw allow ssh or sudo ufw allow 22/tcp, then verify with sudo ufw status. For cloud servers, also check your provider's security group settings.
How do I fix SSH connection refused after changing the port?
If you changed SSH to a non-standard port in /etc/ssh/sshd_config, update your firewall rules to match. Run sudo ufw allow your-port-number/tcp, then restart SSH with sudo systemctl restart ssh. Connect using ssh -p your-port-number user@server. Verify the service is listening on the new port with sudo ss -tlnp | grep ssh.
What is the difference between connection refused and connection timeout for SSH?
Connection refused means the server received your connection attempt and actively rejected it, usually because no service is listening on that port. Connection timeout means your connection attempt never reached the SSH service, typically due to firewall rules blocking traffic, incorrect IP address, or network routing issues. Refused is a service problem; timeout is a network problem.
Related articles
- Hosting OperationsSelf-Hosted App Deployment Fails? Check DNS, SSL, Reverse Proxy, and Logs FirstTroubleshoot failed self-hosted app deployments by checking DNS, SSL, reverse proxy routing, container status, logs, and ports.
- Hosting OperationsSelf-Hosted PaaS on a VPS: What to Check Before Installing Coolify, Dokploy, or CapRoverA hosting support checklist for preparing a VPS before installing self-hosted PaaS tools like Coolify, Dokploy, or CapRover.
- Hosting OperationsLinux Server Security Lessons from the Arch Linux Malware Package IncidentPractical Linux server security checklist for VPS admins after package malware concerns, with safe checks, rollback steps, and support guidance.
- Hosting OperationsAWS Lightsail Hong Kong VPS Latency: Practical Hosting Guide for IndonesiaLearn how to test AWS Lightsail Hong Kong VPS latency, compare regions, migrate safely, and troubleshoot hosting performance.
- Hosting OperationsCloudflare Tomorrow Watchlist: A Practical Hosting Operations GuidePractical Cloudflare troubleshooting checklist for DNS, SSL, caching, WAF, origin health, safe testing, and rollback planning.
- Hosting OperationsNetwork Safety Checklist for AI Agent Skills in Hosting OperationsAudit AI agent skills safely with network checks, secret protection, sandbox testing, rollback steps, and hosting support troubleshooting guidance.