Troubleshoot connection to cloud instances
Use this article if you followed the steps to connect to your cloud instance via SSH, but the connection failed.
Start by checking the error message shown in your terminal. The error message usually points to the most likely cause, such as a blocked connection, incorrect username, incorrect private key, or unreachable IP address.
Note: This article applies to Linux public images in xneelo Cloud. Custom images, ISOs and Windows instances may use different login steps.Â
-
Quick checks
Before troubleshooting further, confirm the following:
- The instance status is Active
- The instance power state is Running
- You are using the correct public IP address or Floating IP
- You are not trying to connect to a private IP address from the internet
- The security group allows inbound SSH traffic on port 22
- Your current IP address is allowed if the rule is restricted
- The correct default username is used for the instance image
- The correct private key is used
- The private key file has the correct permissions
If these checks are correct and you still cannot connect, continue with the steps below.
-
Common error messages
The table below lists common SSH error messages, the likely cause, and what to check first
Follow the troubleshooting sections below to resolve these issues.
Error Message Likely cause
Suggested Action Connection timed out SSH traffic cannot reach the instance Check IP address, security group rules, network setup and firewalls Connection refused The instance was reached, but SSH is not accepting the connection Check instance status, SSH service and OS firewall Permission denied (publickey) Incorrect username or private key Check the default username and private key No supported authentication methods available SSH authentication failed Check the default username and private key Server refused our key SSH key authentication failed Check that the private key matches the instance User key not recognised by server Incorrect private key used Check that the private key matches the key pair assigned to the instance Please log in as the user “X” rather than the user “Y” Incorrect username used Use the default username for the instance image Permissions are too open Private key file permissions are too permissive Set restricted permissions on the private key file Unprotected private key file Private key file permissions are too permissive Set restricted permissions on the private key file Unable to load key Private key format or file path is incorrect Check the private key file path and format Private key must begin with… Private key is not in a valid format Check the private key format
Host key verification failed The stored host key no longer matches the instance Remove the old entry from known_hosts
Network is unreachable Incorrect IP address, unsupported IPv6 or network issue Check the IP address and try IPv4 if needed
-
Connection timed out
A timeout usually means your SSH request cannot reach the instance.
Check the following:
- The instance is Active and Running
- You are using a public IP address or Floating IP
- You are not using a private IP address from outside the private network
- The security group allows inbound TCP traffic on port 22
- Your current IP address is allowed, if the security group rule is restricted to a specific source
- If you are using IPv6, try the IPv4 address instead
- A firewall inside the instance, such as ufw, firewalld or iptables, is not blocking SSH
If the instance only has a private IP address, you cannot connect to it directly from the internet. The instance needs either a public network interface or a Floating IP setup.
-
Connection refused
A refused connection usually means the instance was reached, but SSH is not accepting the connection.
Check the following:
- The instance has finished booting
- The instance status is Active
- YThe instance power state is Running
- The SSH service is installed and running inside the instance
- SSH is listening on port 22
- A firewall inside the instance is not blocking port 22
- Recent OS updates or configuration changes have not disabled SSH
These checks are inside the operating system and are part of your self-managed server configuration.
-
Check the SSH command
Ensure the SSH command used to connect is correct:
ssh -i /path/privatekey.pem username@ip-addressExample:
ssh -i ~/.ssh/mykey.pem ubuntu@154.65.100.23Check that:
- /path/privatekey.pem is the full path to the private key file on your computer
- The file type, usually .pem, is included
- username matches the default username for the instance image
- ip-address matches the public IP address or Floating IP for the instance
SSH uses port 22 by default, so specifying -p22 is not usually required.
-
Check the default username
A connection error can occur if the incorrect username is used.
When connecting for the first time, you must log in using the default username for the instance image.
These are the default usernames for the xneelo Cloud public images.
OS Name Default username AlmaLinux almalinux CentOS cloud-user Debian debian Ubuntu ubuntu The default username is not usually root. Do not use root unless you have configured root login yourself.
If you are using a different operating system image, custom image or ISO, the default username may differ.
-
Check the private key
The private key used to connect must match the key pair assigned to the instance when it was created.
Common problems include:
- Selecting the wrong private key file
- Using a key from another instance
- Using a key that does not match the public key on the instance
- Using a key file that is corrupted or incomplete
- Using the wrong file path in your SSH command
xneelo does not store your private key and cannot recover or resend it if it is lost.
If you have lost the private key, see Recover instance access after losing the private key.
-
Check the private key format
SSH keys used with xneelo Cloud are typically stored in .pem format.
The private key file should begin with a line similar to:
-----BEGIN RSA PRIVATE KEY-----If the key does not follow this format, it may not work with SSH.
If you are connecting using PuTTY on Windows, the private key must be converted to .ppk format using PuTTYgen.
-
Check private key permissions
SSH requires private keys to have restricted permissions to ensure only the current user can read the key file.
If permissions are too open, SSH will reject the key.
Follow the steps to set permissions on the private key file.
-
Lost private key
If you have lost the private key used to access your instance, SSH access will not be possible with that key.
Creating, deleting or renaming a key pair in the Cloud dashboard does not automatically update the public key already stored inside an existing instance.
To use a new key for an existing instance, you must add the new public key to the instance’s authorized_keys file.
See how to recover instance access after losing the private key.
-
Check the instance IP address
Verify that the IP address used in your SSH command matches the instance public IP address.
You can find the IP address in: Compute > Instances.
Both IPv4 and IPv6 addresses may be available.
If you are using IPv6 and cannot connect, try the IPv4 address instead. Some Internet Service Providers (ISPs) do not support IPv6 connectivity.
-
Check the IP address is public
Private IP addresses cannot be reached directly from the internet.
To connect from the internet the instance requires a public IP address. Either:
- It has an interface connected to the public network
- It has a floating IP associated with the instance or port
If your instance only has a private IP address, you need a public network interface or a floating IP setup before you can connect from outside the private network.
-
Check security group rules
Security groups control which network traffic is allowed to reach your instance.
To connect via SSH, the instance must allow inbound traffic on port 22.
The default security group already includes a rule allowing SSH access.
If your instance is using a custom security group, ensure it includes a rule allowing:
- Protocol: TCP
- Port: 22
- Direction: Ingress
If the rule restricts traffic to a specific IP address or range, ensure your current IP address is allowed.
-
Security group is correct, but SSH still fails
Security groups control platform-level access to your instance. They do not replace the firewall or SSH configuration inside the operating system.
If the security group allows port 22 but SSH still fails, check the instance itself:
- OS firewall rules, such as ufw, firewalld or iptables
- SSH service status
- SSH port configuration
- Recent network or firewall changes inside the instance
- Disk full or failed boot issues shown in the console log
These checks are part of your self-managed operating system configuration.
-
Console asks for a password
The instance console is not the same as SSH.
Xneelo Cloud public Linux images do not have a default password. If the console asks for a password, you can only log in if you previously set a password during instance creation or from inside the instance.
If you did not set a password and have lost SSH access, see Recover instance access after losing the private key.
-
Host key verification failed
This can occur if the instance was rebuilt or its SSH host key changed.
SSH stores known hosts in the following file:
~/.ssh/known_hostsYou can remove the entry for the instance from this file and attempt to connect again.
The error message you received should display the line number corresponding to the host instance (IP address will be displayed). You will need to remove this line from the known-hosts text file.
You can either remove this from the file manually, or via command line. In this example, the offending line is line 76.
sed -i '76d' ~/.ssh/known_hosts
-
Check the instance status or reboot
Your instance must be running before it can accept SSH connections.Steps
-
1Navigate to Compute → Instances.
-
2Locate your instance in the table.
-
3Confirm:
- Status: Active
- Power State: Running
If the instance is stopped, start the instance.
If the instance is running but not responding, a reboot may help. Rebooting an instance can interrupt running services, so only do this if it is safe for your workload.
-
-
Check the instance console log
If the instance is running but still unreachable, check the console log.
The console log displays system messages generated during instance startup.
These logs may reveal issues such as:
- Network configuration errors
- Missing network interfaces
- Cloud-init failures
- Disk or filesystem errors
- Boot errors
- Services failing to start
Review the console output for error messages that may explain why the instance cannot accept connections.
By default, the last 35 lines of the console’s output will be displayed. You may need to view the full log to find the error.
Look for errors related to:
- eth
- ens
- cloud-init
- ssh
- disk or filesystem failures
-
Consider recent changes
If an instance was previously accessible but is now unreachable, consider recent changes that may have caused the issue.Examples include:
- Changing security group rules
- Adding or changing OS firewall rules
- Modifying network configuration
- Performing system upgrades
- Editing SSH configuration
- Changing users or permissions
- Rebooting after an update
- Resizing or changing storage
- Running out of disk space
Reverting recent changes may restore connectivity.
-
When to contact support
If you have tried the troubleshooting steps above, you can contact to support to see if there is another issue.Â
Xneelo Cloud is a self-managed product.
You remain responsible for configuration inside the instance, including OS firewall rules, SSH service configuration, users, passwords, application services and custom network configuration.Â
Support can help check platform-side items such as the instance status, power state, IP address, security group rules, project access and Cloud dashboard access.
Do not share your private key or root password with support.Â
You can read more about our scope of support in xneelo Cloud.





