Troubleshoot SSH: timeout, refused and permission denied
Where to start: Find your exact error in the table, then follow the relevant step. Failing to reach the server and having the server reject your sign-in are different problems.
The exact SSH error tells you where the connection failed. A timeout, a refused connection and an authentication failure need different checks. Start by recording the message, time and last relevant change.
Applies to: An OpenSSH client, with server-side commands for Ubuntu 24.04 LTS or Debian 13. The initial checks do not change settings. Keep any working SSH session open. Do not assume that every service includes console or rescue access.
The error helps you choose which stage to check.
- Address
Can the server name be resolved? Check the IP and spelling.
- Network and port
Does the SSH port respond? Timeout and refused point to checks at this stage.
- Server identity
Does the fingerprint match? Verify any change before continuing.
- Account and key
Is the sign-in method accepted? For permission denied, check the account and key.
Keep any working SSH session open and follow the section for your exact error.
1. Verify the address, username and port
Compare three values one at a time: IP address → SSH username → SSH port. The values 203.0.113.10, server_user and 22 below are only examples.
Check the relevant service's provisioning information in the DCHost customer portal. Your hosting panel password may not be your SSH password. Replace the examples with your information and run on your computer:
ssh -p 22 server_user@203.0.113.10
Use the port the service actually listens on rather than guessing a new one. Match the result to the error types below.
Check: If the connection fails, save the exact message and find the same wording in the next table.
2. Identify the failure stage
How to use the table: Find your exact message in the first column. The last column points to the first check. Do not apply one error's fix to every other error.
| Error | What it means | First check |
|---|---|---|
Could not resolve hostname | The client could not resolve the name to an IP | Spelling, DNS and the IP in your service details |
Connection timed out | No connection response arrived within the timeout | Correct IP/port, server state, network and access rules |
Connection refused | The destination or an intermediate device rejected the connection | Listening service/port and rejecting firewall rules |
Permission denied | Authentication did not complete | Account, permitted authentication method and key/password |
REMOTE HOST IDENTIFICATION HAS CHANGED | The presented key differs from the saved identity | Reinstallation, IP changes and trusted fingerprint verification |
A failed ping does not prove that the server is down; ICMP may be blocked. A working website also does not prove that the SSH port is reachable.
3. Investigate timeouts and refused connections
Read the full message and check the stage where the connection failed.
- Connection timed out
No response in time: investigate the IP, port, server state and network access.
- Connection refused
Connection rejected: check the SSH listener and rejecting access rules.
- Permission denied
Sign-in rejected: verify the account, allowed method and key/password.
With no server access, do not run server commands on your computer; request support.
Start with your computer's connection:
- Compare the IP and port with the service details again.
- If using a company network or VPN, check whether the port is allowed.
- If possible, try the same destination from another trusted network.
No server access at all? Do not run the server commands below on your computer. Go to the support ticket section.
Check whether your local network permits outbound connections on that port. If a VPN or company security policy is involved, consult the network administrator. Testing the same address and port from another trusted connection can help determine whether the problem is limited to one network.
Only if you still have a working server session or verified console access, run these read-only checks on the server. Commands using sudo require appropriate administrator privileges; if your account lacks them, ask the server administrator for these results:
systemctl status ssh.service ssh.socket --no-pager
sudo ss -ltnp
sudo journalctl -u ssh.service --since "30 minutes ago" --no-pager
Some installations use socket activation, so do not judge the service from ssh.service alone. A missing ssh.socket unit is not an error on every installation either. Check ss output for the expected listening port. Match log timestamps with your connection attempts.
Do not disable the firewall or flush its rules before assessing access policy. Verify the existing session, a separate new connection and a recovery method you can use before changing the SSH port or firewall. If you have no access at all, open a support ticket with your service information rather than assuming these commands are available to you.
| Command | What should you look for? |
|---|---|
systemctl status | SSH service or listening socket unit state |
ss -ltnp | A LISTEN entry for your actual SSH port |
journalctl | SSH records matching your attempt time |
--since "30 minutes ago" selects the last 30 minutes. Empty logs alone do not prove the connection is healthy.
4. Investigate account and key failures
Check in this order: correct account → correct private key → allowed sign-in method. A key is authorized for a particular account; using another username on the same server is not equivalent.
For Permission denied (publickey), confirm the username and choose the private key authorized for that account. Resetting a password will not help if the server does not permit password login. Use a working session to check files and permissions as described in the SSH key guide.
For more detailed client output, run ssh -v -p 22 server_user@203.0.113.10 on your computer. The output may contain usernames, IP addresses, paths and key information. Remove unnecessary personal details before sharing it. Never attach your private key file or password.
Expected result: Adding -v displays extra lines about attempted sign-in methods and the failure stage. It does not fix the issue by itself.
5. Verify a changed server identity before proceeding
Verify first; remove the old entry second. A fingerprint checks the server's identity. Making the warning disappear does not prove you reached the right server.
A reinstall can change the SSH host key, but connecting to the wrong server can trigger the same warning. Verify the new SHA256 fingerprint through trusted service information or support. Do not bypass the check with options such as StrictHostKeyChecking=no.
After confirming that the change is legitimate, remove only the old entry for the relevant destination. On your computer, for the example IP using the default port:
ssh-keygen -R 203.0.113.10
A custom port uses the record format [IP]:port, for example ssh-keygen -R '[203.0.113.10]:2222'. When reconnecting, compare the displayed fingerprint with the value you verified. Do not delete the entire known_hosts file. This operation removes that destination's saved trust entry on your computer; it does not change server settings.
Check: If the old entry exists, the command reports its removal. The fingerprint on your next connection must match the value you verified beforehand.
Prepare a support ticket
Include the service ID, attempt time and time zone, target port, full error and recent changes. Share your source IP only through a private support channel if needed for investigation. Reinstalling, formatting disks or randomly rebooting is not an appropriate first diagnostic step. Use the support ticket guide to organize the information.