SSH Connection Errors

Last update: October 13 2026Open in Markdown

If you encounter issues connecting to the server, run a diagnostic. After the diagnostic, you can resolve some frequently occurring errors on your own.

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 — flag to enable debug mode, which allows you to trace the entire SSH connection establishment process;
• <username> — username (login). You can find 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 find it in the Control panel: in the top menu, click Products → Dedicated Servers → Servers → server page → Operating system tab → IP field.

The response will show information about the SSH connection establishment process and occurring connection issues.

Connection issues

Error	Reason	Solution
Connection timed out	Connection timed out	check host network reachability 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 permissions for the private key on the client
Permission denied (publickey)	Server rejected the connection	check for a public SSH key on the server; configure permissions; check 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 firewall settings; scan ports; check basic firewall rules

Check for the SSH key file

Check the public key on the server

1. Boot the server into rescue mode.

2. Connect to the server via KVM console.

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

   ls -la ~/.ssh/

   The response will show information about files in the .ssh directory. 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

   Where authorized_keys is a file containing public SSH keys 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 the authorized_keys file does not exist, or the file does not contain the required public key, 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

   Where id_rsa, id_ed25519 are private SSH keys.

3. If the private key file does not exist, 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

   Where id_rsa, id_ed25519 are private SSH keys.

3. If the private SSH key file does not exist, create and place an SSH key on the server.

Configure access rights

On a dedicated server

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

1. Boot the server into rescue mode.

2. Connect to the server via KVM console.

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

   ls -ld ~/.ssh

   The response will show information about permissions for the ~/.ssh directory. For example:

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

   Where:

   • drwx------ — object type and its permissions for system users, where:

     • d — object type: directory;
     • rwx — owner permissions: reading, creating, and deleting files in the directory, accessing the directory;
     • --- — no permissions for the group. Group members cannot read, write, or enter the directory;
     • --- — no permissions for other system users;

   • the first username value — user with owner permissions;

   • the second username value — user group. Usually identical to the username.

   Permissions for the ~/.ssh directory correspond to code 700: reading, creating, and deleting files in the directory, accessing the directory.

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

   chmod 700 ~/.ssh

   Where:

   • 7 — owner permissions: reading, creating, and deleting files in the directory, accessing the directory;
   • 0 — no permissions for the group;
   • 0 — no permissions 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> — username under which you connect to the server via SSH;
   • <user_group> — user group, usually identical to the username. You can check it using the command id <username>, where <username> is the username.

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

   ls -l ~/.ssh/authorized_keys

   The response will show information about permissions for the ~/.ssh/authorized_keys file. For example:

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

   Where:

   • -rw------- — object type and its permissions for system users, where:

     • - — object type for ~/.ssh/authorized_keys: regular file;
     • rw- — owner permissions: reading and writing;
     • --- — no permissions for the group;
     • --- — no permissions for other system users;

   • the first username value — user with owner permissions;

   • the second username value — user group. Usually identical to the username.

   Permissions for the ~/.ssh/authorized_keys file correspond to code 600: reading and writing.

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

   sudo chmod 600 ~/.ssh/authorized_keys

   Where:

   • 6 — owner permissions: reading and writing;
   • 0 — no permissions for the group;
   • 0 — no permissions for other system users.

   If successful, the command will not display any output.

On a local computer

On the device you are using to connect to the dedicated server via SSH, the private key must be accessible only to the current user. If access permissions are too open, the SSH connection will be unable to use the key.

Linux/macOS

1. Open the CLI on your local computer.

