Ubuntu VPS SSH Troubleshooting: Diagnose Connection Errors

Capture one failure and preserve working access

Keep any successful SSH session open and locate the provider's recovery console. Client commands below run on your computer in Linux, macOS or WSL. Server commands run through existing access or the authenticated recovery console. Do not paste server commands into your local terminal.

Replace 203.0.113.10 with your server's address; it is reserved for documentation. Replace ubuntu, port 22 and the key path with the account, port and private-key filename you actually use. First print the evaluated client settings, then make one fresh connection attempt:

ssh -G -p 22 -i ~/.ssh/ubuntu_vps [email protected]
ssh -v -S none -o ConnectTimeout=10 -o StrictHostKeyChecking=ask -p 22 -i ~/.ssh/ubuntu_vps [email protected]

Inspect hostname, user, port, identityfile and any proxy settings. The second command disables connection sharing for this attempt. Record its time and final error. Verify any new host-key prompt using the host-identity section below. Redact usernames, addresses and paths before sharing debug output; never share a private key.

Choose the branch that matches the failure

Scroll sideways to see the full table →

These observations narrow the problem; they do not prove one cause. If the debug output already says Connection established before a timeout, investigate the SSH handshake and server logs rather than assuming all packets were blocked.

Timeout: trace the intended network path

Compare the destination shown by ssh -v with the current address in the provider panel. With a hostname, stale DNS or a different IPv6 destination can send the attempt elsewhere. Confirm whether this VPS requires a public address, VPN or jump host.

Check that the instance is running and its public routing is present. In the provider firewall, verify the actual SSH destination port and your current public source address. A home connection's address can change while a /32 allow rule stays unchanged. Check the guest firewall through the console as well.

On Oracle Cloud, security lists, NSGs, routing and the guest firewall all matter. Preserve the image's supplied firewall rules; installing UFW or flushing iptables is not a diagnostic step. The Oracle Ubuntu setup walkthrough explains that network layout. A failed ping alone does not prove SSH is unavailable.

Refused connection: inspect the listening service

A refusal does not authenticate the destination as your intended VPS. Confirm its identity and port, then run these read-only checks on the server through existing access or the recovery console:

systemctl status ssh.service ssh.socket --no-pager
sudo ss -lntp
sudo /usr/sbin/sshd -t
sudo journalctl -u ssh.service -u ssh.socket --since '15 minutes ago' --no-pager

Look for a listener on the intended port and address, and correlate logs with your attempt. Ubuntu can use socket activation: an inactive ssh.service alone does not prove SSH is unavailable when ssh.socket is listening.

sshd -t checks configuration and host-key validity without starting the daemon. Silent success does not prove network reachability. If it reports an error, identify that file or setting before considering a reload; do not restart blindly.

Rejected public key: check the account and offered identity

Use the provider's initial account or an administrator you created, not a guessed username. In client debug output, find which key fingerprint was offered. To reduce unrelated keys offered by an agent, retry locally with:

ssh -v -S none -o IdentitiesOnly=yes -o StrictHostKeyChecking=ask -p 22 -i ~/.ssh/ubuntu_vps [email protected]

Configured IdentityFile entries can still apply; inspect ssh -G. If the client reports an unreadable key or overly permissive private-key file, correct access to that local file before changing the server.

On the server, inspect the target account and its authorized public keys. This example assumes its home is /home/ubuntu; substitute the home returned by getent:

getent passwd ubuntu
sudo ls -ld /home/ubuntu /home/ubuntu/.ssh /home/ubuntu/.ssh/authorized_keys
sudo ssh-keygen -lf /home/ubuntu/.ssh/authorized_keys

Compare the authorized fingerprints with the offered one. Inspect the journal for ownership, permission or account-policy failures. Check configured AuthorizedKeysFile, included snippets and Match rules when the default path is not used. Provider-managed key services can also change the mechanism. Preserve existing authorized keys; do not disable StrictModes or enable passwords to hide the cause.

Changed host identity: verify before reconnecting

A rebuild or reassigned IP can change the host key, but an unexpected change can also indicate the wrong endpoint or an interception. Confirm the instance identifier and any planned rebuild through your authenticated provider panel.

Through trusted console access to the guest, inspect the public host key matching the algorithm shown by your client. For an Ed25519 host key:

sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub -E sha256

Compare its SHA256 fingerprint with the client warning. This is the server key, not your login key or the provider console gateway's key. A verified replacement may require updating that server's saved host entry; back up the file and preserve unrelated entries. Do not delete known_hosts wholesale or bypass checking. If identity remains unexplained, stop the connection and investigate.

Validate the specific correction in a fresh session

Correct the identified address, user, key, narrow network rule or configuration error. Preserve an independent access path during server changes and validate SSH configuration before applying them. A new port may also involve socket activation settings, not just a service restart.

Repeat the original attempt with connection sharing disabled. Confirm a fresh login reaches the expected account and that required sudo access works. An old session staying connected is not this test. Record what failed and what changed. Then return to the Ubuntu VPS deployment guide if setup was interrupted.

Questions and answers