SSH Connection Errors

If you encounter issues connecting to a server, perform diagnostics. After performing diagnostics, you can resolve some frequently occurring errors yourself.

Identify a connection issue

If connection errors occur when connecting via SSH or if you need to check which key is used for authentication, start the connection in debug mode:

ssh -vvv <username>@<ip_address>

Specify:

• -vvv — a flag to enable debug mode, which allows you to trace the entire SSH connection setup process;
• <username> — a username (login). You can view it in the control panel: in the top menu, click Products → Dedicated Servers → Servers → server page → Operating System tab → Login field;
• <ip_address> — public IP address of the server. You can view it in the control panel: in the top menu, click Products → Dedicated Servers → Servers → server page → Operating System tab → IP.

Information about the SSH connection process and any occurring connection issues will appear in the response.

Connection issues

Error	Reason	Solution
Connection timed out	Connection timed out	check node network availability and measure latency; scan ports
Warning: Identity file /home/user/.ssh/authorized_keys not accessible: No such file or directory	The client private key is missing or inaccessible	check for a private SSH key on the local computer; configure access rights to the private key on the client
Permission denied (publickey)	Server rejected the connection	check for a public SSH key on the server; configure access rights; check the SSH configuration on the server
ssh: connect to host 203.0.113.10 port 22: Connection refused	Port 22 is not accepting connections	check the SSH service status; check the SSH port; check the firewall settings; scan ports; check basic firewall rules

Check for the SSH key file

Check the public key on the server

1. Load the server in recovery and diagnostic mode.

2. Connect to the server via the KVM console.

3. Check for the .ssh directory and the authorized_keys file:

   ls -la ~/.ssh/

   Information about the files in the .ssh directory will appear in the response. For example:

   drwx------ 2  user user 4096 Jul 16 10:15 .
   drwxr-x--- 18 user user 4096 Jul 16 09:50 ..
   -rw------- 1  user user  743 Jul 16 10:10 authorized_keys

   Here, authorized_keys is a file containing public SSH keys that are allowed to connect to the server.

4. Display the contents of the authorized_keys file:

   cat ~/.ssh/authorized_keys

   One or more public SSH keys will appear in the response. For example:

   ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIP... user@example
   ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC... admin@example

   Ensure that the SSH key corresponds to the private key used on the client.

5. If the .ssh directory or authorized_keys file does not exist, or the requested public key is not in the file, place the SSH key on the server.

Check the private key on the local computer

Linux/macOS

1. Open the CLI on your local computer.

2. Check for SSH keys:

   ls -la ~/.ssh/

   Information about SSH keys will appear in the response. For example:

   drwx------  2 user user 4096 Jul 16 10:15 .
   drwxr-x--- 18 user user 4096 Jul 16 09:50 ..
   -rw-------  1 user user  411 Jul 16 10:10 id_ed25519
   -rw-------  1 user user 3389 Jul 10 14:22 id_rsa
   -rw-------  1 user user  978 Jul 15 18:00 known_hosts
   -rw-r--r--  1 user user  142 Jul 12 11:30 config

   Here, id_rsa and id_ed25519 are private SSH keys.

3. If the private key file is missing, create and place an SSH key on the server.

Windows

1. Open PowerShell on your local computer.

2. Check for SSH keys:

   ls $HOME\.ssh

   Information about SSH keys will appear in the response. For example:

       Directory: C:\Users\User\.ssh
   
   Mode                 LastWriteTime         Length Name
   ----                 -------------         ------ ----
   -a----        16.07.2025     10:10            411 id_ed25519
   -a----        10.07.2025     14:22           3389 id_rsa
   -a----        15.07.2025     18:00            978 known_hosts
   -a----        12.07.2025     11:30            142 config

   Here, id_rsa and id_ed25519 are private SSH keys.

3. If the private SSH key file is missing, create and place an SSH key on the server.

Configure access rights

On a dedicated server

