Connection Issues

This page covers the most common SSH connection errors and how to resolve them.

Connection Refused

Error: Connection refused or connect ECONNREFUSED

Cause: The target host received the TCP connection attempt but actively rejected it. This means the host is reachable at the network level, but nothing is listening on the specified port.

Solutions:

1. Verify the SSH daemon is running on the server:

   sudo systemctl status sshd
   # or
   sudo systemctl status ssh

   If it is not running, start it: sudo systemctl start sshd

2. Check the port. If the server runs SSH on a non-standard port (e.g. 2222), make sure your ZestSSH connection is configured with the correct port.

3. Check the server’s firewall: The server’s own firewall (iptables, ufw, firewalld) may be blocking the port.

   sudo ufw status       # Ubuntu/Debian
   sudo firewall-cmd --list-all  # RHEL/CentOS

4. Docker / container port conflicts: If the server runs Docker, a container may have taken port 22.

Host Unreachable / Network Timeout

Error: No route to host, Network is unreachable, or the connection times out silently.

Cause: There is no network path between your device and the server.

Solutions:

1. Check your internet connection. Switch between Wi-Fi and cellular to rule out a local network issue.

2. Verify the hostname/IP. DNS resolution may have failed or returned a stale IP. Try connecting by IP address directly.

3. Check if the server is up. Use another tool or a web-based ping service to verify the server is online.

4. Router / NAT port forwarding. If the server is behind a NAT router, verify the port forwarding rule is still active and pointing to the correct internal IP.

5. ISP blocking. Some ISPs or networks (corporate, hotel, airport) block outbound port 22. Try using an alternate SSH port (443 often works, as it is the HTTPS port and is rarely blocked).

6. VPN interference. If you are using a VPN, it may not be routing traffic to the server’s network. Try disconnecting the VPN.

Permission Denied (publickey)

Error: Permission denied (publickey) or All configured authentication methods failed

Cause: The server rejected all authentication attempts. The SSH key you provided is not authorized on the server.

Solutions:

1. Verify the correct identity is selected. In the ZestSSH connection editor, check that the assigned identity has the right SSH key and username.

2. Check authorized_keys on the server. The public key must be in ~/.ssh/authorized_keys for the target user:

   cat ~/.ssh/authorized_keys

   Compare the public key on the server with the one in ZestSSH (Identities > select identity > view public key).

3. File permissions. OpenSSH is strict about file permissions:

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

   The home directory must not be world-writable.

4. Wrong username. The identity username must match the user account on the server. root and admin are different users.

5. Server configuration. The server may have PubkeyAuthentication no in sshd_config, or it may restrict which users can log in via AllowUsers or AllowGroups.

Permission Denied (password)

Error: Permission denied (password) after entering the correct password.

Solutions:

1. Password authentication may be disabled on the server (PasswordAuthentication no in sshd_config). This is a common security hardening step.

2. Account locked. Too many failed login attempts may have locked the account via PAM or fail2ban.

3. Wrong password. Passwords are case-sensitive. Check for leading/trailing spaces.

4. Keyboard-interactive vs. password. Some servers use keyboard-interactive authentication instead of simple password auth. ZestSSH supports both.

Host Key Verification Failed

Error: ZestSSH shows a warning that the host key has changed.

Cause: The server’s SSH host key is different from what ZestSSH previously stored. This can happen if:

• The server was reinstalled or its SSH daemon was reconfigured.
• You are connecting to a different server at the same IP (e.g. after a cloud provider reassigned the IP).
• A man-in-the-middle attack is intercepting your connection.

What to do:

1. If you know the server was reinstalled or changed, accept the new host key in the ZestSSH prompt. The old key will be replaced.

2. If you are unsure, do NOT accept the new key. Verify the server’s host key fingerprint through an out-of-band channel (console access, hosting provider’s dashboard, a colleague who has physical access).

3. To clear a specific known host, go to Settings > Known Hosts and remove the entry for the affected host.

Firewall and NAT Issues

Symptoms: Connections time out or are intermittently dropped.

Solutions:

1. Corporate firewalls often block port 22. Solutions:

   • Run SSH on port 443 (the HTTPS port, which is almost never blocked).
   • Use your server’s web-based console to change the SSH port.

2. NAT timeout: If connections drop after a period of inactivity, NAT gateways may be closing the idle TCP connection. Enable keep-alive in ZestSSH:

   • Connection editor > Keep-Alive Interval: 15-30 seconds.

3. Double NAT: If both your device and the server are behind NAT, you may need a relay or jump host with a public IP.

Connection Drops During Use

Symptoms: Connection works initially but drops after minutes or hours.

Solutions:

1. Enable SSH keep-alive (connection editor > Keep-Alive Interval). Set to 15-30 seconds.
2. Enable Zlib compression for slow or congested links.
3. Use tmux or screen on the server to maintain your session across drops. See the tmux Workflow guide.
4. On mobile, review battery optimization settings. See Android Background Connections and iOS Sessions Disconnecting.

”Too Many Authentication Failures”

Error: Too many authentication failures for [user]

Cause: ZestSSH (or the SSH client library) offered too many keys before finding the right one, and the server’s MaxAuthTries limit was reached.

Solutions:

1. Assign a specific identity to the connection so ZestSSH does not try multiple keys.
2. On the server, increase MaxAuthTries in sshd_config (default is 6).

”Key Exchange Failed”

Error: kex error or no matching key exchange method found

Cause: The server and ZestSSH have no key exchange algorithms in common. This usually means the server is very old.

Solutions:

1. Check the server’s supported KEX algorithms: ssh -Q kex (on the server).
2. Update the server’s OpenSSH to a newer version that supports modern algorithms.
3. See Supported KEX Algorithms for the full list ZestSSH supports.