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

Secure Shell (SSH) is the default and most secure way to access your Vultr Compute Instance. However, authentication failures like incorrect credentials, key mismatches, or permission issues can prevent access. This guide helps you diagnose and resolve SSH login problems in a systematic manner.

Use the Vultr Console for Immediate Access

If you're locked out of SSH, the View Console button in the Vultr Customer Portal is your backup access method.

1. Go to your instance information page.
2. Click View Console to open the web-based console.
3. Use the console to view startup logs or manually inspect SSH configurations.
4. You can reset your password or reconfigure broken SSH settings using this console.

Use Verbose SSH Logs to Identify the Issue

Verbose output provides deeper insights into where your SSH connection is failing:

ssh -vvv root@your-instance-ip

This will show connection attempts, authentication methods offered, key usage, and any rejection reasons.

Example output snippets and what they mean:

• Permission denied (publickey): No matching public key found on server.
• Too many authentication failures: Too many keys attempted; SSH client is blocked.
• No supported authentication methods: Password or key-based authentication is disabled.

Troubleshoot Based on Error Type

• Password Authentication Fails:

  Error Example:

  root@192.0.2.4's password:
  Permission denied (publickey,password)

  Possible Causes:

  • Wrong password.
  • SSH keys enabled, but password login is disabled (PasswordAuthentication no in sshd_config).
  • PermitRootLogin is disabled.

  How to Fix:

  1. Open the console and edit /etc/ssh/sshd_config.

  2. Locate the below parameters and make sure they look like below.

     ini Copy

     PermitRootLogin yes
     PasswordAuthentication yes
     

     Explain Code

  3. Restart the SSH service.

     console Copy

     # systemctl restart sshd
     

     Explain Code

• SSH Key Authentication Fails:

  Error Example:

  Permission denied (publickey)
  Disconnected: No supported authentication methods available (server sent: publickey)

  Common Causes:

  • Private key file is missing or unreadable on your client.
  • Public key not added to ~/.ssh/authorized_keys on the instance.
  • Wrong permissions on .ssh directory or key files.

  Fix File Permissions (from Console or Recovery Mode):

  console Copy

  $ sudo chmod 700 ~/.ssh
  $ sudo chmod 600 ~/.ssh/authorized_keys
  $ sudo chown -R youruser:youruser ~/.ssh
  

  Explain Code
  Note

  Always verify the private key on your local system and that it matches the public key on the server. You can extract the public key from a private key using:

  console Copy

  $ ssh-keygen -y -f ~/.ssh/id_rsa
  

  Explain Code

• SSH Login Loop or PAM Issues:

  Symptom:

  • Password accepted but console loops back to login.
  • Console prompts for password change but fails.

  Possible Causes:

  • Broken PAM (Pluggable Authentication Modules) configuration.
  • Damaged or missing files like /etc/passwd or /etc/shadow.

  Resolution:

  • Boot into SystemRescue ISO.
  • Use chroot to inspect and fix damaged authentication files or reset user passwords.

Consider Redeployment or Recovery

Sometimes, fixing SSH access is more time-consuming than rebuilding. Consider redeployment if:

• Critical files are corrupted.
• You’ve accidentally deleted system directories.
• PAM or init systems are broken beyond quick repair.

You can:

• Create a snapshot of the broken instance.
• Deploy a new instance from the snapshot.
• Restore critical files via mounted disks.

When to Contact Support

If you've tried all troubleshooting steps and still can't regain access, reach out to Vultr Support. Include:

• The instance IP.
• SSH username and method used (password or key).
• Full verbose SSH output (ssh -vvv).
• Any error logs from /var/log/auth.log or journalctl (if accessible).

This helps Vultr's support team pinpoint the root cause and accelerate resolution.

Preventive Best Practices

• Enable automatic backups or manual snapshots regularly.
• Use non-root users for login and disable root SSH access in production.
• Configure fail2ban or SSH rate-limiting to block brute-force attempts.
• Set up log rotation to avoid logs filling the disk and blocking SSH.