The SSH server strictly checks user rights for the ~/.ssh directory and the ~/.ssh/authorized_keys file. If the rights are too open, the SSH connection cannot use the keys, even if they are specified correctly.

1. Load the server in recovery and diagnostic mode.

2. Connect to the server via the KVM console.

3. Check rights for the ~/.ssh directory:

   ls -ld ~/.ssh

   Information about rights for the ~/.ssh directory will appear in the response. For example:

   drwx------ 2 username username 4096 Oct 24 10:00 /home/user/.ssh

   Where:

   • drwx------ — object type and the rights systems users have for it, where:

     • d — object type: directory;
     • rwx — owner rights: read, create, and delete files in the directory, access to the directory;
     • --- — no group rights. Group members cannot read, write to, or enter the directory;
     • --- — no rights for other system users;

   • the first username value — user with owner rights;

   • the second username value — user group. Usually the same as the username.

   The rights for the ~/.ssh directory correspond to the 700 code: read, create, and delete files in the directory, access to the directory.

4. If the rights for the ~/.ssh directory differ in step 3, set the correct rights:

   chmod 700 ~/.ssh

   Where:

   • 7 — owner rights: read, create, and delete files in the directory, access to the directory;
   • 0 — no group rights;
   • 0 — no rights for other system users.

   If successful, the command will not display any output.

5. If the owner of the ~/.ssh directory is incorrect, change it:

   sudo chown -R <username>:<user_group> ~/.ssh

   Specify:

   • <username> — name of the user you connect to the server with via SSH;
   • <user_group> — user group, usually the same as the username. You can view it using the id <username> command, where <username> is the username.

6. Check rights for the ~/.ssh/authorized_keys file:

   ls -l ~/.ssh/authorized_keys

   Information about rights for the ~/.ssh/authorized_keys file will appear in the response. For example:

   -rw------- 1 username username  234 Oct 24 10:00 /home/username/.ssh/authorized_keys

   Where:

   • -rw- — object type and the rights systems users have for it, where:

     • - — ~/.ssh/authorized_keys object type: regular file;
     • rw- — owner rights: read and write;
     • --- — no group rights;
     • --- — no rights for other system users;

   • the first username value — user with owner rights;

   • the second username value — user group. Usually the same as the username.

   The rights for the ~/.ssh/authorized_keys file correspond to the 600 code: read and write.

7. If rights for the ~/.ssh/authorized_keys file differ in step 6, set the correct rights:

   sudo chmod 600 ~/.ssh/authorized_keys

   Where:

   • 6 — owner rights: read and write;
   • 0 — no group rights;
   • 0 — no rights for other system users.

   If successful, the command will not display any output.

On a local computer

On the device from which you connect to the dedicated server via SSH, the private key must be accessible only to the current user. If the access rights are too open, the SSH connection cannot use the key.

Linux/macOS

1. Open the CLI on your local computer.

2. Check rights for the .ssh directory:

   ls -ld ~/.ssh

   Information about rights for the .ssh directory will appear in the response. For example:

   drwx------ 2 username username 4096 Oct 24 10:00 /home/user/.ssh

   Where:

   • drwx------ — object type and the rights systems users have for it, where:

     • d — object type: directory;
     • rwx — owner rights: read, create, and delete files in the directory, access to the directory;
     • --- — no group rights. Group members cannot read, write to, or enter the directory;
     • --- — no rights for other system users;

   • the first username value — user with owner rights;

   • the second username value — user group. Usually the same as the username.

   The rights for the ~/.ssh directory correspond to the 700 code: read, create, and delete files in the directory, access to the directory.

3. If rights for the ~/.ssh directory differ in step 2, set the correct rights:

   chmod 700 ~/.ssh

   Where:

   • 7 — owner rights: read, create, and delete files in the directory, access to the directory;
   • 0 — no group rights;
   • 0 — no rights for other system users.

   If successful, the command will not display any output.

