Ошибки подключения к серверу по SSH

Последнее изменение: 27 июля 2026

Если вы столкнулись с проблемами подключения к серверу, выполните диагностику. После диагностики некоторые часто возникающие ошибки вы можете решить самостоятельно.

Определить проблему подключения

Если при подключении по SSH возникают ошибки или нужно проверить, какой ключ используется для аутентификации, запустите подключение в режиме отладки:

ssh -vvv <username>@<ip_address>

Укажите:

• -vvv — флаг для включения режима отладки, который позволяет проследить весь процесс установки SSH-соединения;
• <username> — имя пользователя (логин). Можно посмотреть в панели управления: в верхнем меню нажмите Продукты → Выделенные серверы → Серверы → страница сервера → вкладка Операционная система → поле Логин;
• <ip_address> — публичный IP-адрес сервера. Можно посмотреть в панели управления: в верхнем меню нажмите Продукты → Выделенные серверы → Серверы → страница сервера → вкладка Операционная система → поле IP.

В ответе появится информация о процессе установки SSH-соединения и возникающих проблемах подключения.

Проблемы подключения

Ошибка	Причина	Решение
Connection timed out	Истекло время ожидания подключения	проверить доступность узла в сети и измерить задержку; просканировать порты
Warning: Identity file /home/user/.ssh/authorized_keys not accessible: No such file or directory	Приватный ключ клиента отсутствует или недоступен	проверить наличие приватного SSH-ключа на локальном компьютере; настроить права доступа к приватному ключу на клиенте
Permission denied (publickey)	Сервер отклонил подключение	проверить наличие публичного SSH-ключа на сервере; настроить права доступа; проверить конфигурацию SSH на сервере
ssh: connect to host 203.0.113.10 port 22: Connection refused	Порт 22 не принимает соединение	проверить состояние службы SSH; проверить порт SSH; проверить настройки файрвола; просканировать порты; проверить правила базового файрвола

Проверить наличие файла SSH-ключа

Проверить публичный ключ на сервере

1. Загрузите сервер в режиме восстановления и диагностики.

2. Подключитесь к серверу через KVM-консоль.

3. Проверьте наличие директории .ssh и файла authorized_keys:

   ls -la ~/.ssh/

   В ответе появится информация о файлах в директории .ssh. Например:

   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

   Здесь authorized_keys — файл с публичными SSH-ключами, которым разрешено подключение к серверу.

4. Выведите содержимое файла authorized_keys:

   cat ~/.ssh/authorized_keys

   В ответе появится один или несколько публичных SSH-ключей. Например:

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

   Убедитесь, что SSH-ключ соответствует приватному ключу, который используется на клиенте.

5. Если директории .ssh или файла authorized_keys не существует или в файле нет нужного публичного ключа, разместите SSH-ключ на сервере.

Проверить приватный ключ на локальном компьютере

Linux/macOS

1. На локальном компьютере откройте CLI.

2. Проверьте наличие SSH-ключей:

   ls -la ~/.ssh/

   В ответе появится информация о SSH-ключах. Например:

   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

   Здесь id_rsa, id_ed25519 — приватные SSH-ключи.

3. Если файла приватного ключа нет, создайте и разместите SSH-ключ на сервере.

Windows

1. На локальном компьютере откройте PowerShell.

2. Проверьте наличие SSH-ключей:

   ls $HOME\.ssh

   В ответе появится информация о SSH-ключах. Например:

       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

   Здесь id_rsa, id_ed25519 — приватные SSH-ключи.

3. Если файла приватного SSH-ключа нет, создайте и разместите SSH-ключ на сервере.

Настроить права доступа

На выделенном сервере

SSH-сервер строго проверяет права пользователя на директорию ~/.ssh и файл ~/.ssh/authorized_keys. Если права слишком открытые, SSH-подключение не сможет использовать ключи, даже если они указаны верно.

1. Загрузите сервер в режиме восстановления и диагностики.

