FAQ and Troubleshooting Guide

This FAQ and troubleshooting guide addresses common questions and issues encountered when using SSH. It covers solutions to typical problems and provides insights into troubleshooting errors that users may face.

Frequently Asked Questions

Why can't the SSH server be reached?

Several factors can prevent an SSH server from being reachable:

  • Network issues: Check network connectivity using ping or traceroute to the SSH server.
  • Firewall rules: Ensure that port 22 (or the custom SSH port) is open in the firewall.
  • SSH service not running: Verify that the SSH service is running on the server by executing sudo systemctl status sshd (or equivalent).

How can the SSH service be restarted?

To restart the SSH service on most Linux systems, use the following command:

sudo systemctl restart sshd

On older systems or different configurations:

sudo service ssh restart

What does "Permission denied (publickey)" mean?

This error indicates that the server is configured to require public key authentication, and the client either does not have the correct key or the key is not authorized on the server. Verify that the public key is added to the ~/.ssh/authorized_keys file on the server and that the client is using the correct private key.

How to resolve "Host key verification failed"?

The error occurs when the server's host key does not match the key stored on the client, possibly due to a server change or a man-in-the-middle attack.

  • If the server's host key has legitimately changed, remove the old key from ~/.ssh/known_hosts:
ssh-keygen -R hostname
  • Connect again to re-verify the server’s new key.

What should be done if SSH hangs or times out?

If SSH hangs or times out while connecting, it may be due to network issues, DNS problems, or a slow server response. Try the following:

  • Use verbose mode to gather more information:
ssh -v user@hostname
  • Disable DNS lookups by adding UseDNS no to the server’s sshd_config file.
  • Increase connection timeout by specifying the ConnectTimeout option:
ssh -o ConnectTimeout=10 user@hostname

Why is the "Too many authentication failures" error shown?

This error occurs when the client tries multiple authentication methods (e.g., keys or passwords) and exceeds the server's authentication limit. The following solutions can help:

  • Limit the keys used in a session by specifying the correct identity file:
ssh -i ~/.ssh/id_rsa user@hostname
  • Increase the server’s MaxAuthTries in sshd_config to allow more authentication attempts.

How to troubleshoot "Connection refused" errors?

This error generally indicates that the SSH service is not running on the server or that the firewall is blocking the connection.

  • Check that the SSH service is running:
sudo systemctl status sshd
  • Ensure that the correct port is being used. If the SSH service runs on a non-standard port, specify it with the -p option.
  • Check firewall rules to ensure that the SSH port is open on both the client and the server.

Troubleshooting Tips

Using Verbose Mode to Debug SSH Issues

Verbose mode (-v, -vv, -vvv) can help identify SSH issues by providing detailed output during the connection process. Increasing verbosity helps pinpoint where the failure occurs:

ssh -vvv user@hostname

Checking Server Logs

When troubleshooting server-side issues, examining the SSH logs can provide insights. On most Unix-based systems, the logs are found in /var/log/auth.log or /var/log/secure. To view SSH logs:

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

Look for errors related to authentication or connection attempts.

Resolving Permission Issues with SSH Keys

Ensure that the permissions on the .ssh directory and the key files are correct:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_rsa
chmod 644 ~/.ssh/authorized_keys

Incorrect permissions can prevent SSH from using keys for authentication.


This FAQ and troubleshooting guide covers common SSH issues and provides practical solutions for resolving them. By using verbose mode and checking logs, most SSH problems can be diagnosed and resolved efficiently.