Skip to main content

Diagnosing SSH errors and troubleshooting

This guide explains how to diagnose SSH connection issues for Linux instances and outlines the necessary checks and recovery procedures.

Prerequisites​

Before troubleshooting SSH access, confirm the following:

Check Default Username​

Each OS uses a different default SSH username. Verify it via Console or OpenAPI:

  1. Via Console: Click the [More] icon > SSH Connection. Check the "Default username" in the popup.
  2. Via OpenAPI: Use the Get instance API and check the instance.image.os_admin field.
OSDefault Username
Ubuntuubuntu
CentOScentos
Rocky Linuxrocky
Alma Linuxalmalinux
info

KakaoCloud supports key-based SSH login by default using port 22.

Check Security Group and Routing Table​

Ensure proper network connectivity to the Linux server:

  1. Via Console:
  2. Via OpenAPI:
    • List security groups: Check security_group.rules for SSH port access.
    • List route tables: Confirm destination is 0.0.0.0/0 and target_type is an internet/NAT gateway. Ensure is_local_route: true matches the subnet CIDR.

Check Linux Server Status​

  1. Via Console:
    • Verify the instance status is Active.
    • Go to [More] > System Log and confirm {Hostname} login: is present.
  2. Via OpenAPI:

SSH Error Messages​

Common SSH errors and their resolutions are listed below.

ssh: connect to host {server IP} port xx: No route to host​

Occurs when network settings are misconfigured via tools like systemd or Netplan.

   ssh -i {SSH key file} ubuntu@{Server IP} -v
   OpenSSH_9.0p1, Ubuntu-3ubuntu13.8, OpenSSL 3.0.13 30 Jan 2024
   debug1: Reading configuration data /etc/ssh/ssh_config
   debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
   debug1: /etc/ssh/ssh_config line 21: Applying options for *
   debug2: resolve_canonicalize: hostname '{Server IP}' is address
   debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' -> '/home/ubuntu/.ssh/known_hosts'
   debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' -> '/home/ubuntu/.ssh/known_hosts2'
   debug3: channel_clear_timeouts: clearing
   debug3: ssh_connect_direct: entering
   debug1: Connecting to '{Server IP}' ['{Server IP}'] port 22.
   debug3: set_sock_tos: set socket 3 IP_TOS 0x10
   debug1: connect to address '{Server IP}' port 22: No route to host
   ssh: connect to host {Server IP} port 22: No route to host

▶️ Resolution

  • Check network configuration daemons: Verify that no manual changes were made to network settings via systemd or Netplan. Disabling DHCP or altering network interfaces may prevent SSH connections.
    If the issue persists, refer to the Root Volume Check and Instance Recovery guide to restore access.

WARNING: UNPROTECTED PRIVATE KEY FILE!​

This error occurs when the SSH private key file has overly permissive permissions.

Example Error Message
ssh -i {SSH key file} ubuntu@{server IP} -v

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0666 for '{SSH key file}' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.

▶️ Resolution: Follow the steps below to update the file permissions for the SSH private key.

  1. Check the current permissions of the SSH key file.

    ls -al {SSH key file}

  2. Change the file permission so only the owner can read it.

    chmod 0400 {SSH key file}

Load key {SSH key file} : invalid format​

This error occurs when the SSH key file is in an incorrect format, corrupted, or improperly saved.

Example Error Message
ssh -i {SSH key file} ubuntu@{server IP} 
Load key "{SSH key file}": invalid format
{server IP}: Permission denied (publickey).

▶️ Resolution: Open the SSH key file and check its contents. A valid key should follow the format below.
If it does not match this format, verify that you are using a correct key.
If the file is corrupted or invalid, generate a new key pair and restore access.
For more details, refer to the Recover Lost Key Pair guide.

RSA SSH Key Format
vi {SSH key file}

-----BEGIN RSA PRIVATE KEY-----
<contents...>
-----END RSA PRIVATE KEY-----

Warning: Identity file {SSH key file} not accessible: No such file or directory.​

This error occurs when the specified SSH key file cannot be found.

Example Error Message
ssh -i {SSH key file} ubuntu@{server IP}
Warning: Identity file {SSH key file} not accessible: No such file or directory.
{server IP}: Permission denied (publickey).

▶️ Resolution: Make sure the SSH key file exists and that the directory it's stored in is accessible.

ls -al {SSH key file}

ssh: connect to host {server IP} port xx: Operation timed out​

This error occurs when the SSH connection attempt times out while trying to reach the server.