2. Подключитесь к серверу через KVM-консоль.

3. Проверьте права на директорию ~/.ssh:

   ls -ld ~/.ssh

   В ответе появится информация о правах на директорию ~/.ssh. Например:

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

   Здесь:

   • drwx------ — тип объекта и права на него у пользователей системы, где:

     • d — тип объекта: директория;
     • rwx — права владельца: чтение, создание и удаление файлов в директории, доступ в директорию;
     • --- — отсутствие прав у группы. Участники группы не могут читать, писать или переходить в директорию;
     • --- — отсутствие прав у других пользователей системы;

   • первое значение username — пользователь с правами владельца;

   • второе значение username — группа пользователя. Обычно аналогична имени пользователя.

   Права на директорию ~/.ssh соответствуют коду 700: чтение, создание и удаление файлов в директории, доступ в директорию.

4. Если на шаге 3 права на директорию ~/.ssh отличаются, установите корректные права:

   chmod 700 ~/.ssh

   Здесь:

   • 7 — права владельца: чтение, создание и удаление файлов в директории, доступ в директорию;
   • 0 — отсутствие прав у группы;
   • 0 — отсутствие прав у других пользователей системы.

   При успешном выполнении команда не выводит результат.

5. Если владелец директории ~/.ssh неверный, измените его:

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

   Укажите:

   • <username> — имя пользователя, от имени которого вы подключаетесь к серверу по SSH;
   • <user_group> — группа пользователя, обычно аналогична имени пользователя. Можно посмотреть с помощью команды id <username>, где <username> — имя пользователя.

6. Проверьте права на файл ~/.ssh/authorized_keys:

   ls -l ~/.ssh/authorized_keys

   В ответе появится информация о правах на файл ~/.ssh/authorized_keys. Например:

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

   Здесь:

   • -rw------- — тип объекта и права на него у пользователей системы, где:

     • - — тип объекта ~/.ssh/authorized_keys: обычный файл;
     • rw- — права владельца: чтение и запись;
     • --- — отсутствие прав у группы;
     • --- — отсутствие прав у других пользователей системы;

   • первое значение username — пользователь с правами владельца;

   • второе значение username — группа пользователя. Обычно аналогична имени пользователя.

   Права на файл ~/.ssh/authorized_keys соответствуют коду 600: чтение и запись.

7. Если на шаге 6 права на файл ~/.ssh/authorized_keys отличаются, установите корректные права:

   sudo chmod 600 ~/.ssh/authorized_keys

   Здесь:

   • 6 — права владельца: чтение и запись;
   • 0 — отсутствие прав у группы;
   • 0 — отсутствие прав у других пользователей системы.

   При успешном выполнении команда не выводит результат.

На локальном компьютере

На устройстве, с которого вы подключаетесь по SSH к выделенному серверу, приватный ключ должен быть доступен только текущему пользователю. Если права доступа слишком открытые, SSH-подключение не сможет использовать ключ.

Linux/macOS

1. На локальном компьютере откройте CLI.

2. Проверьте права на директорию ~/.ssh:

   ls -ld ~/.ssh

   В ответе появится информация о правах на директорию ~/.ssh. Например:

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

   Здесь:

   • drwx------ — тип объекта и права на него у пользователей системы, где:

     • d — тип объекта: directory (директория);
     • rwx — права владельца: чтение, создание и удаление файлов в директории, доступ в директорию;
     • --- — отсутствие прав у группы. Участники группы не могут читать, писать или переходить в директорию;
     • --- — отсутстсвие прав у других пользователей системы;

   • первое значение username — пользователь с правами владельца;

   • второе значение username — группа пользователя. Обычно аналогична имени пользователя.

   Права на директорию ~/.ssh соответствуют коду 700: чтение, создание и удаление файлов в директории, доступ в директорию.

