Skip to main content

Linux Instance Connection Issues

This document explains SSH connection issues and solutions for Linux environments.

Prerequisite​

Before resolving SSH access issues on a Linux server, please check the following items.

Verify default username​

The default username for the instance is as follows and can also be checked from the console:

  • Path: KakaoCloud console > Virtual Machine > Instances tab > [More options] icon > SSH connection
OSDefault username
Ubuntuubuntu
CentOScentos
Rocky Linuxrocky
Alma Linuxalmalinux
info

KakaoCloud supports SSH key-based authentication by default, and SSH uses port 22.

Check security groups and routing tables​

  • Verify that the network connection between the source and the Linux server is functioning correctly.
  • Check if the connection is allowed in the security group associated with the instance, or verify the routing tables to ensure no communication issues exist.

Check the status of the Linux server​

Check if the Linux server is operating correctly:

  • In the KakaoCloud console, verify that the instance is in Active status.
  • Check the system logs of the instance to confirm the appearance of {Hostname} login:.
    • Path: KakaoCloud console > Virtual Machine > Instances tab > [More options] icon > Check system logs

SSH Error Messages​

The following are common error messages that can occur during SSH connection attempts, along with their solutions.

connect to host {Server IP} port 22: No Route to host​

This error may occur when the user has changed network settings, such as disabling DHCP, via network configuration daemons like Systemd or Netplan in a Linux environment.

ssh -i {SSH key file} ubuntu@'{HOST}' -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 '{HOST}' 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 '{HOST}' ['{HOST}'] port 22.
debug3: set_sock_tos: set socket 3 IP_TOS 0x10
debug1: connect to address '{HOST}' port 22: No route to host
ssh: connect to host '{HOST}' port 22: No route to host

▶️ Solution

  • Check network configuration daemon settings: Verify that no network settings, such as disabling DHCP, have been made in Systemd or Netplan. If any network changes are made, SSH access may fail. If you encounter an error message, ensure the settings are correct.

WARNING: UNPROTECTED PRIVATE KEY FILE!​

This error can occur if the SSH key file has been assigned too many permissions.

Key file permission issue
ssh -i {SSH key file} ubuntu@'{HOST}' -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.

▶️ Solution: Follow these steps to change the permissions of the SSH key file:

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

    ls -al {SSH key file}

  2. Change the permissions of the SSH key file so that 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 not in the correct format or if the file is corrupted or improperly saved.

ssh -i {SSH key file} ubuntu@{HOST}  
Load key "{SSH key file}": invalid format
{HOST}: Permission denied (publickey).

▶️ Solution: Open the SSH key file and check its contents. If the key file is valid, it should follow the format below. If it does not, check if the key is correct. If the key file is problematic, you will need to generate a new key pair. For more information, refer to the instance key pair recovery 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 SSH key file cannot be found.

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

▶️ Solution: Check if the SSH key file exists and verify if the directory where the key is stored is accessible.

ls -al {SSH key file}

ssh: connect to host {Host} port 22: Operation timed out​

This error occurs when a timeout happens while trying to connect to the server.

ssh -i {SSH key file} ubuntu@'{HOST}' -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 '{HOST}' port 22.
debug1: connect to address '{HOST}' port 22: Operation timed out
ssh: connect to host '{HOST}' port 22: Operation timed out

▶️ Solution

  • Check network connection status: Ensure the network from the source to the Linux server is functioning properly.
  • Check security settings: Verify if the connection is allowed in the security group and check for any issues in the routing table.
  • Check the instance status: Verify in the KakaoCloud console if the instance is in Active status.
  • Resolve SSH daemon issues: If the SSH daemon is problematic and access is impossible, consider rebooting the instance in case direct access is not available.
  • Verify multiple network interfaces setup: Before connecting multiple network interfaces, ensure SSH works with a single interface and adjust routing tables accordingly.

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!​

This error occurs when the SSH client detects a change in the server’s identification that was previously stored. This could imply a potential security threat, so it should be handled carefully. This error can occur in the following situations:

  • The server's HOST key has changed: This happens when the SSH server’s HOST key is modified. The HOST key is used to uniquely identify the server and ensure connection security.

    • The HOST key is stored when the SSH client first connects to the server, and the same key is used for future connections.
    • If the server is reset or reinstalled, a new HOST key is generated, which can cause this warning.

  • Possible man-in-the-middle attack: There may be a possibility of a man-in-the-middle attack.

    • This occurs when a malicious attacker intercepts or modifies network traffic, which can compromise the security of the SSH connection.
    • In such cases, the SSH client will warn that the server's identification does not match expectations.
    ssh -i {SSH key file} ubuntu@'{HOST}'
    @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
    @    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 {HOST} has changed and you have requested strict checking.
    Host key verification failed.

▶️ Solution: Verify the change of the server's HOST key, and if no security issues are found, you can resolve it using the following methods:

  • Solution 1: Delete the HOST key and reconnect

    Delete the HOST key and reconnect via SSH.

    1. Open the ~/.ssh/known_hosts file in the SSH client.
    2. Remove the registered HOST key for the source server and save it.
    3. Try to reconnect again.
    ssh -i {SSH key file} ubuntu@'{HOST}'

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

    Add the -o StrictHostKeyChecking=no option when connecting to the server each time.

    ssh -i {SSH key file} -o StrictHostKeyChecking=no ubuntu@'{HOST}'

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

This error can occur for various reasons, typically due to the following:

  • Using a different SSH key: Trying to connect with a different SSH key than the one registered for the instance.
  • Incorrect username: Trying to connect with an incorrect user account.
  • Key not specified: Trying to connect without specifying the required key.
  • SSH key setup error: The SSH key was not properly configured when the instance was created.
ssh -i {SSH key file} ubuntu@'{HOST}'

'{SSH key file} ubuntu@'{HOST}': Permission denied (publickey).

▶️ Solution: After identifying the cause of the error, follow the appropriate steps below:

  1. Check the SSH key file: Ensure that you are using the correct SSH key file and that the path and permissions of the key file are properly configured.

    ssh -i {SSH key file} ubuntu@{HOST}

  2. Check the username: Verify that the correct username for the instance (e.g., ubuntu or root) is used.

  3. Check if the key is specified: Verify that the key file is specified using the -i option in the SSH command.

  4. Check SSH key setup: When the instance is created, it communicates with the metadata server (169.254.169.254) to configure the SSH key. If communication with the metadata server is blocked by security group settings, the SSH key setup may fail. This can be resolved by configuring security group settings.

    • When creating the instance, ensure that communication with the metadata server (169.254.169.254) is allowed by setting the following rule in the security group:

      ProtocolSourcePort Number
      HTTP0.0.0.0/0 (or a valid range)80

    This action should resolve most of the Permission denied errors.

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

This error occurs when the destination host cannot be reached or there is no path to the host. This can happen due to the following reasons:

  • Network configuration errors: The system's network configuration may be incorrect, such as an incorrect IP address, subnet mask, or routing table setting.

  • Gateway setup errors: The gateway used to find the path to the destination host may not be properly configured, or the gateway may not be connected to the network.

    ssh -i {SSH key file} ubuntu@'{HOST}'

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

▶️ Solution: Refer to the VPC documentation to review the network configuration and check the gateway and routing table settings.