Example Error Message
ssh -i {SSH key file} ubuntu@{server IP} -v
OpenSSH_9.0p1, LibreSSL 3.3.6
debug1: Reading configuration data /Users/kakao_ent/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 21: include /etc/ssh/ssh_config.d/* matched no files
debug1: /etc/ssh/ssh_config line 54: Applying options for *
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug1: Connecting to '{server IP}' port 22.
debug1: connect to address '{server IP}' port 22: Operation timed out
ssh: connect to host {server IP} port 22: Operation timed out

▶️ Resolution

  • Check network connectivity: Ensure that the network connection from the source to the Linux server is properly established.
  • Verify security settings: Check that the security group allows SSH access and the routing table is correctly configured with no communication blockages.
  • Check instance status: Make sure the instance is in Active status in the Kakao Cloud Console.
  • Address SSH daemon issues: If the SSH daemon is not responding and direct access is unavailable, consider restarting the instance.
  • Check multi-network interface configuration: If using multiple network interfaces, first connect via a single interface and configure the routing table correctly.
  • If SSH access cannot be restored, refer to the Root Volume Check and Instance Recovery guide for additional recovery options.

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!​

This error indicates that the identification information (host key) for the server you previously connected to has changed.
It may signal a potential security threat, so you should verify the situation carefully. Common causes include:

  • Server's host key has changed: This can occur if the SSH server's host key was regenerated (e.g., after a reinstallation or reset).

    • SSH clients store the host key upon first connection and verify it on future connections.
    • If the server has been reset or reinstalled, a new host key may be generated, triggering this warning.

  • Possible Man-in-the-Middle (MITM) attack:

    • A malicious actor may be intercepting or modifying your SSH traffic, posing a serious security risk.
    • In such cases, the SSH client will alert you that the server’s fingerprint differs from what was previously recorded.
Example Error Message
ssh -i {SSH key file} ubuntu@{server IP}
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ED25519 key sent by the remote host is
SHA256:PtRMM9ps+sHDxMmgDlabcdefghaddfQQpylRabcdefg6bPI.
Please contact your system administrator.
Add correct host key in ~/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in ~/.ssh/known_hosts:25
Host key for {server IP} has changed and you have requested strict checking.
Host key verification failed.

▶️ Resolution: If you have confirmed that the host key change is expected and there are no security concerns, follow the steps below to resolve the issue.

  • Option 1: Remove the existing host key and reconnect

    Delete the old host key and try reconnecting via SSH:

    1. Open the ~/.ssh/known_hosts file on your SSH client.
    2. Locate and delete the line containing the host key entry for the target server.
    3. Reconnect to the server using SSH.
    ssh -i {SSH key file} ubuntu@{server IP}

  • Option 2: Use the -o StrictHostKeyChecking=no option

    Add the -o StrictHostKeyChecking=no option when connecting to the server to bypass the host key verification.

    ssh -i {SSH key file} -o StrictHostKeyChecking=no ubuntu@{server IP}

Permission denied (publickey,gssapi-keyex,gssapi-with-mic)​

This error can occur for various reasons, most commonly due to the following. However, other factors may also cause this error:

  • Using a different SSH key: You attempted to connect using an SSH key that is not registered with the instance.
  • Incorrect username: You used an invalid or incorrect username for SSH login.
  • Missing key specification: You tried to connect without specifying the required SSH key.
  • SSH key setup failure: The SSH key was not properly configured during instance creation.
Example Error Message
ssh -i {SSH key file} ubuntu@{server IP}

{server IP}: Permission denied (publickey).

▶️ Resolution: Identify the root cause of the error and take appropriate action based on the situation.

1. Verify the SSH key file:
Make sure you are using the correct SSH key file and that the file path and permissions are properly configured.

ssh -i {SSH key file} ubuntu@{server IP}

2. Verify the username:
Ensure that you are using the correct username configured for the instance (e.g., ubuntu, root), and that it is typed correctly.

3. Check if the key was specified:
Make sure the SSH command includes the -i option with the correct key file.

4. Validate SSH key injection via metadata server:
When creating an instance on Kakao Cloud, the instance retrieves the SSH key from the metadata server (169.254.169.254).
If access to the metadata server is blocked due to security group settings, the key may not be properly injected.
To prevent this, configure the security group as follows during instance creation:

  • Allow communication to the metadata server (169.254.169.254) using the rule below:
ProtocolSourcePort
HTTP0.0.0.0/0 (or an appropriate CIDR)80

Taking these steps can resolve most Permission denied errors.


ssh connect to host {server IP} port xx: Network is unreachable​

This error occurs when the destination host is unreachable or has no valid route. Common causes include:

  • Network configuration error: The system may be misconfigured — incorrect IP address, subnet mask, or routing table entries can cause this issue.
  • Incorrect gateway settings: The default gateway may not be set correctly or may not be connected to the network, leading to unreachable routes.
Example Error Message
ssh -i {SSH key file} ubuntu@{server IP}

ssh: connect to host {server IP} port 22: Network is unreachable

▶️ Resolution: Review your network configuration, gateway, and routing table settings by referring to the VPC documentation.

ssh: connect to host {server IP} port xx: Connection refused​

This error may occur even if the SSH daemon is running, typically when access to the custom SSH port is blocked or the daemon is not listening on that port.

▶️ Resolution: Refer to the Restore SSH Port guide to reset the SSH port to the default (22),
or register the custom port in SELinux policy and restart the SSH service to allow the connection.