3. Если на шаге 2 права на директорию ~/.ssh отличаются, установите корректные права:

   chmod 700 ~/.ssh

   Здесь:

   • 7 — права владельца: чтение, создание и удаление файлов в директории, доступ в директорию;
   • 0 — отсутствие прав у группы;
   • 0 — отсутствие прав у других пользователей системы.

   При успешном выполнении команда не выводит результат.

4. Проверьте права на файл ~/.ssh/id_rsa:

   ls -l ~/.ssh/id_rsa

   В ответе появится информация о текущих правах на файл ~/.ssh/id_rsa. Например:

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

   Здесь:

   • -rw-r--r-- — тип объекта и права на него у пользователей системы, где:

     • - — тип объекта ~/.ssh/id_rsa: обычный файл;
     • rw- — права владельца: чтение и изменение файла;
     • r-- — права группы: чтение;
     • r-- — права других пользователей системы: чтение.

   • первое значение username — пользователь с правами владельца;

   • второе значение username — группа пользователя, обычно аналогична имени пользователя, но может отличаться.

   Права на файл ~/.ssh/id_rsa соответствуют коду 600: чтение и запись.

5. Если на шаге 4 права на файл ~/.ssh/id_rsa отличаются, установите корректные права:

   chmod 600 ~/.ssh/id_rsa

   Здесь:

   • 6 — права владельца: чтение и запись;
   • 0 — отсутствие прав у группы;
   • 0 — отсутствие прав у остальных пользователей системы.

   При успешном выполнении команда не выводит результат.

Windows

На Windows SSH проверяет NTFS-права. Приватный ключ должен быть доступен только пользователю, от имени которого выполняется подключение. Если права включают доступ для других пользователей, OpenSSH может отказаться использовать ключ.

1. На локальном компьютере откройте PowerShell от имени пользователя, под которым вы подключаетесь по SSH к выделенному серверу.

2. Проверьте права на директорию .ssh:

   icacls $env:USERPROFILE\.ssh

   В ответе появится информация о правах на директорию .ssh. Например:

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

   Здесь:

   • (F) — полный доступ;
   • (OI) — наследуются права доступа на файлы в папке;
   • (CI) — наследуются права доступа на вложенные папки;
   • (R) — права на чтение.

3. Назначьте права на директорию .ssh только текущему пользователю:

   3.1. Удалите наследование прав на директорию:

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

   3.2. Назначьте права на директорию только текущему пользователю:

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

4. Проверьте текущие права на директорию .ssh:

   icacls $env:USERPROFILE\.ssh

   В ответе появится информация о правах на директорию .ssh. Например:

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

   Здесь права на директорию .ssh есть только у пользователя User.

5. Проверьте текущие права на файл id_rsa:

   icacls $env:USERPROFILE\.ssh\id_rsa

   В ответе появится информация о правах на файл id_rsa. Например:

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

   Здесь:

   • (I) — право унаследовано от родительской папки;
   • (F) — полный доступ;
   • (R) — права на чтение файла.

6. Назначьте права на файл id_rsa только текущему пользователю:

   6.1. Удалите наследование прав на файл от родительской директории:

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

   6.2. Назначьте права на файл только текущему пользователю:

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

7. Проверьте права на файл id_rsa:

   icacls $env:USERPROFILE\.ssh\id_rsa

   В ответе появится информация о правах на файл id_rsa. Например:

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

   Здесь права на файл id_rsa есть только у пользователя User.

Проверить состояние службы SSH

1. Загрузите сервер в режиме восстановления и диагностики.

2. Подключитесь к серверу через KVM-консоль.

3. Проверьте состояние службы sshd:

   systemctl status sshd

   В ответе появится информация о состоянии службы sshd. Например:

   Active: active (running)

4. Если служба sshd остановлена, перезапустите ее:

   systemctl start sshd

Проверить порт SSH

По умолчанию SSH-сервер принимает подключения на порту 22.

1. Загрузите сервер в режиме восстановления и диагностики.

2. Подключитесь к серверу через KVM-консоль.