4. Check rights for the ~/.ssh/id_rsa file:

   ls -l ~/.ssh/id_rsa

   Information about current rights for the ~/.ssh/id_rsa file will appear in the response. For example:

   -rw-r--r-- 1 username username 2602 Jan 10 12:34 /home/user/.ssh/id_rsa

   Where:

   • -rw-r--r-- — object type and the rights systems users have for it, where:

     • - — ~/.ssh/id_rsa object type: regular file;
     • rw- — owner rights: read and write;
     • r-- — group rights: read;
     • r-- — rights of other system users: read.

   • the first username value — user with owner rights;

   • the second username value — user group. Usually the same as the username, but this may vary.

   The rights for the ~/.ssh/id_rsa file correspond to the 600 code: read and write.

5. If rights for the ~/.ssh/id_rsa file differ in step 4, set the correct rights:

   chmod 600 ~/.ssh/id_rsa

   Where:

   • 6 — owner rights: read and write;
   • 0 — no group rights;
   • 0 — no rights for other system users.

   If successful, the command will not display any output.

Windows

On Windows, SSH checks NTFS rights. The private key must be accessible only to the user under whose name you are connecting. If the rights include access for other users, OpenSSH may refuse to use the key.

1. Open PowerShell on your local computer as the user you connect to the dedicated server with via SSH.

2. Check rights for the .ssh directory:

   icacls $env:USERPROFILE\.ssh

   Information about rights for the .ssh directory will appear in the response. For example:

   C:\Users\User\.ssh
     NT AUTHORITY\SYSTEM:(OI)(CI)(F)
     BUILTIN\Administrators:(OI)(CI)(F)
     User:(OI)(CI)(F)
     BUILTIN\Users:(OI)(CI)(R)

   Where:

   • (F) — full access;
   • (OI) — object inherit, rights to files in the folder are inherited;
   • (CI) — container inherit, rights to nested folders are inherited;
   • (R) — read access.

3. Assign rights for the .ssh directory to the current user only:

   3.1. Remove permission inheritance for the directory:

   icacls $env:USERPROFILE\.ssh /inheritance:r

   3.2. Assign rights for the directory only to the current user:

   icacls $env:USERPROFILE\.ssh /grant:r "$env:USERNAME:(OI)(CI)F"

4. Check current rights for the .ssh directory:

   icacls $env:USERPROFILE\.ssh

   Information about rights for the .ssh directory will appear in the response. For example:

   C:\Users\User\.ssh
     User:(OI)(CI)(F)

   Here, rights for the .ssh directory are held only by the User.

5. Check current rights for the id_rsa file:

   icacls $env:USERPROFILE\.ssh\id_rsa

   Information about rights for the id_rsa file will appear in the response. For example:

   C:\Users\User\.ssh\id_rsa
     NT AUTHORITY\SYSTEM:(I)(F)
     BUILTIN\Administrators:(I)(F)
     User:(I)(R)
     BUILTIN\Users:(I)(R)

   Where:

   • (I) — permission inherited from the parent folder;
   • (F) — full access;
   • (R) — read access for the file.

6. Assign rights for the id_rsa file to the current user only:

   6.1. Remove permission inheritance for the file from the parent directory:

   icacls $env:USERPROFILE\.ssh\id_rsa /inheritance:r

   6.2. Assign rights for the file only to the current user:

   icacls $env:USERPROFILE\.ssh\id_rsa /grant:r "$env:USERNAME:(R)"

7. Check rights for the id_rsa file:

   icacls $env:USERPROFILE\.ssh\id_rsa

   Information about rights for the id_rsa file will appear in the response. For example:

   C:\Users\User\.ssh\id_rsa
     User:(R)

   Here, rights for the id_rsa file are held only by the User.

Check SSH service status

1. Load the server in recovery and diagnostic mode.

2. Connect to the server via the KVM console.

3. Check the sshd service status:

   systemctl status sshd

   Information about the sshd service status will appear in the response. For example:

   Active: active (running)

4. If the sshd service is stopped, restart it:

   systemctl start sshd

Check SSH port

By default, the SSH server accepts connections on port 22.

1. Load the server in recovery and diagnostic mode.

