Troubleshooting Common SSH Errors: Connection Refused and Denied

SSH failures are easier to fix when you separate transport problems from authentication problems. Connection refused means your SSH client reached a host, but nothing accepted the TCP connection on that port. Permission denied means the SSH server answered, but it rejected your login. Those are different incidents, even if they both feel like "I can't get in."

Keep one active SSH session open while changing server settings. Most painful SSH outages happen when someone edits /etc/ssh/sshd_config, restarts the service, disconnects, and only then discovers that the new config blocks every login path.

Understanding the Errors: Refused vs. Denied

Read the exact client message before changing anything:

• Connection refused: the host actively rejected the TCP connection, usually because sshd is not listening on that port or a firewall is rejecting it.
• Connection timed out: packets are being dropped or the network path is broken. This is more likely a firewall, route, VPN, security group, or wrong IP.
• Permission denied (publickey): the server is reachable, but it did not accept your key.
• Permission denied (publickey,password): the server tried one or more auth methods and rejected them.
• Host key verification failed: your client does not trust the server identity currently presented for that hostname or IP.

---

Part 1: Troubleshooting Connection Refused

ssh: connect to host example port 22: Connection refused usually points to the remote host or port. The machine answered, but SSH was not accepting connections there.

1. Verify the SSH Daemon (sshd) Status

The most common cause for refusal is that the SSH server process is not running or has crashed.

Actionable Steps (on the remote server):

On many Linux distributions the service is called sshd; on Debian and Ubuntu it is often called ssh. Try the one your system uses:

systemctl status sshd
systemctl status ssh

If the service is inactive or failed, start it:

sudo systemctl start sshd
sudo systemctl enable sshd

If sshd fails to start after a config change, validate the config:

sudo sshd -t

That command is one of the safest checks you can run before restarting SSH.

2. Check the Listening Port and Configuration

By default, SSH uses TCP port 22, but many servers use a different port. If the server listens on 2222, the client command must include it:

ssh -p 2222 [email protected]

A. Review sshd_config

Examine the SSH configuration file, typically located at /etc/ssh/sshd_config. Look for the Port directive:

# /etc/ssh/sshd_config example
Port 2222  # If this is not 22, you need to specify it client-side

After editing the file, run sudo sshd -t before reloading. If the syntax is valid, reload or restart the service. Reload is usually less disruptive:

sudo systemctl reload sshd

B. Verify Listening Sockets

Use ss to confirm that sshd is listening:

sudo ss -tuln | grep 22

# Expected output showing listening status:
# LISTEN 0      128    0.0.0.0:22               0.0.0.0:* 

If SSH listens only on 127.0.0.1:22, remote clients cannot connect. If it listens on 0.0.0.0:22 or a specific private interface address, remote access may be possible depending on firewall rules.

3. Firewall and Network Checks

A firewall that drops packets usually causes a timeout. A firewall that rejects packets may cause a refusal. Check both the host firewall and any network firewall outside the host.

Common Firewall Commands (UFW on Ubuntu/Debian):

Ensure SSH traffic is allowed:

# Check current status
sudo ufw status

# Allow traffic on default port 22
sudo ufw allow ssh
# OR by port number
sudo ufw allow 22/tcp

# Reload firewall rules
sudo ufw reload

Cloud security groups, network ACLs, VPN routes, and office firewalls can block SSH before traffic reaches the server. If sshd is listening and the host firewall is open, test from a machine inside the same private network. That tells you whether the problem is local to the server or somewhere along the external path.

---

Part 2: Troubleshooting Permission Denied

If the server replies with Permission denied, the network path is working. Focus on username, allowed auth methods, keys, account state, and file permissions.

1. Check Username and Password

This is the simplest check, but often overlooked:

• Username: Cloud images often use specific users such as ubuntu, ec2-user, admin, debian, or rocky. root may be disabled.
• Password: If password auth is enabled, check typos, account lockout, expired passwords, and PAM rules.
• Port and host: A surprising number of auth failures are caused by connecting to the wrong server that happens to run SSH.

