Your network is down, and you’re staring at a cryptic error message. The frustrating reality is that most network issues aren’t a single point of failure, but a cascade of events. Understanding how these components interact is key to unraveling the mystery.
Let’s say you’re seeing Connection refused when trying to ssh to a server. This isn’t just a "timeout"; it means the server’s operating system actively rejected your connection attempt. The interesting part is why it chose to reject it, as this points directly to the specific service or configuration that’s misbehaving.
Here’s how to systematically diagnose and fix this:
1. The Remote Server Isn’t Listening: The most common reason is that the SSH daemon (sshd) on the target server simply isn’t running or isn’t configured to listen on the expected port (default is 22).
* Diagnosis: On the remote server, run sudo ss -tulnp | grep sshd. You’re looking for a line showing sshd listening on 0.0.0.0:22 or :::22 (for IPv6).
* Fix: If it’s not listening, start it with sudo systemctl start sshd and enable it to start on boot with sudo systemctl enable sshd. If it is listening but on a different port (e.g., 2222), you need to update your SSH command: ssh -p 2222 user@host.
* Why it works: This ensures the SSH service is active and accessible on the network interface and port you expect.
2. A Firewall is Blocking the Connection: A firewall, either on the server itself (iptables, firewalld, ufw) or a network-level firewall, is actively dropping or rejecting packets destined for port 22.
* Diagnosis:
* On the server: Check sudo iptables -L -n -v (for iptables), sudo firewall-cmd --list-all (for firewalld), or sudo ufw status verbose (for ufw). Look for rules that might be blocking port 22.
* From your client machine, try telnet host 22. If it says "Connection refused," it’s likely the server’s OS or local firewall. If it times out, it’s more likely a network firewall or the server is down.
* Fix:
* For iptables: sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT (to allow).
* For firewalld: sudo firewall-cmd --permanent --add-service=ssh followed by sudo firewall-cmd --reload.
* For ufw: sudo ufw allow ssh or sudo ufw allow 22/tcp.
* If it’s a network firewall, you’ll need to consult your network administrator to open port 22.
* Why it works: Firewalls act as gatekeepers; explicitly allowing traffic on port 22 tells the firewall to let your SSH connection through.
3. Incorrect Network Configuration on the Server: The server’s network interface might not have an IP address assigned correctly, or it might be on the wrong subnet, preventing it from communicating on the network.
* Diagnosis: On the remote server, run ip addr show or ifconfig. Verify that the primary network interface (e.g., eth0, ens192) has a valid IP address in the correct subnet and that the interface is marked as UP.
* Fix: If the IP address is missing or incorrect, you’ll need to reconfigure the network interface. This often involves editing files like /etc/netplan/*.yaml (Ubuntu), /etc/sysconfig/network-scripts/ifcfg-eth0 (CentOS/RHEL), or using nmcli (NetworkManager). For example, to set a static IP: sudo ip addr add 192.168.1.100/24 dev eth0 and sudo ip link set eth0 up. Then, ensure your DNS and gateway are also correct.
* Why it works: A correctly configured IP address is the fundamental requirement for a device to participate in network communication.
4. Routing Issues: Even if the server has an IP, the network path between your client and the server might be broken. Packets are being sent, but they don’t reach their destination because of incorrect routing tables somewhere in the network.
* Diagnosis: From your client machine, run traceroute host (or tracert host on Windows). This command shows the path packets take to reach the destination. Look for timeouts (* * *) or hops that are unexpectedly far away or in the wrong network segment. On the server, check ip route show.
* Fix: This is often the most complex to fix as it can involve routers outside your immediate control. On the server, ensure the default gateway is correctly set (e.g., sudo ip route add default via 192.168.1.1 dev eth0). If the issue is on your local network, you might need to reconfigure your router. If it’s a larger network, you’ll need to involve network engineers.
* Why it works: Routing tells network devices where to send packets to reach their destination. Correcting routing ensures packets can traverse the network path.
5. DNS Resolution Problems: If you’re using a hostname (e.g., ssh user@myserver.example.com) and getting Connection refused, it’s possible DNS is resolving to the wrong IP address, and the server at that IP isn’t running SSH or is refusing the connection.
* Diagnosis: On your client machine, run dig myserver.example.com or nslookup myserver.example.com. Verify that the IP address returned is the correct one for your target server. Then, from your client, try ping <resolved_ip_address>.
* Fix: If the IP is wrong, you need to fix the DNS record with your DNS provider. If the IP is correct but ping fails, you’re back to checking firewalls or network connectivity to that IP.
* Why it works: DNS translates human-readable names into machine-readable IP addresses. An incorrect IP means you’re trying to connect to the wrong place.
6. SSH Daemon Configuration Errors: The sshd_config file on the server might be misconfigured, preventing legitimate connections.
* Diagnosis: On the remote server, check the SSH logs for errors: sudo journalctl -u sshd or look in /var/log/auth.log or /var/log/secure. Also, examine /etc/ssh/sshd_config for directives like ListenAddress, Port, AllowUsers, DenyUsers, AllowGroups, or DenyGroups.
* Fix: Correct any syntax errors or restrictive directives in /etc/ssh/sshd_config. For example, if ListenAddress is set to 127.0.0.1, it will only accept connections from the server itself. Change it to ListenAddress 0.0.0.0 to listen on all interfaces. After editing, restart SSH: sudo systemctl restart sshd.
* Why it works: The sshd_config file dictates how the SSH server behaves, including who can connect and from where. Correcting these settings aligns the server’s behavior with your connection attempts.
After fixing these, the next error you’ll likely encounter is Permission denied (publickey,password).