Read the SSH error
A refusal means a TCP connection was rejected; a timeout means no successful response arrived; Permission denied reached SSH authentication. Start with the exact error.
A refusal can come from a rejecting device on the path or from no listener at the destination; it does not prove sshd replied. A timeout means the exchange did not complete. Permission denied reaches SSH authentication, so check login details before network firewall rules.
This guide assumes you are authorised to administer the guest operating system. The console, firewall, SSH service and recovery options available to a Novasean customer depend on the actual VPS and managed-service agreement. Do not assume root login, port 22, a Linux distribution or a panel feature is included.
Preserve an alternative access route
Before any change to SSH, collect the assigned public IP or hostname, expected SSH port and username from your service record. Check whether the VPS is running in its service panel. If a console is available, verify that you can access it before touching network or SSH settings; the console is a recovery path if remote access fails. For a managed guest, ask the operator who owns SSH configuration and firewall changes under the agreement.
From your own machine, record the exact command and error, for example ssh -v -p PORT user@HOST, substituting the actual values. Never post the private key or full verbose output without checking for sensitive data. Try from a second network only to distinguish a local-network restriction from a server-side problem.
Check the transport path
For a refusal, confirm the IP and port, then use an authorised console to check whether the SSH service is running and listening on the expected address and port. On Ubuntu, OpenSSH is managed as a service; other distributions differ. A firewall reject can also produce an immediate refusal. Compare guest firewall rules and any provider-side network policy without disabling them wholesale.
For a timeout, check that the VPS is powered on, the intended address is assigned, the route is available and the relevant firewall policies allow the specific source and port. A provider incident, guest routing fault or resource exhaustion can also block access. If the console works but network SSH does not, collect guest interface, route, service and firewall observations for the responsible operator. If the console also fails, escalate platform access rather than guessing at guest rules.
For “Permission denied”, inspect the specified user, key selection, server-authorised keys and account status using an existing safe access path. Do not enable password or root login merely to make a test pass.
Illustrative branch: a fast refusal on the configured port with a responsive console calls for a listener and reject-rule check; a timeout with no console access needs panel and provider-path evidence.
A refusal may come from a firewall or intermediary, so do not report the SSH daemon as stopped without a console or service check.
Make the smallest authorised correction
If a service has stopped and you administer the guest, inspect its logs and configuration before restarting it. Validate configuration syntax with the distribution’s documented method before applying a change. If a firewall rule is wrong, add or correct a narrowly scoped rule for the actual SSH port and trusted source using a console session, then test a second SSH session before closing the first. Never flush all firewall rules, expose SSH to every source by default, or close the only console session before verifying remote access.
If the expected IP or port in your connection details is wrong, correct the client command. If the guest’s network settings are inconsistent with the assigned service, ask the provider to reconcile them. A managed service may require the operator to perform the change; customer possession of a control panel does not automatically grant authority to alter managed controls.
Verify both access and security
Connect successfully from the intended network using the intended account and key. Confirm that the server identity or host-key change is expected before accepting it; an unexpected host key after a rebuild deserves investigation. Review the relevant auth and firewall logs for the test time. Make sure the original recovery console remains reachable, then document the actual port, source restriction and owner of future changes.
If access still fails, restore the last known safe setting via the console where possible. Provide support the time, public target, observed refusal or timeout, source network, console availability and sanitised SSH diagnostic output. Keep private keys and account passwords out of tickets.
Common questions
Does refusal always mean SSH is down? No. A firewall or intermediary can actively reject the connection.
Does timeout mean the password is wrong? No. Authentication has not necessarily begun.
Should I switch to port 22? Use the port actually configured for your service; a guessed default is not a repair.
Sources and technical references
Related guides
Was this guide helpful?
If you accepted optional analytics, your Yes/No answer and this guide’s page address are sent to Google Analytics. No written feedback is collected. Read our privacy statement or change your choice in .
Need help with your service?
Open your client area or contact Novasean. Describe the symptom and checks you have performed. Keep passwords, recovery codes and private keys out of your message.