Linux

Fixing SSH Connections in Linux: Diagnosis and Problem Solving

This guide provides step-by-step instructions for resolving common SSH issues on Linux, helping you restore remote access and secure connections.

Updated at February 17, 2026
15-30 min
Medium
FixPedia Team
Применимо к:Ubuntu 20.04/22.04CentOS 7/8Debian 10/11Fedora 35+

Introduction / Why This Is Needed

SSH (Secure Shell) is the standard protocol for secure remote management of servers and network devices. However, when working with SSH on Linux, various issues can arise—from an inability to establish a connection to authentication errors. This guide will help you systematically diagnose and resolve common malfunctions to restore working SSH access.

Requirements / Preparation

Before you begin, ensure the following:

  • You have physical or alternative remote access to the server (e.g., via your hosting provider's management console) if SSH is not working.
  • You know the IP address or domain name of the target server.
  • An SSH client is installed on your client computer (typically openssh-client).
  • You are prepared to use sudo commands to perform administrative tasks.

Step 1: Check the SSH Daemon Status

First, ensure the SSH server (sshd) is running on the target server. Connect to the server via console (if possible) or use an alternative access method.

Run the command:

sudo systemctl status sshd

Or on older systems:

sudo service ssh status

If the service is not active, start it:

sudo systemctl start sshd

To enable automatic startup at boot:

sudo systemctl enable sshd

Step 2: Diagnose Network Connectivity and Port 22

Check if the server is reachable over the network and if port 22 (the standard for SSH) is open.

From the client machine, run:

telnet <server_IP> 22

Or, if telnet is not installed:

nc -zv <server_IP> 22

If the connection is established, you will see an SSH greeting. If not, the issue may be with the network, firewall, or the SSH daemon is not listening on port 22.

Ensure the SSH daemon is listening on all interfaces. On the server, check:

sudo ss -tlnp | grep :22

You should see something like: LISTEN 0 128 *:22 *:* users:(("sshd",pid=1234,fd=3)). If it's only listening on 127.0.0.1, adjust the configuration.

Step 3: Check SSH Server Configuration

Errors in the /etc/ssh/sshd_config configuration file can block connections. Check this file for options that restrict access.

Open the file:

sudo nano /etc/ssh/sshd_config

Or use vi/vim.

Pay attention to these parameters:

  • Port: If changed from the standard 22, ensure the client connects to the correct port.
  • PermitRootLogin: If set to no, root login is prohibited.
  • AllowUsers or DenyUsers: Check if access is restricted for your user.
  • PasswordAuthentication: If no, key-based authentication is required.
  • PubkeyAuthentication: Should be yes for keys.

After making changes, restart SSH:

sudo systemctl restart sshd

Step 4: Analyze SSH Logs

SSH logs contain detailed error information. Main log locations:

On Debian/Ubuntu:

sudo tail -f /var/log/auth.log

On CentOS/RHEL/Fedora:

sudo tail -f /var/log/secure

Try connecting from the client while watching the logs. Look for lines with "sshd" and error messages like "Failed password", "Connection closed", "Invalid user". This will indicate the cause.

If the logs are empty, the connection may not be reaching the SSH daemon due to a firewall or network issue.

Step 5: Check SSH Keys and Permissions

If key-based authentication is used, ensure keys are configured correctly.

On the client, check for the presence of the private key (usually ~/.ssh/id_rsa or id_ed25519) and its permissions:

ls -la ~/.ssh/
chmod 600 ~/.ssh/id_rsa  # if RSA key
chmod 600 ~/.ssh/id_ed25519  # if Ed25519 key

On the server, check that the public key is added to ~/.ssh/authorized_keys for the user, and check permissions:

ls -la ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

The ~/.ssh directory should have permissions set to 700.

If keys are not working, regenerate the key pair and copy the public key using ssh-copy-id:

ssh-copy-id user@server

Step 6: Configure the Firewall

The server's firewall may be blocking port 22. Check active rules.

For ufw (Ubuntu/Debian):

sudo ufw status

If SSH is not allowed, add it:

sudo ufw allow 22

Or for a specific port if changed.

For firewalld (CentOS/RHEL/Fedora):

sudo firewall-cmd --list-all

Allow SSH:

sudo firewall-cmd --add-service=ssh --permanent
sudo firewall-cmd --reload

For iptables (older systems):

sudo iptables -L -n

Add a rule if necessary.

Verify the Result

After completing the steps, try connecting from the client:

ssh user@server

If using a non-standard port:

ssh -p <port> user@server

A successful connection with a command prompt or without a password prompt (with key authentication) indicates the problem is resolved.

Potential Issues

Additional complications may arise while following this guide:

  • "Connection timed out" error: Check if the server is reachable over the network (ping, traceroute) and ensure there is no blocking on intermediate routers.
  • "Host key verification failed" error: This may indicate a change in the server's host key. Delete the server's entry from ~/.ssh/known_hosts on the client and try again.
  • SELinux issues (on CentOS/RHEL): If SELinux is in enforcing mode, it may block SSH. Check SELinux logs (ausearch -m avc -ts recent) and adjust policies.
  • Insufficient server resources: If the server is overloaded, the SSH daemon may not respond. Check CPU and memory usage (top, htop).

This list is not exhaustive; use the logs and diagnostic commands for further analysis.

F.A.Q.

Why does SSH refuse to connect with a 'Connection refused' error?
How to fix 'Permission denied (publickey)' when connecting via SSH?
What to do if the SSH connection drops after some time?
Can I use SSH without a password using only keys?

Hints

Check SSH daemon status
Network connection troubleshooting
Check SSH configuration
Analyze SSH logs
Check SSH keys
Configure firewall

Did this article help you solve the problem?

FixPedia

Free encyclopedia for fixing errors. Step-by-step guides for Windows, Linux, macOS and more.

© 2026 FixPedia. All materials are available for free.

Made with for the community