How to Troubleshoot SSH Access When It Does Not Work

If SSH access is not working, first check whether the connection reaches the server, then verify the user authentication, and finally inspect the SSH service on the server. On a shared hosting account, these settings may be limited to the provider’s control panel; on a VDS or managed server, you may need the administration panel and an existing console connection. Before making any change, save the current setting and change only one factor at a time.

Determine the environment and existing access for SSH access first

This guide is intended for a Linux-based VDS, VPS, or a server where you have administrative access. The device from which you are trying to connect must have a terminal, the server’s IP address or domain name, the correct username, and the SSH port specified by the provider. The SSH port is the network gateway on which connections are accepted; if a port other than the default is used, it must be specified explicitly in the client.

If you use shared hosting, the service provider may have disabled SSH for your account, allowed only certain users, or restricted connections to a key configured through its own panel. In that case, instead of trying to change the server configuration file, check the SSH keys, access status, and connection details in the panel. On a provider-managed server, the provider’s web console, recovery console, or another authorized session provides a safe fallback point.

Separate the stage at which the connection fails

First, try connecting to the same target again with the same username and port information, and note the time of the error. A “connection timed out” or “connection refused” message occurs before authentication and requires you to examine the network path, firewall, incorrect port, or whether the SSH service is listening. “Permission denied” indicates that the server was reached, but the key or user information was not accepted.

If necessary, you can use the following diagnostic option in the terminal:

ssh -v username@server-address

Replace the username and server-address placeholders with your own information. This command displays details of the connection exchange in the local terminal; when sharing the output publicly, hide usernames, IP addresses, and key paths. For example, if the log remains at the “Connecting to...” stage, a network or port problem is more likely; if the key is rejected after “Offering public key,” an authentication problem is more likely. This output alone is not a definitive cause; it should be matched against the server logs.

Safe, sequential troubleshooting procedure for SSH access

1. Verify the target and port. Compare the server address and SSH port in the hosting panel with the values you are using in the client. If the connection succeeds when you retry with the correct port, the problem is not the network but the outdated port information. If the timeout continues, inspect the network filter or server access rule in the next step.
2. Check the SSH status in the provider panel. Check whether SSH is enabled for the account or server, which user is allowed, and whether an IP restriction exists. If the feature is disabled, use only the secure enablement option provided by the provider; preserve the permitted address scope instead of opening general access. If you changed this setting, record the previous value and try the connection again from the same device.
3. Match the server access logs by time. In the administrative panel’s SSH logs, system logs, or security records, look for the time of the attempt you just made. If there is no record at all, the request may not be reaching the server; investigate the port, external firewall, or source IP restriction. If the record shows a result such as “invalid user,” the target user is incorrect; select the correct account and review the existing authorization policy before creating a new account.
4. Check the authentication method. Verify that the key file is actually selected on the client, that the corresponding public key is assigned to the correct user on the server, and that it was saved in the format expected by the panel. If you see “Permission denied (publickey),” correct the key match instead of repeatedly trying the password. Password login may have been disabled by the provider; make key-based access work before changing the security policy.
5. Inspect the SSH service and listening status. If you have an authorized console, check the service status and configuration validation, and also verify whether the service is listening on the expected port. If the configuration shows a recent change, keep a backup or the previous value, correct only the relevant line, and make a single change. If configuration validation produces an error, correct the syntax first instead of restarting the service; the correct behavior depends on the distribution and provider management.
6. Verify the same operation with new evidence. After the change, establish the same SSH connection again with the same user, target, and port. Look for the time of the new attempt in the logs: a successful login record and a terminal that accepts commands indicate that the fix worked. If the error continues, do not change another setting at the same time; revert the last change and inspect the new, time-stamped record through the provider’s console.

Choose the right correction according to the symptom

For example, suppose a VDS administrator sees “connection refused” and finds no line in the server records for the time of the attempt. Changing the password or key is not the right first step. The administrator should first compare the port information in the panel with the external network rule; if a new attempt with the correct port appears in the records, the network path has been corrected. If no record is created, the provider-side access restriction should be investigated; only when a record shows that the request reached the server but was rejected should the administrator move on to the user or key settings.

In another situation, if the record clearly shows a failed public-key authentication for the correct user, changing the target port will not solve the problem. Compare the key offered by the client with the public key assigned to the same user on the server; if the keys do not match, correct only the relevant key through the panel or an authorized administration tool. Preserve the existing key before making the change, reconnect, and verify that the new record shows a successful login.

Safe fallback if the connection still cannot be established

If the symptom changed after a setting was modified, return to the previous value you recorded to isolate the effect of the last change. If there is no other authorized session, provider console, or fallback access to the server, randomly restarting services, completely disabling the firewall, or broadening permissions is not safe. If the new records show that the problem is with the provider’s network, account policy, or server service, send the provider the error time, target used, and message; do not send a private key, password, or access token.

Your first next step should be to note the SSH port, enabled status, and permitted-user information in the panel you use; then make a single connection attempt and check the record for the same time period. These three pieces of information distinguish, in most setups, whether the problem occurs before the request reaches the server or during authentication. If you would also like to review the VDS option, you can visit the Turkey VDS server plans page.