2. Connect to the server via the KVM console.

3. Check which ports the sshd service is waiting for incoming connections on:

   ss -tlnp | grep sshd

   Information about the ports that the sshd service accepts connections on will appear in the response. For example:

   LISTEN 0      128          0.0.0.0:22        0.0.0.0:*    users:(("sshd",pid=1023,fd=3))
   LISTEN 0      128             [::]:22           [::]:*    users:(("sshd",pid=1023,fd=4))

   Here, 22 is the port on which the SSH server accepts connections.

   If the output is empty, the sshd service is not running or is not accepting connections.

4. Check which port is specified in the SSH configuration:

   sshd -T | grep ^port

   Information about the SSH server ports will appear in the response. For example:

   port 2222

5. If the SSH ports in steps 3 and 4 do not match, restart the sshd service:

   systemctl restart sshd

6. If the SSH port on the server has been changed, for example to 2222, you must specify it when connecting:

   ssh -p <port> <username>@<ip_address>

   Specify:

   • <port> — SSH port;
   • <username> — username (login). You can view it in the control panel: in the top menu, click Products → Dedicated Servers → Servers → server page → Operating System → field Login;
   • <ip_address> — public IP address of the server. You can view it in the control panel: in the top menu, click Products → Dedicated Servers → Servers → server page → Operating System → field IP.

Check firewall settings

Ensure that incoming connections to the SSH port are allowed by firewall rules.

1. Load the server in recovery and diagnostic mode.

2. Connect to the server via the KVM console.

3. For diagnostics, temporarily turn off the firewall and test the connection:

   3.1. Turn off the firewall:

   systemctl stop firewalld

   3.2. Connect to the server via SSH. If you can connect, check the firewall rules.

   3.3. After finishing diagnostics, turn on the firewall:

   systemctl start firewalld

4. Check iptables rules:

   iptables -L -n -v

   A list of rules will appear in the response. For example:

   Chain INPUT (policy DROP 120 packets, 7200 bytes)
   pkts bytes target    prot opt in     out     source           destination
   145 8700  ACCEPT     tcp  --  *      *      0.0.0.0/0        0.0.0.0/0        tcp dpt:22
     80 4800  ACCEPT     all  --  lo     *      0.0.0.0/0        0.0.0.0/0

   Here, ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 is a rule that allows connections to port 22.

5. If iptables policies for port 22 are set to DROP or REJECT, change the firewall configuration to allow incoming connections to port 22.

6. Try connecting via SSH again.

Check SSH configuration on the server

If a Permission denied (publickey) error occurs when connecting or if the server does not offer key authentication, check the SSH server settings.

1. Load the server in recovery and diagnostic mode.

2. Connect to the server via the KVM console.

3. Open the /etc/ssh/sshd_config configuration file with the vi text editor:

   vi /etc/ssh/sshd_config

4. Ensure that the configuration contains the following parameters:

   PubkeyAuthentication yes
   AuthorizedKeysFile .ssh/authorized_keys

   Where:

   • PubkeyAuthentication — when set to yes, this enables authentication using SSH keys;
   • AuthorizedKeysFile — path to the file containing the public SSH key.

5. If the PubkeyAuthentication and AuthorizedKeysFile parameters are missing, add them.

6. Exit the vi text editor with your changes saved:

   :wq

7. Optional: if you added parameters to the configuration file in step 5, check it for errors:

   sshd -t

   If the output is empty, the configuration is correct.

8. If you added parameters to the configuration file in step 5, restart the SSH service:

   systemctl restart sshd

Check basic firewall rules

The basic firewall processes each packet in isolation — it does not remember established connections and does not track TCP session state. When analyzing traffic, the firewall only checks the header of each packet for compliance with rules:

• outgoing packets are only checked against outgoing rules;
• incoming packets are only checked against incoming rules, even if the incoming packet is a response to an allowed outgoing request.

Ensure that basic firewall rules are not blocking port 22. For more information, see the Manage basic firewall rules guide.