--- title: 'Ошибки подключения к серверу по SSH' sidebar_label: 'Ошибки подключения к серверу по SSH' sidebar_position: 4 description: 'Как определить и исправить ошибки при подключении к выделенному серверу по 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 Если вы столкнулись с проблемами подключения к серверу, выполните диагностику. После диагностики некоторые часто возникающие ошибки вы можете решить самостоятельно. ## Определить проблему подключения \{#troubleshoot-ssh-connection} Если при подключении по SSH возникают ошибки или нужно проверить, какой ключ используется для аутентификации, запустите подключение в режиме отладки: ```bash ssh -vvv @ ``` Укажите: * `-vvv` — флаг для включения режима отладки, который позволяет проследить весь процесс установки SSH-соединения; * `` — имя пользователя (логин). Можно посмотреть в [панели управления](https://my.selectel.ru/servers): в верхнем меню нажмите **Продукты** → **Выделенные серверы** → **Серверы** → страница сервера → вкладка **Операционная система** → поле **Логин**; * `` — публичный IP-адрес сервера. Можно посмотреть в [панели управления](https://my.selectel.ru/servers): в верхнем меню нажмите **Продукты** → **Выделенные серверы** → **Серверы** → страница сервера → вкладка **Операционная система** → поле **IP**. В ответе появится информация о процессе установки SSH-соединения и возникающих [проблемах подключения](#ssh-connection-issues). ### Проблемы подключения \{#ssh-connection-issues}
Ошибка Причина Решение
`Connection timed out` Истекло время ожидания подключения * [проверить доступность узла в сети и измерить задержку](/dedicated/troubleshooting/network-diagnostics.mdx#ping-to-measure-latency); * [просканировать порты](/dedicated/troubleshooting/network-diagnostics.mdx#scans-of-ports)
`Warning: Identity file /home/user/.ssh/authorized_keys not accessible: No such file or directory` Приватный ключ клиента отсутствует или недоступен * [проверить наличие приватного SSH-ключа](#check-for-ssh-key) на локальном компьютере; * [настроить права доступа к приватному ключу](#set-permissions) на клиенте
`Permission denied (publickey)` Сервер отклонил подключение * [проверить наличие публичного SSH-ключа](#check-for-ssh-key) на сервере; * [настроить права доступа](#set-permissions); * [проверить конфигурацию SSH на сервере](#check-ssh-configuration)
`ssh: connect to host 203.0.113.10 port 22: Connection refused` Порт `22` не принимает соединение * [проверить состояние службы SSH](#check-ssh-status); * [проверить порт SSH](#check-ssh-port); * [проверить настройки файрвола](#check-firewall); * [просканировать порты](/dedicated/troubleshooting/network-diagnostics.mdx#scans-of-ports); * [проверить правила базового файрвола](#check-basic-firewall)
### Проверить наличие файла SSH-ключа \{#check-for-ssh-key} Проверить публичный ключ на сервере 1. [Загрузите сервер в режиме восстановления и диагностики](/dedicated/troubleshooting/boot-to-recovery.mdx). 2. [Подключитесь к серверу через KVM-консоль](/dedicated/manage/connect-to-server.mdx#connect-via-kvm-console). 3. Проверьте наличие директории `.ssh` и файла `authorized_keys`: ```bash ls -la ~/.ssh/ ``` В ответе появится информация о файлах в директории `.ssh`. Например: ```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 ``` Здесь `authorized_keys` — файл с публичными SSH-ключами, которым разрешено подключение к серверу. 4. Выведите содержимое файла `authorized_keys`: ```bash cat ~/.ssh/authorized_keys ``` В ответе появится один или несколько публичных SSH-ключей. Например: ```bash ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIP... user@example ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC... admin@example ``` Убедитесь, что SSH-ключ соответствует приватному ключу, который используется на клиенте. 5. Если директории `.ssh` или файла `authorized_keys` не существует или в файле нет нужного публичного ключа, [разместите SSH-ключ на сервере](/dedicated/manage/create-and-place-ssh-key.mdx#place-ssh-key-on-dedicated-server). Проверить приватный ключ на локальном компьютере Linux/macOS 1. На локальном компьютере откройте CLI. 2. Проверьте наличие SSH-ключей: ```bash ls -la ~/.ssh/ ``` В ответе появится информация о SSH-ключах. Например: ```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 ``` Здесь `id_rsa`, `id_ed25519` — приватные SSH-ключи. 3. Если файла приватного ключа нет, [создайте и разместите SSH-ключ на сервере](/dedicated/manage/create-and-place-ssh-key.mdx). Windows 1. На локальном компьютере откройте PowerShell. 2. Проверьте наличие SSH-ключей: ```bash ls $HOME\.ssh ``` В ответе появится информация о SSH-ключах. Например: ```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 ``` Здесь `id_rsa`, `id_ed25519` — приватные SSH-ключи. 3. Если файла приватного SSH-ключа нет, [создайте и разместите SSH-ключ на сервере](/dedicated/manage/create-and-place-ssh-key.mdx). ### Настроить права доступа \{#set-permissions} На выделенном сервере SSH-сервер строго проверяет права пользователя на директорию `~/.ssh` и файл `~/.ssh/authorized_keys`. Если права слишком открытые, SSH-подключение не сможет использовать ключи, даже если они указаны верно. 1. [Загрузите сервер в режиме восстановления и диагностики](/dedicated/troubleshooting/boot-to-recovery.mdx). 2. [Подключитесь к серверу через KVM-консоль](/dedicated/manage/connect-to-server.mdx#connect-via-kvm-console). 3. Проверьте права на директорию `~/.ssh`: ```bash ls -ld ~/.ssh ``` В ответе появится информация о правах на директорию `~/.ssh`. Например: ```bash drwx------ 2 username username 4096 Oct 24 10:00 /home/user/.ssh ``` Здесь: * `drwx------` — тип объекта и права на него у пользователей системы, где: * `d` — тип объекта: директория; * `rwx` — права владельца: чтение, создание и удаление файлов в директории, доступ в директорию; * `---` — отсутствие прав у группы. Участники группы не могут читать, писать или переходить в директорию; * `---` — отсутствие прав у других пользователей системы; * первое значение `username` — пользователь с правами владельца; * второе значение `username` — группа пользователя. Обычно аналогична имени пользователя. Права на директорию `~/.ssh` соответствуют коду `700`: чтение, создание и удаление файлов в директории, доступ в директорию. 4. Если на шаге 3 права на директорию `~/.ssh` отличаются, установите корректные права: ```bash chmod 700 ~/.ssh ``` Здесь: * `7` — права владельца: чтение, создание и удаление файлов в директории, доступ в директорию; * `0` — отсутствие прав у группы; * `0` — отсутствие прав у других пользователей системы. При успешном выполнении команда не выводит результат. 5. Если владелец директории `~/.ssh` неверный, измените его: ```bash sudo chown -R : ~/.ssh ``` Укажите: * `` — имя пользователя, от имени которого вы подключаетесь к серверу по SSH; * `` — группа пользователя, обычно аналогична имени пользователя. Можно посмотреть с помощью команды `id `, где `` — имя пользователя. 6. Проверьте права на файл `~/.ssh/authorized_keys`: ```bash ls -l ~/.ssh/authorized_keys ``` В ответе появится информация о правах на файл `~/.ssh/authorized_keys`. Например: ```bash -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` отличаются, установите корректные права: ```bash sudo chmod 600 ~/.ssh/authorized_keys ``` Здесь: * `6` — права владельца: чтение и запись; * `0` — отсутствие прав у группы; * `0` — отсутствие прав у других пользователей системы. При успешном выполнении команда не выводит результат. На локальном компьютере На устройстве, с которого вы подключаетесь по SSH к выделенному серверу, приватный ключ должен быть доступен только текущему пользователю. Если права доступа слишком открытые, SSH-подключение не сможет использовать ключ. Linux/macOS 1. На локальном компьютере откройте CLI. 2. Проверьте права на директорию `~/.ssh`: ```bash ls -ld ~/.ssh ``` В ответе появится информация о правах на директорию `~/.ssh`. Например: ```bash drwx------ 2 username username 4096 Oct 24 10:00 /home/user/.ssh ``` Здесь: * `drwx------` — тип объекта и права на него у пользователей системы, где: * `d` — тип объекта: directory (директория); * `rwx` — права владельца: чтение, создание и удаление файлов в директории, доступ в директорию; * `---` — отсутствие прав у группы. Участники группы не могут читать, писать или переходить в директорию; * `---` — отсутстсвие прав у других пользователей системы; * первое значение `username` — пользователь с правами владельца; * второе значение `username` — группа пользователя. Обычно аналогична имени пользователя. Права на директорию `~/.ssh` соответствуют коду `700`: чтение, создание и удаление файлов в директории, доступ в директорию. 3. Если на шаге 2 права на директорию `~/.ssh` отличаются, установите корректные права: ```bash chmod 700 ~/.ssh ``` Здесь: * `7` — права владельца: чтение, создание и удаление файлов в директории, доступ в директорию; * `0` — отсутствие прав у группы; * `0` — отсутствие прав у других пользователей системы. При успешном выполнении команда не выводит результат. 4. Проверьте права на файл `~/.ssh/id_rsa`: ```bash ls -l ~/.ssh/id_rsa ``` В ответе появится информация о текущих правах на файл `~/.ssh/id_rsa`. Например: ```bash -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` отличаются, установите корректные права: ```bash chmod 600 ~/.ssh/id_rsa ``` Здесь: * `6` — права владельца: чтение и запись; * `0` — отсутствие прав у группы; * `0` — отсутствие прав у остальных пользователей системы. При успешном выполнении команда не выводит результат. Windows На Windows SSH проверяет NTFS-права. Приватный ключ должен быть доступен только пользователю, от имени которого выполняется подключение. Если права включают доступ для других пользователей, OpenSSH может отказаться использовать ключ. 1. На локальном компьютере откройте PowerShell от имени пользователя, под которым вы подключаетесь по SSH к выделенному серверу. 2. Проверьте права на директорию `.ssh`: ```bash icacls $env:USERPROFILE\.ssh ``` В ответе появится информация о правах на директорию `.ssh`. Например: ```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) ``` Здесь: * `(F)` — полный доступ; * `(OI)` — наследуются права доступа на файлы в папке; * `(CI)` — наследуются права доступа на вложенные папки; * `(R)` — права на чтение. 3. Назначьте права на директорию `.ssh` только текущему пользователю: 3.1. Удалите наследование прав на директорию: ```bash icacls $env:USERPROFILE\.ssh /inheritance:r ``` 3.2. Назначьте права на директорию только текущему пользователю: ```bash icacls $env:USERPROFILE\.ssh /grant:r "$env:USERNAME:(OI)(CI)F" ``` 4. Проверьте текущие права на директорию `.ssh`: ```bash icacls $env:USERPROFILE\.ssh ``` В ответе появится информация о правах на директорию `.ssh`. Например: ```bash C:\Users\User\.ssh User:(OI)(CI)(F) ``` Здесь права на директорию `.ssh` есть только у пользователя `User`. 5. Проверьте текущие права на файл `id_rsa`: ```bash icacls $env:USERPROFILE\.ssh\id_rsa ``` В ответе появится информация о правах на файл `id_rsa`. Например: ```bash 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. Удалите наследование прав на файл от родительской директории: ```bash icacls $env:USERPROFILE\.ssh\id_rsa /inheritance:r ``` 6.2. Назначьте права на файл только текущему пользователю: ```bash icacls $env:USERPROFILE\.ssh\id_rsa /grant:r "$env:USERNAME:(R)" ``` 7. Проверьте права на файл `id_rsa`: ```bash icacls $env:USERPROFILE\.ssh\id_rsa ``` В ответе появится информация о правах на файл `id_rsa`. Например: ```bash C:\Users\User\.ssh\id_rsa User:(R) ``` Здесь права на файл `id_rsa` есть только у пользователя `User`. ### Проверить состояние службы SSH \{#check-ssh-status} 1. [Загрузите сервер в режиме восстановления и диагностики](/dedicated/troubleshooting/boot-to-recovery.mdx). 2. [Подключитесь к серверу через KVM-консоль](/dedicated/manage/connect-to-server.mdx#connect-via-kvm-console). 3. Проверьте состояние службы `sshd`: ```bash systemctl status sshd ``` В ответе появится информация о состоянии службы `sshd`. Например: ```bash Active: active (running) ``` 4. Если служба `sshd` остановлена, перезапустите ее: ```bash systemctl start sshd ``` ### Проверить порт SSH \{#check-ssh-port} По умолчанию SSH-сервер принимает подключения на порту `22`. 1. [Загрузите сервер в режиме восстановления и диагностики](/dedicated/troubleshooting/boot-to-recovery.mdx). 2. [Подключитесь к серверу через KVM-консоль](/dedicated/manage/connect-to-server.mdx#connect-via-kvm-console). 3. Проверьте, на каких портах служба `sshd` ожидает входящие подключения: ```bash ss -tlnp | grep sshd ``` В ответе появится информация о портах, на которых служба `sshd` принимает подключения. Например: ```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)) ``` Здесь `22` — порт, на котором SSH-сервер принимает подключения. Если вывод пустой, служба `sshd` не запущена или не принимает подключения. 4. Проверьте, какой порт указан в конфигурации SSH: ```bash sshd -T | grep ^port ``` В ответе появится информация о портах SSH-сервера. Например: ```bash port 2222 ``` 5. Если SSH-порты на шагах 3 и 4 не совпадают, перезапустите службу `sshd`: ```bash systemctl restart sshd ``` 6. Если на сервере изменен порт SSH, например на `2222`, нужно указывать его при подключении: ```bash ssh -p @ ``` Укажите: * `` — порт SSH; * `` — имя пользователя (логин). Можно посмотреть в [панели управления](https://my.selectel.ru/servers): в верхнем меню нажмите **Продукты** → **Выделенные серверы** → **Серверы** → страница сервера → вкладка **Операционная система** → поле **Логин**; * `` — публичный IP-адрес сервера. Можно посмотреть в [панели управления](https://my.selectel.ru/servers): в верхнем меню нажмите **Продукты** → **Выделенные серверы** → **Серверы** → страница сервера → вкладка **Операционная система** → поле **IP**. ### Проверить настройки файрвола \{#check-firewall} Убедитесь, что входящие подключения к SSH-порту разрешены правилами файрвола. 1. [Загрузите сервер в режиме восстановления и диагностики](/dedicated/troubleshooting/boot-to-recovery.mdx). 2. [Подключитесь к серверу через KVM-консоль](/dedicated/manage/connect-to-server.mdx#connect-via-kvm-console). 3. Для диагностики временно отключите файрвол и проверьте подключение: 3.1. Выключите файрвол: ```bash systemctl stop firewalld ``` 3.2. Подключитесь к серверу по SSH. Если удалось подключиться, проверьте правила файрвола. 3.3. После завершения диагностики включите файрвол: ```bash systemctl start firewalld ``` 4. Проверьте правила `iptables`: ```bash iptables -L -n -v ``` В ответе появится список правил. Например: ```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 ``` Здесь `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 на сервере \{#check-ssh-configuration} Если при подключении возникает ошибка `Permission denied (publickey)` или сервер не предлагает аутентификацию по ключу, проверьте настройки SSH-сервера. 1. [Загрузите сервер в режиме восстановления и диагностики](/dedicated/troubleshooting/boot-to-recovery.mdx). 2. [Подключитесь к серверу через KVM-консоль](/dedicated/manage/connect-to-server.mdx#connect-via-kvm-console). 3. Откройте файл конфигурации `/etc/ssh/sshd_config` текстовым редактором `vi`: ```bash vi /etc/ssh/sshd_config ``` 4. Убедитесь, что конфигурация содержит следующие параметры: ```bash PubkeyAuthentication yes AuthorizedKeysFile .ssh/authorized_keys ``` Здесь: * `PubkeyAuthentication` — в значении `yes` разрешает аутентификацию с помощью SSH-ключей; * `AuthorizedKeysFile` — путь к файлу с публичным SSH-ключом. 5. Если параметры `PubkeyAuthentication` и `AuthorizedKeysFile` отсутствуют, добавьте их. 6. Выйдите из текстового редактора `vi` с сохранением изменений: ```bash :wq ``` 7. Опционально: если на шаге 5 вы добавили параметры в файл конфигурации, проверьте его на ошибки: ```bash sshd -t ``` Если вывод пустой, конфигурация корректна. 8. Если на шаге 5 вы добавили параметры в файл конфигурации, перезапустите службу SSH: ```bash systemctl restart sshd ``` ### Проверить правила базового файрвола \{#check-basic-firewall} [Базовый файрвол](/basic-firewall/about/about-basic-firewall.mdx) обрабатывает каждый пакет изолированно — он не запоминает установленные соединения и не отслеживает состояние TCP-сессий. При анализе трафика файрвол проверяет только заголовок каждого пакета на соответствие правилам: * исходящие пакеты проверяются только по исходящим правилам; * входящие пакеты проверяются только по входящим правилам, даже если входящий пакет — это ответ на разрешенный исходящий запрос. Убедитесь, что правила базового файрвола не блокируют порт `22`. Подробнее в инструкции [Управлять правилами базового файрвола](/basic-firewall/manage/manage-rules.mdx).