3. Проверьте, на каких портах служба sshd ожидает входящие подключения:

   ss -tlnp | grep sshd

   В ответе появится информация о портах, на которых служба sshd принимает подключения. Например:

   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))

   Здесь 22 — порт, на котором SSH-сервер принимает подключения.

   Если вывод пустой, служба sshd не запущена или не принимает подключения.

4. Проверьте, какой порт указан в конфигурации SSH:

   sshd -T | grep ^port

   В ответе появится информация о портах SSH-сервера. Например:

   port 2222

5. Если SSH-порты на шагах 3 и 4 не совпадают, перезапустите службу sshd:

   systemctl restart sshd

6. Если на сервере изменен порт SSH, например на 2222, нужно указывать его при подключении:

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

   Укажите:

   • <port> — порт SSH;
   • <username> — имя пользователя (логин). Можно посмотреть в панели управления: в верхнем меню нажмите Продукты → Выделенные серверы → Серверы → страница сервера → вкладка Операционная система → поле Логин;
   • <ip_address> — публичный IP-адрес сервера. Можно посмотреть в панели управления: в верхнем меню нажмите Продукты → Выделенные серверы → Серверы → страница сервера → вкладка Операционная система → поле IP.

Проверить настройки файрвола

Убедитесь, что входящие подключения к SSH-порту разрешены правилами файрвола.

1. Загрузите сервер в режиме восстановления и диагностики.

2. Подключитесь к серверу через KVM-консоль.

3. Для диагностики временно отключите файрвол и проверьте подключение:

   3.1. Выключите файрвол:

   systemctl stop firewalld

   3.2. Подключитесь к серверу по SSH. Если удалось подключиться, проверьте правила файрвола.

   3.3. После завершения диагностики включите файрвол:

   systemctl start firewalld

4. Проверьте правила iptables:

   iptables -L -n -v

   В ответе появится список правил. Например:

   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

   Здесь ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 — правило, разрешающее подключения на порт 22.

5. Если в правилах iptables для порта 22 установлены политики DROP или REJECT, измените конфигурацию файрвола, чтобы разрешить входящие подключения на порт 22.

6. Повторите попытку подключения по SSH.

Проверить конфигурацию SSH на сервере

Если при подключении возникает ошибка Permission denied (publickey) или сервер не предлагает аутентификацию по ключу, проверьте настройки SSH-сервера.

1. Загрузите сервер в режиме восстановления и диагностики.

2. Подключитесь к серверу через KVM-консоль.

3. Откройте файл конфигурации /etc/ssh/sshd_config текстовым редактором vi:

   vi /etc/ssh/sshd_config

4. Убедитесь, что конфигурация содержит следующие параметры:

   PubkeyAuthentication yes
   AuthorizedKeysFile .ssh/authorized_keys

   Здесь:

   • PubkeyAuthentication — в значении yes разрешает аутентификацию с помощью SSH-ключей;
   • AuthorizedKeysFile — путь к файлу с публичным SSH-ключом.

5. Если параметры PubkeyAuthentication и AuthorizedKeysFile отсутствуют, добавьте их.

6. Выйдите из текстового редактора vi с сохранением изменений:

   :wq

7. Опционально: если на шаге 5 вы добавили параметры в файл конфигурации, проверьте его на ошибки:

   sshd -t

   Если вывод пустой, конфигурация корректна.

8. Если на шаге 5 вы добавили параметры в файл конфигурации, перезапустите службу SSH:

   systemctl restart sshd

Проверить правила базового файрвола

Базовый файрвол обрабатывает каждый пакет изолированно — он не запоминает установленные соединения и не отслеживает состояние TCP-сессий. При анализе трафика файрвол проверяет только заголовок каждого пакета на соответствие правилам:

• исходящие пакеты проверяются только по исходящим правилам;
• входящие пакеты проверяются только по входящим правилам, даже если входящий пакет — это ответ на разрешенный исходящий запрос.

Убедитесь, что правила базового файрвола не блокируют порт 22. Подробнее в инструкции Управлять правилами базового файрвола.