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
sudocommands 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 tono, root login is prohibited.AllowUsersorDenyUsers: Check if access is restricted for your user.PasswordAuthentication: Ifno, key-based authentication is required.PubkeyAuthentication: Should beyesfor 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_hostson 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.