Client-Side Check: To see detailed debug output, run your client with verbose flags:

ssh -vvv user@hostname

This output will clearly show which authentication methods the client attempted and which the server rejected.

2. Key-Based Authentication Failures

Key authentication fails when the client offers the wrong private key, the server does not have the matching public key, permissions are too open, or sshd_config blocks the login.

A. Incorrect Permissions on .ssh Directory

SSH is extremely strict about file permissions for security. If the permissions are too open, the server will ignore the key file entirely.

On the Remote Server (Fixing Permissions):

# User's home directory permissions are usually fine, but check the .ssh folder
chmod 700 ~/.ssh

# The authorized_keys file must only be writable by the owner
chmod 600 ~/.ssh/authorized_keys

Also check ownership:

chown -R "$USER:$USER" ~/.ssh

On the server, StrictModes is commonly enabled. If the home directory, .ssh directory, or authorized_keys file is writable by other users, sshd may ignore the key.

B. Key Not Present or Incorrectly Formatted

Ensure the public key is in the target user's ~/.ssh/authorized_keys, one key per line. The private key stays on your client. Do not paste the private key into authorized_keys.

From the client, force a specific key while debugging:

ssh -i ~/.ssh/id_ed25519 -vvv [email protected]

In the verbose output, look for lines showing which keys were offered and why the server accepted or rejected them.

C. Server Configuration Disabling Keys

Check /etc/ssh/sshd_config on the server to ensure key authentication is permitted:

PubkeyAuthentication yes

# Ensure password authentication is not disabled if you rely on passwords
PasswordAuthentication yes

If AllowUsers, AllowGroups, DenyUsers, or DenyGroups are present, they can override what looks like a valid key setup. A user with the right key can still be blocked by those directives.

3. Server-Side Log Investigation

Server logs usually tell you the real reason for a denial. Keep a terminal open on the server and watch logs while attempting a login from the client.

Common Log Locations:

• Debian/Ubuntu: /var/log/auth.log
• RHEL/CentOS/Fedora: /var/log/secure

Use grep to filter for recent connection attempts:

# On RHEL/CentOS systems
sudo grep 'Failed password' /var/log/secure

# Or look for general SSH activity
sudo tail -f /var/log/secure

On systems with systemd journaling, this is often easier:

sudo journalctl -u sshd -f
sudo journalctl -u ssh -f

Log messages may show "bad ownership or modes", "user not allowed", "invalid user", "authentication refused", or PAM account failures. Those messages are more reliable than guessing from the client side alone.

Host key verification failures

Host key verification failed is not the same as a bad password or key. It means your client has a saved server identity for that hostname or IP, and the server is now presenting a different identity. That can happen after a rebuild, IP reuse, load balancer change, or a real man-in-the-middle risk.

Do not blindly delete the warning in a production environment. Verify the server fingerprint through your cloud console, configuration management, or an existing trusted channel. Once you know the change is expected, remove the old entry:

ssh-keygen -R example.com
ssh-keygen -R 192.0.2.10

Then connect again and accept the new host key only if the fingerprint matches what you expect.

---

Best Practice Summary for Reliable SSH Access

1. Use key pairs: Disable password authentication only after you have tested key access in a second session.
2. Limit who can log in: Use AllowUsers or AllowGroups when appropriate, but document it so future operators do not chase false permission problems.
3. Use PermitRootLogin no: Prefer normal users with sudo.
4. Back up configuration: Before changing /etc/ssh/sshd_config, copy it:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%F) ``` 5. Validate before reload: Run sudo sshd -t. 6. Keep a break-glass path: For cloud servers, know how to use the serial console, rescue mode, instance connect feature, or configuration management if SSH breaks.

The shortest path through SSH troubleshooting is: identify the exact error, prove whether the server is listening, prove whether the network path reaches that port, then read the server logs for authentication failures. Guessing usually takes longer than running those checks in order.