2. Check permissions for the ~/.ssh directory:

   ls -ld ~/.ssh

   The response will show information about permissions for the ~/.ssh directory. For example:

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

   Where:

   • drwx------ — object type and its permissions for system users, where:

     • d — object type: directory;
     • rwx — owner permissions: reading, creating, and deleting files in the directory, accessing the directory;
     • --- — no permissions for the group. Group members cannot read, write, or enter the directory;
     • --- — no permissions for other system users;

   • the first username value — user with owner permissions;

   • the second username value — user group. Usually identical to the username.

   Permissions for the ~/.ssh directory correspond to code 700: reading, creating, and deleting files in the directory, accessing the directory.

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

   chmod 700 ~/.ssh

   Where:

   • 7 — owner permissions: reading, creating, and deleting files in the directory, accessing the directory;
   • 0 — no permissions for the group;
   • 0 — no permissions for other system users.

   If successful, the command will not display any output.

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

   ls -l ~/.ssh/id_rsa

   The response will show information about current permissions for the ~/.ssh/id_rsa file. For example:

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

   Where:

   • -rw------- — the object type and its permissions for system users, where:

     • - — object type for ~/.ssh/id_rsa: regular file;
     • rw- — owner permissions: read and write the file;
     • --- — group permissions: none;
     • --- — permissions for other system users: none.

   • the first username value — user with owner permissions;

   • the second username value — user group, usually identical to the username, but may differ.

   Permissions for the ~/.ssh/id_rsa file correspond to code 600: reading and writing.

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

   chmod 600 ~/.ssh/id_rsa

   Where:

   • 6 — owner permissions: reading and writing;
   • 0 — no permissions for the group;
   • 0 — no permissions for other system users.

   If successful, the command will not display any output.

Windows

On Windows, SSH checks NTFS permissions. The private key must be accessible only to the user under whose account the connection is being performed. If permissions 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 permissions for the .ssh directory:

   icacls $env:USERPROFILE\.ssh

   The response will show information about permissions for the .ssh directory. 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) — permissions are inherited for files in the folder;
   • (CI) — permissions are inherited for subfolders;
   • (R) — read permissions.

3. Grant permissions for the .ssh directory only to the current user:

   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 permissions for the .ssh directory:

   icacls $env:USERPROFILE\.ssh

   The response will show information about permissions for the .ssh directory. For example:

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

   Here, only user User has permissions for the .ssh directory.

5. Check current permissions for the id_rsa file:

   icacls $env:USERPROFILE\.ssh\id_rsa

   The response will show information about permissions for the id_rsa file. 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 parent folder;
   • (F) — full access;
   • (R) — file read permissions.

6. Grant permissions for the id_rsa file only to the current user:

   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 permissions for the id_rsa file:

   icacls $env:USERPROFILE\.ssh\id_rsa

   The response will show information about permissions for the id_rsa file. For example:

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

   Here, only user User has permissions for the id_rsa file.

Check SSH service status

1. Boot the server into rescue mode.

2. Connect to the server via KVM console.

3. Check the status of the sshd service:

   systemctl status sshd

   The response will show information about the status of the sshd service. 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. Boot the server in recovery and diagnostics mode.

2. Connect to the server via KVM console.

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

   ss -tlnp | grep sshd

   The response will show information about the ports on which the sshd service accepts connections. 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))

   Where 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 has been changed on the server, 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 find 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 find it in the Control panel: in the top menu, click Products → Dedicated Servers → Servers → server page → Operating system tab → IP field.

Check firewall settings

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

1. Boot the server into rescue mode.

2. Connect to the server via 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

   Where ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 is a rule allowing connections to port 22.

5. If DROP or REJECT policies are set in the iptables rules for port 22, 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 upon connection or the server does not offer key authentication, check the SSH server settings.

1. Boot the server into rescue mode.

2. Connect to the server via KVM console.

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

   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, allows authentication using SSH keys;
   • AuthorizedKeysFile — path to the file with the public SSH key.

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

6. Exit the text editor vi while saving changes:

   :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

Basic firewall processes each packet in isolation — it does not remember established connections and does not track the state of TCP sessions. When analyzing traffic, the firewall only checks the header of each packet for compliance with the 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.

Make sure that the basic firewall rules do not block port 22. Learn more in the Manage basic firewall rules instructions.