Ubuntu VPS SSH Troubleshooting

Run these in a local shell. ssh -V identifies the client; the file listing shows whether the selected private key exists and its permissions. Neither prints the private-key contents.

ssh -V
ssh_address='203.0.113.10'
ssh_user='ubuntu'
ssh_port='22'
ssh_key="$HOME/.ssh/ubuntu_vps"
ls -l "$ssh_key"
ssh -G -p "$ssh_port" -i "$ssh_key" "$ssh_user@$ssh_address"
date -u '+%Y-%m-%dT%H:%M:%SZ'
ssh -v -S none -o ConnectTimeout=10 -o StrictHostKeyChecking=ask -p "$ssh_port" -i "$ssh_key" "$ssh_user@$ssh_address"

Optional direct TCP check, if your client already has netcat:

nc -vz -w 5 "$ssh_address" "$ssh_port"

A successful TCP check only reaches a port. It does not verify SSH, the host identity or your login. For a jump-host route, this direct probe does not follow ProxyJump.

Use Windows OpenSSH Client. If Get-Command cannot find ssh, install the OpenSSH Client optional feature; a Windows SSH server is not needed to connect out. Run the following in PowerShell, not in the remote Ubuntu shell.

Get-Command ssh
ssh -V
$sshAddress = '203.0.113.10'
$sshUser = 'ubuntu'
$sshPort = 22
$sshKey = Join-Path $env:USERPROFILE '.ssh\ubuntu_vps'
Get-Item -LiteralPath $sshKey
Get-Acl -LiteralPath $sshKey | Format-List Owner,AccessToString
ssh -G -p $sshPort -i "$sshKey" "$sshUser@$sshAddress"
Test-NetConnection -ComputerName $sshAddress -Port $sshPort -InformationLevel Detailed
(Get-Date).ToUniversalTime().ToString('o')
ssh -v -S none -o ConnectTimeout=10 -o StrictHostKeyChecking=ask -p $sshPort -i "$sshKey" "$sshUser@$sshAddress"

Check RemoteAddress and TcpTestSucceeded. True means TCP connected on that direct path; it is not a host-key or authentication check. A missing file or ACL error is local to Windows. Review the exact private file’s ownership/access; do not paste Linux chmod commands into PowerShell.

If your working client is PuTTY, its .ppk key is a different format. Use PuTTYgen locally to export an OpenSSH private key to a new protected file when switching clients. Preserve the original and never upload either private-key file.

A name-resolution error happens before a direct TCP connection to the target. Correct a typo or missing SSH alias first. Inspect ssh -G: a Host block may select another username, key, port or ProxyJump, so “IP works” does not by itself prove broken DNS.

Compare the evaluated HostName and the actual address shown by debug output. If the hostname has both A and AAAA records, compare one ssh -4 and one ssh -6 attempt with the same account, port and key. IPv6 needs a working route, listener and rules of its own. With a jump host, name resolution and target connectivity can occur there; a local DNS check is not the complete path.

Next action: correct the one mismatched setting or stale record. Do not remove working IPv6 globally to conceal a different destination.

These messages concern the client’s local key. Verify the full quoted path, filename and file owner. A private key is different from the public key uploaded to the provider. Never paste the private key into this page or support messages.

On Linux/macOS/WSL, inspect the file owner and mode with ls -l. For an ordinary private file you own, mode 600 restricts access to its owner; apply a permission change only to that verified file. Windows uses file ACLs instead of Bash permissions. If the format is invalid, check whether the file is truncated, a public key, or a PuTTY PPK file requiring local export to OpenSSH format. Preserve the original; changing the extension does not convert it.

Next action: retry after the key can be read. Do not regenerate keys or change the server’s authorized keys merely to suppress a local read error.

The server ended the authentication attempts. An agent offering many unrelated keys is one possible cause, not a certainty. Inspect the offered fingerprints and use the existing-key attempt with IdentitiesOnly. Explicit IdentityFile entries can still add identities; inspect ssh -G as well.

With guest access: check the matching log entry and applicable MaxAuthTries policy. Avoid repeated retries or raising the limit before identifying the unwanted attempts.

A pre-authentication disconnect may come from the endpoint, a network intermediary or an admission rule. The text alone does not identify which. Capture the last debug lines and one timestamp. Confirm you are reaching SSH on the intended port, then correlate provider security events and the guest SSH journal if accessible.

