SSH Connection Fails: Troubleshooting SSH Issues on Linux Mint

SSH connection failures on Linux Mint typically stem from misconfigured firewall rules, disabled SSH services, or incorrect host key verification. This guide provides a systematic approach to diagnosing and resolving these connectivity issues by verifying service status, checking network permissions, and managing known hosts.

Verifying the SSH Service Status

The most common reason for an immediate refusal to connect is that the Secure Shell daemon is not running or has been disabled. On Linux Mint, which uses systemd, you can check the current state of the SSH service using the terminal. Open your terminal application and execute the following command to see if the service is active:

systemctl status ssh

If the output indicates that the service is inactive or dead, you need to start it manually. You can initiate the service with the command sudo systemctl start ssh. However, starting it once will not persist across reboots. To ensure the SSH server starts automatically every time your system boots, enable the service permanently by running:

sudo systemctl enable ssh

After enabling and starting the service, verify its status again to confirm it is now active and running. If the service was already running but connections still fail, proceed to check if the SSH configuration file has been modified incorrectly or if the port has been changed from the default.

Checking Firewall Configuration

Even if the SSH service is running, external connections may be blocked by the system firewall. Linux Mint typically uses UFW (Uncomplicated Firewall) as its interface for managing iptables rules. You should first check the current status of the firewall by typing:

sudo ufw status

If the status is listed as "active," you must ensure that traffic on port 22 (the default SSH port) is allowed. If the rule is missing, add it using the following command:

sudo ufw allow 22/tcp

In some cases, users may have customized their SSH port for security reasons. If you are connecting on a non-standard port, replace 22 with your specific port number in the allow command. After adding the rule, reload the firewall to apply the changes:

sudo ufw reload

If you recently migrated from another distribution or installed Windows Subsystem for Linux alongside Mint, you might encounter similar port conflicts. For insights into handling WSL-related SSH connectivity problems, refer to our guide on Troubleshooting SSH WSL Machine: Can't Connect to Localhost.

Resolving Host Key Verification Errors

A frequent source of confusion for users is the "Host key verification failed" error. This occurs when the SSH client detects a mismatch between the stored host key for the remote server and the key currently presented by that server. This often happens after reinstalling the operating system on the remote machine or if someone is attempting a man-in-the-middle attack. To resolve this safely, you must remove the outdated entry from your local known hosts file. First, identify the IP address or hostname causing the issue. Then, use the ssh-keygen utility to delete the specific entry. Replace example.com with the actual remote host identifier:

ssh-keygen -R example.com

Once the old key is removed, attempt to connect again. The client will prompt you to accept the new host key. Type yes to store the new key in your ~/.ssh/known_hosts file. This process ensures that your client trusts the current identity of the remote server. Be cautious only to do this if you are certain about the server's identity, as blindly accepting keys can expose you to security risks.

Testing Connectivity with Verbose Output

When standard troubleshooting steps do not resolve the issue, increasing the verbosity of the SSH command can provide critical diagnostic information. By adding multiple -v flags, you can see exactly where the connection process hangs or fails. Try connecting with three levels of verbosity:

ssh -vvv user@remote_host

This output will show each step of the authentication and connection negotiation process. Look for lines indicating "Connection refused," "Network is unreachable," or "Permission denied." If you experience significant delays before the password prompt appears, the issue might be related to DNS resolution or GSSAPI authentication attempts. In such scenarios, investigating connection delays is essential. You can find detailed steps on how to fix these latency issues in our article How to troubleshoot a long delay when connecting over SSH?. Additionally, if you are trying to connect from a different environment, such as Ubuntu to Windows, the underlying protocol differences might cause timeouts. Understanding cross-platform SSH limitations can help isolate whether the problem lies with the client or the server architecture. See Unable to Connect Ubuntu 20.04 to Windows for more context on mixed-environment connections.

Frequently Asked Questions

Why does SSH say "Connection Refused"?

This error usually means the target machine is reachable, but no program is listening on the specified port. Ensure the SSH service is actually started on the remote machine using systemctl status ssh.

How do I change the default SSH port on Linux Mint?

Edit the /etc/ssh/sshd_config file and change the line Port 22 to your desired number. Remember to restart the SSH service and update your firewall rules to allow the new port.

What should I do if my SSH key is rejected?

Verify that the public key is correctly appended to the ~/.ssh/authorized_keys file on the server. Check file permissions; the private key should be readable only by you (chmod 600), and the server's home directory should not be world-writable.

Can I use SSH without a password?

Yes, by setting up SSH key-based authentication. Generate a key pair on your client using ssh-keygen, then copy the public key to the server using ssh-copy-id. This allows seamless login without entering a password each time.

Why am I getting a "Permission Denied (publickey)" error?

This indicates the server rejected your authentication attempt. It often happens if you are using the wrong username or if the server is configured to disallow password logins while you are not providing a valid key. Check the server's sshd_config for PubkeyAuthentication yes.