Vultr DocsLatest Content

Associated Doc

How to Troubleshoot SSH Connectivity Issues on a Vultr Compute Instance?

Updated on 15 September, 2025

A troubleshooting guide for diagnosing and resolving SSH connection problems on Vultr Compute Instances.


SSH is the primary method to access and manage your Vultr Compute Instance. If SSH fails, it can be difficult to determine the root cause because even minor misconfigurations can block access. This guide helps you diagnose and resolve common SSH connectivity problems, including authentication failures, port blocks, and service errors.

When to Troubleshoot vs. Redeploy

Before diving into troubleshooting, consider whether it's more efficient to restore from a backup or redeploy the instance entirely. Scenarios that may warrant recovery instead of debugging include:

  • Accidental chmod or rm commands that render the system unusable.
  • Corrupted file systems or boot failures.
  • Misconfigured firewalls or network services that block all external access.

If your instance has a backup or snapshot, it may be faster to redeploy from that instead of repairing the existing setup. You can also mount the volume on a new instance to recover data.

Pre-Troubleshooting Checklist

Before troubleshooting SSH directly, complete the following checks:

  1. Log in to the Vultr Customer Portal and ensure.

    • The instance is Running.
    • There are no reported network outages.
    • The firewall is not blocking port 22 (default SSH port).
  2. If you've lost access to the instance, verify the root password shown on the instance Overview tab. If that doesn't work and password login is enabled, reset the password using the recovery ISO. See password reset instructions.

  3. If your SSH access is broken, use the Vultr View Console option from the portal to access the instance directly, even if networking is down.

  4. Use the Server Restart option from the instance's Overview tab in the Vultr Customer Portal. Rebooting the server can often resolve basic SSH or networking issues caused by temporary misconfigurations or service failures.

Diagnose SSH Connection Failures

Depending on what type of error your SSH client displays, refer to the following categories:

  1. DNS or Hostname Resolution Errors:

    Symptom:

    ssh: Could not resolve hostname myvultrserver.com: Name or service not known

    Fix:

    • Verify you're using the correct hostname or IP.

    • Use the IP directly if DNS is unreliable.

    • Test DNS resolution locally:

      console
      $ ping myvultrserver.com
      

      If resolution fails, the issue might lie with your local DNS resolver. Check your system's network settings or switch to a different DNS provider (e.g., Google DNS 8.8.8.8).

  2. Connection Timeout:

    Symptom:

    ssh: connect to host 192.0.2.123 port 22: Connection timed out

    Fix:

    • Check that your local network or ISP isn't blocking port 22.
    • On public Wi-Fi or office networks, try using mobile tethering to test.
    • Ensure Vultr firewall group rules allow incoming TCP traffic on port 22.
  3. Connection Refused:

    Symptom:

    ssh: connect to host 192.0.2.123 port 22: Connection refused

    Fix:

    1. Use the View Console option in the Vultr Customer Portal to log in to your instance directly.

    2. Check if the SSH service is active.

      console
      $ sudo systemctl status sshd
      

      If it's not listed as active (running), then restart the SSH service:

      console
      $ sudo systemctl restart sshd
      
    3. Verify the SSH port configuration.

      console
      $ sudo grep ^Port /etc/ssh/sshd_config
      

      The default port is 22. If you've customized the port, ensure your SSH client is configured to use that port (e.g., ssh -p <custom-port>).

Conclusion

SSH access issues can stem from a variety of causes—from simple firewall blocks to incorrect authentication methods. If you've followed the steps above and still can't connect:

  • Consider restoring from a snapshot if the system is unrecoverable.
  • Open a support ticket with detailed output from your SSH attempts.