If the error explicitly says no matching key-exchange, host-key or cipher algorithm, compare client/server versions and the applicable security policy. Prefer a supported compatible configuration. Do not universally enable obsolete algorithms. If logs instead identify a source block or connection limit, correct that specific condition; do not flush the firewall or disable protection globally.

An Authenticated to message places the failure after authentication. Server accepts key alone does not. First distinguish an interactive shell from SFTP, a remote command, port forwarding or ssh -N, which deliberately starts no remote command.

With guest access: inspect the matching session log and target account with getent passwd ubuntu (replace the username). Check its intended shell/home, applicable ForceCommand, PermitTTY and ChrootDirectory, and restrictions on the specific authorized key or certificate. A forwarding-channel failure needs its own forwarding/destination checks; it does not prove that login failed.

If the log reports a full filesystem, inode exhaustion or process/memory failure, inspect that resource with df -h, df -i, free -h and the relevant journal. These are observations, not proof of the cause. Fix the confirmed policy, path or resource condition without deleting data at random or removing deliberate account restrictions.

systemctl cat ssh.service ssh.socket --no-pager
systemctl show ssh.service -p ActiveState -p MainPID -p ExecStart -p FragmentPath -p DropInPaths -p NeedDaemonReload --no-pager
systemctl show ssh.socket -p ActiveState -p Listen -p FragmentPath -p DropInPaths -p NeedDaemonReload --no-pager
sudo ps -C sshd -o pid,ppid,args

cat shows unit files and drop-ins on disk. show reports the manager’s loaded properties, including socket Listen and the configured service launch. NeedDaemonReload=yes indicates a unit-file change since loading; it is an observation, not a reason to reload blindly. Use MainPID and the process list to distinguish the daemon from connection processes. No running daemon at that instant can be normal with socket activation.

Ubuntu’s socket behavior has changed across releases; Ubuntu 24.04 introduced a generator that reads Port and ListenAddress. Determine the actual mode and overrides on this machine. The distribution version or an edited Port line alone does not establish the current listener. Compare the loaded unit, any launch-time -f/-o/-p options and ss before planning a correction.

sshd -T prints the parsed effective configuration; -C supplies a connection context for applicable Match rules. This example uses the default configuration. If the actual launch selects another file or overrides settings, include those configuration options in the test too. Do not copy daemon-start flags such as -D into this inspection.

Replace all example values with what sshd sees: user is the target account; addr is the connecting source address (possibly a jump host/NAT); host is the resolved source hostname, not the VPS hostname; laddr and lport are the guest-side destination. Behind NAT, laddr can be private. When source-name lookup is not used, use the numeric source value; do not invent a reverse hostname.

check_user='ubuntu'
check_source='198.51.100.25'
check_source_name='198.51.100.25'
check_local='10.0.0.5'
check_port='22'
sudo /usr/sbin/sshd -T -C "user=$check_user,addr=$check_source,host=$check_source_name,laddr=$check_local,lport=$check_port"

Inspect PubkeyAuthentication, AuthenticationMethods, AuthorizedKeysFile/AuthorizedKeysCommand, AllowUsers/DenyUsers, group rules, ForceCommand and PermitTTY as relevant. Resolve relative authorized-key paths against the account’s actual home from getent passwd. Provider-managed key commands or certificate policy may replace the simple file-based route.

Ubuntu normally includes sshd_config.d snippets near the start of sshd_config. Many settings use the first obtained value, and conditional Match rules need the correct context. Adding a later duplicate line may not change the effective result. Review the applicable file/rule instead of disabling StrictModes or account restrictions.

The test reads configuration now; it cannot prove what a daemon loaded earlier, whether authentication will pass, or what systemd is currently listening on. Keep the listener and log checks separate.

Record the client attempt in UTC, check the guest clock, and replace both example endpoints below with a short window around that attempt:

date -u '+%Y-%m-%dT%H:%M:%SZ'
sudo journalctl -u ssh.service -u ssh.socket --since '2026-10-13 12:00:00 UTC' --until '2026-10-13 12:02:00 UTC' --utc -o short-iso-precise --no-pager

Match the time, source and account, then distinguish negotiation, authentication and session messages. If your service uses another unit or logging destination, inspect that configured destination. No entry can mean the request never arrived, but also different logging, insufficient permissions, clock mismatch or expired records; it does not prove a firewall cause.