After renting a VPS cloud server, some users find their system slowing down, getting infected with a virus, or crashing after a while, and they want to upgrade or reinstall the system. However, many users find they can't connect after reinstalling the system and excitedly opening their SSH tools to connect to the VPS! Even more frustrating is that the VPS clearly shows "Running" in the control panel, the IP address is the same, and the password is correct—yet they still can't connect! What's the problem? Don't rush to blame the VPS provider; the problem is very likely with your local VPS cloud server.
Why does reinstalling a VPS cloud server cause VPS connection failures? Three core reasons
Reason 1: SSH local key cache conflict—the most easily overlooked "invisible killer"
This is the most common culprit for VPS connection failures after system reinstallation, bar none. When you first connect to a VPS via SSH, your local computer automatically records the server's public key and saves it in the `~/.ssh/known_hosts` file. This mechanism is to prevent man-in-the-middle attacks—each time you connect, your local computer checks whether the public key returned by the server matches the previously recorded one. Here's the problem: When you reinstall your VPS system, the server generates a completely new host key. However, your local VPS cloud host retains the old system's host key. Since they don't match, the SSH connection will be rejected.
A typical error message looks like this:
WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!Or more directly:
Host key verification failed.
Many users are confused by this error—the password is correct, so why is it "verification failed"? The problem is that the locally cached key doesn't match the server's.
Reason Two: SSH Client Configuration Lost
Reinstalling the system means all your previously installed software is gone—including SSH clients (such as PuTTY, Xshell, Termius, etc.). After reinstalling, previously saved session configurations, port numbers, key pair paths, etc., are all reset to zero.
If you previously changed the default SSH port (e.g., from 22 to 2222) and forgot to configure it after reinstalling, the client will default to using port 22 to connect—while the server listens on port 2222—resulting in a connection failure.
Reason 3: Local firewall or network settings have changed.
A newly installed operating system may have different default firewall policies. Windows' built-in Defender firewall and third-party security software may both block outbound SSH (port 22) or RDP (port 3389) connections by default. Additionally, the IP address may change after reinstalling (especially if using DHCP to automatically obtain an IP address). While this doesn't affect internet access, it can affect routing paths in some network environments.
Solve step-by-step: Follow these steps, and the connection will be restored in 10 minutes.
Step 1: Clear the local SSH key cache (for "Host key verification failed")
This is the highest priority and most easily overlooked step.
Method 1 (Recommended): Open a terminal (CMD or PowerShell on Windows, Terminal on Mac/Linux) and execute the following command:
ssh-keygen -R your_server_IPFor example:
ssh-keygen -R 45.207.8.254This command will directly delete the old key record associated with that IP address in the `known_hosts` file. Reconnect after execution.
Method 2 (Brute Force but Effective): Directly delete the entire `known_hosts` file. The path on Windows is `C:\Users\your_username\.ssh\known_hosts`, and on Linux/Mac it's `~/.ssh/known_hosts`. After deletion, reconnect. The system will prompt you to accept the new host key—enter "yes". Note that deleting `known_hosts` will clear all server key records. If you are connecting to multiple servers, it is recommended to use Method 1 to precisely delete the records for the corresponding IP addresses.
Step 2: Confirm You're Connecting to the "Correct" Connection
After reinstalling the system, don't assume everything is the same as before. Verify the following items one by one:
Is the IP address correct? Go to the VPS control panel and recheck the public IP address—sometimes your service provider will assign a new IP after a reinstall.
Is the port correct? If you previously changed the SSH port (not the default 22), remember to specify it again in the client.
Are the username and password correct? After reinstalling the VPS system, the default username and password may have changed. Go to the control panel to confirm or reset the root password.
Step 3: Check Your Local Firewall
Temporarily disable your local firewall (Windows Defender firewall) and test—if you can connect after disabling it, the problem is with the firewall rules. Then add inbound rules in the firewall settings, allowing SSH (port 22) or RDP (port 3389).
Step 4: Use VNC/Console to "Take a Shortcut"
If you've tried all the above methods and still can't connect, don't force it. Most VPS providers offer a VNC console or web-based terminal – simply log in to the VPS control panel via a browser and access the server using VNC.
Once logged in, you can do two things:
Check if the SSH service is running: Execute `systemctl status sshd` (Linux). If it's not running, run `systemctl start sshd`.
Check if the firewall is blocking the SSH port: Execute `ufw status` or `iptables -L` to view the rules.
If you can access the console, use it first – confirm the SSH service is running, the port is correct, and the firewall is not blocking it. Don't immediately reinstall the system.
Prevention is better than cure: Do these three things before reinstalling:
Back up your SSH keys and configuration: Back up the entire `~/.ssh/` folder to a USB drive or cloud drive. After reinstalling, simply copy it back; all keys and known_hosts records will be preserved.
Record critical server information: Record the IP address, port, username, and password (or key path) in a secure location – don't try to memorize them. Using Session Management Tools: Tools like Xshell and Termius that support cloud-based session configuration synchronization allow you to restore all sessions after reinstalling and logging back into your account, saving you the hassle of reconfiguration.
Regarding the VPS itself: Choosing a reliable provider can save you a lot of trouble.
After troubleshooting local issues, if you still can't connect, it might be due to problems on the provider's end—such as node maintenance or network fluctuations. In this case, choosing a reliable VPS provider becomes crucial.
Jtti (full name JT TELECOM INTERNATIONAL PTE.LTD) is a global network infrastructure service provider registered in Singapore, primarily offering one-stop internet service solutions including cloud servers, server leasing, server hosting, and security technology development. Its core advantages lie in Hong Kong CN2 lines, optimized networks in Japan, US CN2 servers, high-bandwidth resources, and DDoS protected servers.
For websites targeting domestic visitors, cross-border e-commerce independent websites, and remote office systems, a high-quality network line is often more important than simply increasing CPU and memory. Jtti offers cloud servers in multiple regions including Hong Kong, Singapore, and the United States, supporting on-demand upgrades of CPU, memory, and bandwidth. Promotional prices typically include lifetime recurring discounts.
If you're looking for a VPS provider with stable lines, multi-node coverage, and prompt after-sales support, Jtti is a worthwhile option.
If your VPS is inaccessible after a reinstall, in most cases it's not that the VPS itself is "broken," but rather that your local VPS's cache, configuration, or firewall is causing problems. Follow the troubleshooting steps in this article: first, clear known_hosts; then, verify the IP address/port/password; next, check your local firewall; and finally, use the VNC console as a fallback—most problems can be resolved within 10 minutes.
Remember this: Reinstalling the system isn't scary; what's scary is forgetting what configuration changes you made afterward.
Develop the habit of recording server information and backing up SSH configurations; this will ensure a truly "seamless" transition next time you reinstall.
