--- title: "SSH Connection Errors" sidebar_label: "SSH Connection Errors" sidebar_position: 4 description: "How to diagnose and fix errors when connecting to a dedicated server via SSH" --- import Formbricks from '@theme/MDXComponents/Formbricks' import {CustomTable} from '@selectel/docux/components' import Tabs from '@theme/Tabs' import TabItem from '@theme/TabItem' import {TabItemLabel} from '@selectel/docux/components' # SSH Connection Errors 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 \{#troubleshoot-ssh-connection} 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: ```bash ssh -vvv @ ``` Specify: * `-vvv` — a flag to enable debug mode, which allows you to trace the entire SSH connection setup process; * `` — username (login). You can view it in the [control panel](https://my.selectel.ru/servers): in the top menu, click **Products** → **Dedicated Servers** → **Servers** → server page → **Operating System** tab → **Login**; * `` — public IP address of the server. You can view it in the [control panel](https://my.selectel.ru/servers): 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](#ssh-connection-issues) will appear in the response. ### Connection issues \{#ssh-connection-issues}
ErrorReasonSolution
`Connection timed out`Connection timed out * [check node network availability and measure latency](/dedicated/troubleshooting/network-diagnostics.mdx#ping-to-measure-latency); * [scan ports](/dedicated/troubleshooting/network-diagnostics.mdx#scans-of-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](#check-for-ssh-key) on the local computer; * [configure access rights to the private key](#set-permissions) on the client
`Permission denied (publickey)`Server rejected the connection * [check for a public SSH key](#check-for-ssh-key) on the server; * [configure access rights](#set-permissions); * [check the SSH configuration on the server](#check-ssh-configuration)
`ssh: connect to host 203.0.113.10 port 22: Connection refused`Port `22` is not accepting connections * [check the SSH service status](#check-ssh-status); * [check the SSH port](#check-ssh-port); * [check the firewall settings](#check-firewall); * [scan ports](/dedicated/troubleshooting/network-diagnostics.mdx#scans-of-ports); * [check basic firewall rules](#check-basic-firewall)
### Check for the SSH key file \{#check-for-ssh-key} Check the public key on the server 1. [Load the server in recovery and diagnostic mode](/dedicated/troubleshooting/boot-to-recovery.mdx). 2. [Connect to the server via the KVM console](/dedicated/manage/connect-to-server.mdx#connect-via-kvm-console). 3. Check for the `.ssh` directory and the `authorized_keys` file: ```bash ls -la ~/.ssh/ ``` Information about the files in the `.ssh` directory will appear in the response. For example: ```bash 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: ```bash cat ~/.ssh/authorized_keys ``` One or more public SSH keys will appear in the response. For example: ```bash 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](/dedicated/manage/create-and-place-ssh-key.mdx#place-ssh-key-on-dedicated-server). Check the private key on the local computer Linux/macOS 1. Open the CLI on your local computer. 2. Check for SSH keys: ```bash ls -la ~/.ssh/ ``` Information about SSH keys will appear in the response. For example: ```bash 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](/dedicated/manage/create-and-place-ssh-key.mdx). Windows 1. Open PowerShell on your local computer. 2. Check for SSH keys: ```bash ls $HOME\.ssh ``` Information about SSH keys will appear in the response. For example: ```bash 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](/dedicated/manage/create-and-place-ssh-key.mdx). ### Configure access rights \{#set-permissions} On a dedicated server The SSH server strictly checks user permissions for the `~/.ssh` directory and the `~/.ssh/authorized_keys` file. If permissions are too open, the SSH connection will be unable to use the keys, even if they are specified correctly. 1. [Load the server in recovery and diagnostic mode](/dedicated/troubleshooting/boot-to-recovery.mdx). 2. [Connect to the server via the KVM console](/dedicated/manage/connect-to-server.mdx#connect-via-kvm-console). 3. Check rights for the `~/.ssh` directory: ```bash ls -ld ~/.ssh ``` Information about rights for the `~/.ssh` directory will appear in the response. For example: ```bash 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: ```bash 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: ```bash sudo chown -R : ~/.ssh ``` Specify: * `` — name of the user you connect to the server with via SSH; * `` — user group, usually the same as the username. You can view it using the `id ` command, where `` is the username. 6. Check rights for the `~/.ssh/authorized_keys` file: ```bash ls -l ~/.ssh/authorized_keys ``` Information about rights for the `~/.ssh/authorized_keys` file will appear in the response. For example: ```bash -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: ```bash 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 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 rights for the `.ssh` directory: ```bash ls -ld ~/.ssh ``` Information about rights for the `.ssh` directory will appear in the response. For example: ```bash 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: ```bash 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: ```bash ls -l ~/.ssh/id_rsa ``` Information about current rights for the `~/.ssh/id_rsa` file will appear in the response. For example: ```bash -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: ```bash 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 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 rights for the `.ssh` directory: ```bash icacls $env:USERPROFILE\.ssh ``` Information about rights for the `.ssh` directory will appear in the response. For example: ```bash 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: ```bash icacls $env:USERPROFILE\.ssh /inheritance:r ``` 3.2. Assign rights for the directory only to the current user: ```bash icacls $env:USERPROFILE\.ssh /grant:r "$env:USERNAME:(OI)(CI)F" ``` 4. Check current rights for the `.ssh` directory: ```bash icacls $env:USERPROFILE\.ssh ``` Information about rights for the `.ssh` directory will appear in the response. For example: ```bash 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: ```bash icacls $env:USERPROFILE\.ssh\id_rsa ``` Information about rights for the `id_rsa` file will appear in the response. For example: ```bash 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: ```bash icacls $env:USERPROFILE\.ssh\id_rsa /inheritance:r ``` 6.2. Assign rights for the file only to the current user: ```bash icacls $env:USERPROFILE\.ssh\id_rsa /grant:r "$env:USERNAME:(R)" ``` 7. Check rights for the `id_rsa` file: ```bash icacls $env:USERPROFILE\.ssh\id_rsa ``` Information about rights for the `id_rsa` file will appear in the response. For example: ```bash 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 \{#check-ssh-status} 1. [Load the server in recovery and diagnostic mode](/dedicated/troubleshooting/boot-to-recovery.mdx). 2. [Connect to the server via the KVM console](/dedicated/manage/connect-to-server.mdx#connect-via-kvm-console). 3. Check the `sshd` service status: ```bash systemctl status sshd ``` Information about the `sshd` service status will appear in the response. For example: ```bash Active: active (running) ``` 4. If the `sshd` service is stopped, restart it: ```bash systemctl start sshd ``` ### Check SSH port \{#check-ssh-port} By default, the SSH server accepts connections on port `22`. 1. [Load the server in recovery and diagnostic mode](/dedicated/troubleshooting/boot-to-recovery.mdx). 2. [Connect to the server via the KVM console](/dedicated/manage/connect-to-server.mdx#connect-via-kvm-console). 3. Check which ports the `sshd` service is waiting for incoming connections on: ```bash ss -tlnp | grep sshd ``` Information about the ports that the `sshd` service accepts connections on will appear in the response. For example: ```bash 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: ```bash sshd -T | grep ^port ``` Information about the SSH server ports will appear in the response. For example: ```bash port 2222 ``` 5. If the SSH ports in steps 3 and 4 do not match, restart the `sshd` service: ```bash systemctl restart sshd ``` 6. If the SSH port on the server has been changed, for example to `2222`, you must specify it when connecting: ```bash ssh -p @ ``` Specify: * `` — SSH port; * `` — username (login). You can view it in the [control panel](https://my.selectel.ru/servers): in the top menu, click **Products** → **Dedicated Servers** → **Servers** → server page → **Operating System** tab → **Login**; * `` — public IP address of the server. You can view it in the [control panel](https://my.selectel.ru/servers): in the top menu, click **Products** → **Dedicated Servers** → **Servers** → server page → **Operating System** tab → **IP**. ### Check firewall settings \{#check-firewall} Ensure that incoming connections to the SSH port are allowed by firewall rules. 1. [Load the server in recovery and diagnostic mode](/dedicated/troubleshooting/boot-to-recovery.mdx). 2. [Connect to the server via the KVM console](/dedicated/manage/connect-to-server.mdx#connect-via-kvm-console). 3. For diagnostics, temporarily turn off the firewall and test the connection: 3.1. Turn off the firewall: ```bash 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: ```bash systemctl start firewalld ``` 4. Check `iptables` rules: ```bash iptables -L -n -v ``` A list of rules will appear in the response. For example: ```bash 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 \{#check-ssh-configuration} 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](/dedicated/troubleshooting/boot-to-recovery.mdx). 2. [Connect to the server via the KVM console](/dedicated/manage/connect-to-server.mdx#connect-via-kvm-console). 3. Open the `/etc/ssh/sshd_config` configuration file with the `vi` text editor: ```bash vi /etc/ssh/sshd_config ``` 4. Ensure that the configuration contains the following parameters: ```bash 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: ```bash :wq ``` 7. Optional: if you added parameters to the configuration file in step 5, check it for errors: ```bash 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: ```bash systemctl restart sshd ``` ### Check basic firewall rules \{#check-basic-firewall} [Basic firewall](/basic-firewall/about/about-basic-firewall.mdx) processes each packet in isolation — it does not store established connections or track the state of TCP sessions. When analyzing traffic, the firewall checks only 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. Ensure that the basic firewall rules are not blocking port `22`. For more information, see the guide [Manage basic firewall rules](/basic-firewall/manage/manage-rules.mdx).