Your First Move: Use Verbose Mode
Before you start changing configurations, your most powerful tool is SSH's own verbose mode. Running your connection command with a `-v` flag tells the client to print out detailed debugging information about the connection process. You'll see the client and server
exchange information, negotiate encryption, and attempt authentication. For even more detail, you can use `-vv` or `-vvv`. This log is your roadmap; it often reveals exactly where the process is failing, whether it's a negotiation problem, a key mismatch, or an issue on the server side, guiding you directly to the source of the trouble.
Error: Connection Refused
The 'Connection refused' error is one of the most common and means your request reached the server, but the server actively rejected it. This isn't a network timeout; it's a specific denial. The most frequent causes are straightforward. First, the SSH service (often called `sshd`) might not be running on the server. You can check its status using commands like `sudo systemctl status sshd`. Second, a firewall on the server or an intermediary network device could be blocking traffic on the SSH port, which is typically port 22. Finally, you might simply be connecting to the wrong IP address or port, especially if the server uses a non-standard port for security. Systematically checking these three possibilities will resolve the vast majority of 'Connection refused' errors.
Error: Permission Denied (publickey)
This maddening error tells you that you've successfully connected to the SSH server, but it rejected the specific key you offered for authentication. This is almost always a configuration or permissions issue. The leading cause is incorrect file permissions on the server. For security, SSH requires that your home directory, your `~/.ssh` directory, and the `~/.ssh/authorized_keys` file have strict permissions. The `~/.ssh` directory should be `700` (readable, writable, and executable only by you), and the `authorized_keys` file inside it should be `600` (readable and writable only by you). If permissions are too open, the server will ignore the keys as a security precaution. Other causes include the public key not being correctly added to the `authorized_keys` file or the client offering the wrong private key if you have several configured.
Error: Connection Timed Out
Unlike 'Connection refused,' a 'Connection timed out' error suggests your machine couldn't reach the server at all. The server isn't actively rejecting you; your connection request is simply getting lost on the way. The problem lies somewhere in the network path between your client and the server. This could be a fundamental network connectivity issue, like your own internet being down or a broader network outage. More commonly, it points to a firewall or security group rule that is silently dropping your connection attempt instead of actively refusing it. You should also double-check that you have the correct IP address for the server. A simple `ping` command to the server's IP can help you determine if there is a basic network path available.
Server-Side and Final Checks
If client-side troubleshooting fails, the problem may lie entirely on the server. Beyond ensuring the SSH service is running, it's crucial to check the server's own logs, typically found in `/var/log/auth.log` or `/var/log/secure`. These logs provide the server's perspective on why a connection failed. You should also verify that the SSH server's configuration file (`/etc/ssh/sshd_config`) allows the type of authentication you're attempting. For example, it might have `PasswordAuthentication no` or `PubkeyAuthentication no` set, explicitly disabling those methods. Finally, ensure the user account you're trying to log in with actually exists and is permitted to log in via SSH.
