SSH Troubleshooting - Supabyoi Docs

Common Errors

The table below lists the most frequent SSH errors, their likely causes, and recommended fixes.

Error	Cause	Fix
Authentication failed	Wrong SSH key	Verify the private key matches the public key on the server. Try `ssh -i your_key user@ip` locally first.
Could not reach SSH	Port blocked or SSH not running	Check cloud provider firewall allows port 22. Verify SSH service is running: `systemctl status sshd`
Connection timed out	Wrong IP or port blocked	Verify IP address. Check cloud provider firewall. Try `ping your-ip` to confirm reachability.
Connection refused	SSH not running or wrong port	Ensure SSH daemon is active. Check you are using the correct port.
No route to host	Server offline or wrong IP	Verify server is powered on and the IP address is correct in your cloud provider console.
Invalid SSH key format	Key not RSA or Ed25519	Generate a new key: `ssh-keygen -t ed25519`

Post-Hardening Access

After VM hardening, the SSH port and user are changed for security. The new port and user are displayed on the VM detail page inside Supabyoi.

If you need to connect manually via your terminal, use the displayed port and the supabyoi user:

ssh -i your_key -p NEW_PORT supabyoi@your-ip

Replace NEW_PORT with the port shown on your VM detail page and your-ip with your server's IP address.

Re-verification

You can use the Test Connection button on the VM detail page at any time to re-check SSH connectivity. This runs a live connection test from Supabyoi to your VM and reports any errors immediately, making it easy to confirm that access is restored after making firewall or configuration changes.

Cloud Provider Gotchas

Each cloud provider has its own firewall and networking model. Below are common pitfalls for the most popular providers.

AWS

Security Groups must have inbound rules for the SSH port. The default VPC may block custom ports after hardening. Update your Security Group inbound rules to allow the new SSH port from your IP or CIDR range.

DigitalOcean

Firewall rules are separate from the droplet itself. Navigate to Networking → Firewalls in the control panel and ensure the new SSH port is permitted in the inbound rules assigned to your droplet.

Hetzner

Hetzner Firewalls must explicitly allow the new SSH port after hardening. Go to your server's Firewall settings and add an inbound TCP rule for the updated port. Without this, connections will be silently dropped.

GCP

GCP uses VPC Firewall rules. Check both network-level and instance-level firewall rules. You may need to add a firewall rule that targets your instance by tag and allows TCP ingress on the new SSH port.

Still Having Issues?

If you have worked through the steps above and are still unable to connect, there are two good next steps:

Check the FAQ page for additional common questions and answers.
Reach out to support via supabyoi.com and include your error message, cloud provider, and any steps you have already tried.

When contacting support, it helps to include the output of the Test Connection diagnostic from the VM detail page.