Why can't I connect to my server using SSH?

This guide helps diagnose common SSH connection problems with a BinaryLane Cloud Server.

If you are setting up SSH for the first time, see:

• How do I connect to my Cloud Server using my SSH key?
• Connecting to Linux with SSH
• SSH Keys: Connecting with PuTTY

First, identify the error

The error message helps narrow down the cause:

Check the server address and status

Confirm that you are using the correct public IP address or hostname, and that the server is powered on in mPanel.

If you use a hostname, try the public IP address directly. This rules out a DNS issue:

ssh username@YOUR_SERVER_IP

Check from another network

Try connecting from another independent internet connection, such as a mobile hotspot.

Corporate networks, public Wi-Fi, endpoint-security software and local firewalls can block outbound SSH traffic. If SSH works from another network, the issue is local to the original network or device.

For more detail from the SSH client, run:

ssh -vvv username@YOUR_SERVER_IP

Include the output in a support ticket if you need help.

Check the Cloud Firewall

If you have configured the VPS's Cloud Firewall in mPanel, make sure it allows SSH traffic to the server.

A rule allowing SSH commonly uses:

• Source: your public IP address, or 0.0.0.0/0 if SSH must be available from any IPv4 address
• Destination: Server Public Addresses
• Port: 22
• Protocol: TCP
• Action: Allow

If you use a final 'block all' rule, an SSH allow rule must appear before it. See Cloud Firewall for details.

Ingress and egress traffic within our networks remain completely unfiltered. We do not impose traffic filtering, shaping or rules beyond those customers configure through the Cloud Firewall for their VPS.

Check the server's own firewall and SSH service

If you can access the server through the mPanel console, check that the SSH service is running and listening on the expected port.

On Ubuntu or Debian:

sudo systemctl status ssh
sudo ss -ltnp | grep ':22'
sudo ufw status

If SSH is configured to use another port, use that port when connecting:

ssh -p PORT username@YOUR_SERVER_IP

The server's own firewall must allow the SSH port. Common firewall tools include UFW, firewalld, nftables and iptables.

If you receive 'Permission denied (publickey)'

This means the connection reached your server, but the supplied key was not accepted.

Check that:

• You are using the correct username. Many standard Linux installations use root, but custom images or cloud-init configurations may use another user.
• You are using the private key that matches the public key deployed to the server.
• You specify the required private-key file if it is not in the default location:
  
  

ssh -i /path/to/private_key username@YOUR_SERVER_IP

On Windows, the same command in PowerShell uses your user profile's .ssh folder:

ssh -i $HOME\.ssh\KEY_NAME root@YOUR_SERVER_IP

If you are unsure whether an SSH key was selected during deployment, review your keys at SSH Keys. A key with Default For Future Installations set to Yes is automatically pre-selected for new Cloud Server installations.

This setting does not add the key to servers that already exist. If the key was not selected when the server was deployed or rebuilt, it will not be installed automatically.

For setup guidance, see Set a default SSH key for all new Cloud Server installations.

Why is my root password refused over SSH?

On BinaryLane Linux images you log in as root. There is no separate sudo user on a standard image, so root is the account to use.

• Server deployed with an SSH key (including a key set as Default For Future Installations): the key is written to /root/.ssh/authorized_keys and SSH is set to PermitRootLogin without-password. Root must log in over SSH with that key. The root password emailed when the server was created is refused over SSH, even though it is correct.
• Server deployed without an SSH key: SSH is set to PermitRootLogin yes, so root can log in over SSH with the password.

This setting applies to SSH only. The root password still exists and still works on the Rescue Console on the server's Overview page in mPanel, so if you have lost the key you can still get in from the console. To allow root password logins over SSH, or to change other SSH settings, use a drop-in file as described in Why Your SSH Hardening Changes Aren't Working on BinaryLane. Edits made to /etc/ssh/sshd_config are overridden by /etc/ssh/sshd_config.d/10-binarylane.conf.

To remove an SSH key and go back to password logins, follow Remove an SSH key and re-enable password logins on an Ubuntu VPS.

Is the problem my computer or the server?

Use the Rescue Console to tell a problem with your own computer or network apart from a problem on the server:

1. In mPanel, open the server. The Rescue Console is on its Overview page.
2. Log in as root with the root password.
3. If the console login works, the server is running and the root account is fine. The problem is with SSH: the key, the server's SSH configuration or firewall, or your own computer or network. Check the key the server holds:

   cat /root/.ssh/authorized_keys
   ssh-keygen -lf /root/.ssh/authorized_keys

   and compare the fingerprint with your own key on your computer (ssh-keygen -lf followed by the path to your public key file).
4. If the root password is refused on the console too, reset it from the Recovery tab of the server in mPanel and try the console again. If you still cannot log in after the reset, the cause is inside the server, such as its SSH configuration or the account itself.

The Rescue Console is a recovery tool. Once you have fixed access, go back to connecting over SSH. See Where is the BinaryLane Rescue Console?

Using the Finnix Recovery CD

Check the Rescue Console first: in most root login problems the root password still works there, and no recovery CD is needed. If you do need to boot the Finnix Recovery CD (from Recovery > Rescue Disk in mPanel) to repair the disk or the root account, note that switching to Finnix restarts the server. Take a current backup before you make any changes to the disk or the root account.

If the connection still fails

Submit a support ticket with:

• The server's public IP address
• Your approximate location and internet provider
• Whether SSH works from another network
• The exact error message
• Output from ssh -vvv username@YOUR_SERVER_IP

Do not include private keys, passwords or other credentials.