Почему не работает SSH-подключение к VPS и как это исправить

Время чтения: 14 мин. Обновлено: 12 ноября 2026

Выбирайте VPS

Если вы в поиске надежного провайдера VPS, то смотрите подбору лучших VPS.

Перейти

SSH позволяет удалённо подключаться к виртуальному серверу (VPS) и управлять им через командную строку. Однако иногда подключение не устанавливается: программа выдаёт ошибку, долго ожидает ответа или отклоняет пароль.

Причина может быть как на самом сервере, так и на компьютере пользователя. Например, неправильно указан IP-адрес, закрыт порт 22, не работает SSH-сервис или запрещён вход по паролю.

Разберём основные ошибки SSH и способы их устранения. Для примеров будем использовать Ubuntu 24.04 LTS, а для подключения — стандартный SSH-клиент и PuTTY.

Команды для проверки подключения выполняются на вашем компьютере. Команды с sudo ниже выполняются на VPS через консоль провайдера или действующий SSH-сеанс; для них нужны права администратора.

Основные причины ошибок SSH

SSH-подключение может не работать по нескольким причинам:

  • Неправильный IP-адрес или порт. Клиент пытается подключиться не к тому серверу или использует неверный порт.
  • SSH-сервис не работает. На VPS не установлен или не запущен OpenSSH Server.
  • Порт заблокирован. Подключение ограничено брандмауэром сервера, правилами провайдера или локальной сетью.
  • Неверные данные авторизации. Указан неправильный пользователь, пароль или SSH-ключ.
  • Изменены настройки SSH. Например, отключён вход по паролю или запрещено подключение пользователя root.
  • Несовместимость SSH-клиента и сервера. Старый сервер может использовать алгоритмы, которые современные SSH-клиенты по умолчанию не поддерживают.
  • Сервер недоступен. VPS выключен, завис или имеет проблемы с сетью.

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

Проверка IP-адреса и порта

Первое, что нужно проверить, — правильность данных для подключения.

Откройте панель управления VPS у провайдера и найдите публичный IP-адрес сервера. Сравните его с адресом, который указан в SSH-клиенте.

Для подключения из терминала используется команда:

ssh root@203.0.113.10

Здесь root — имя пользователя, а 203.0.113.10 — пример IP-адреса. Замените их своими данными.

По умолчанию SSH использует TCP-порт 22. Если провайдер указал другой порт или вы изменили его самостоятельно, добавьте параметр -p:

ssh -p 2222 root@203.0.113.10

В этом примере подключение выполняется через порт 2222.

Если вы используете PuTTY, укажите IP-адрес VPS в поле Host Name (or IP address), проверьте поле Port и выберите тип соединения SSH.

После проверки нажмите Open.

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

Проверка доступности SSH-порта

Даже если IP-адрес указан правильно, компьютер может не иметь доступа к SSH-порту.

В Windows 10 и 11 откройте PowerShell и выполните:

Test-NetConnection 203.0.113.10 -Port 22

Замените IP-адрес на адрес своего VPS. Если SSH работает на другом порту, укажите его вместо 22.

Найдите в результате строку:

TcpTestSucceeded : True

Значение True означает, что TCP-соединение с указанным портом удалось установить. Это ещё не подтверждает успешную SSH-авторизацию.

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

В Linux и macOS можно попробовать подключение с подробным выводом:

ssh -v root@203.0.113.10

Параметр -v показывает этапы подключения и помогает определить, на каком из них возникает ошибка.

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

Проверка SSH-сервиса на VPS

Если подключение не устанавливается, необходимо проверить работу SSH непосредственно на сервере.

Для этого потребуется доступ через веб-консоль, VNC или другой способ управления VPS, предоставленный хостинг-провайдером.

В Ubuntu выполните:

sudo systemctl status ssh

Команда показывает состояние SSH-сервиса. Если он запущен обычным способом, в выводе будет строка:

Active: active (running)

В Ubuntu 24.04 LTS SSH может запускаться автоматически при поступлении подключения. Поэтому дополнительно проверьте:

sudo systemctl status ssh.socket

Если отображается active (listening), система ожидает SSH-подключения. При такой настройке неактивный ssh.service сам по себе не обязательно является ошибкой.

Если SSH-сервис отсутствует, команда проверки состояния может показать Unit ssh.service could not be found. Проверьте также ssh.socket.

Если OpenSSH Server действительно не установлен, установите его через консоль сервера:

sudo apt update
sudo apt install openssh-server

Для запуска SSH-сервиса в обычной конфигурации используется:

sudo systemctl start ssh

Если система использует ssh.socket, проверьте его состояние и при необходимости запустите:

sudo systemctl start ssh.socket

Не меняйте способ запуска без необходимости.

Проверка настроек SSH

Ошибки в конфигурации могут мешать запуску SSH.

Проверьте её командой:

sudo sshd -t

Команда проверяет конфигурацию SSH на ошибки, но не проверяет доступность сервера по сети. Если ошибок нет, она обычно ничего не выводит; иначе появится сообщение с описанием проблемы.

Основной файл настроек расположен по пути:

/etc/ssh/sshd_config

Дополнительные настройки могут находиться в каталоге:

/etc/ssh/sshd_config.d/

Изменения в этих файлах могут влиять на порт, разрешённые способы входа и доступ отдельных пользователей.

В Ubuntu 24.04 LTS при использовании ssh.socket порт прослушивания также зависит от настроек systemd. Поэтому изменение параметра Port в конфигурации SSH не всегда приводит к изменению фактического порта.

Не перезапускайте SSH после редактирования настроек, пока не проверите конфигурацию. Ошибка может привести к потере удалённого доступа.

Если сервер использует старые алгоритмы SSH

Иногда новый SSH-клиент не может подключиться к старому серверу: клиент и сервер не могут согласовать алгоритмы для защищённого соединения.

В таком случае может появиться ошибка:

no matching host key type found

Если в сообщении Their offer указан только ssh-rsa, можно временно разрешить этот устаревший алгоритм для одного подключения:

ssh -o HostKeyAlgorithms=+ssh-rsa root@203.0.113.10

Параметр разрешает использование старого алгоритма подписи ключа сервера RSA с SHA-1. Применяйте его только при соответствующей ошибке.

Если соединение устанавливается, но вход по RSA-ключу отклоняется из-за несовместимости алгоритма подписи, в отдельных случаях может потребоваться:

ssh -o PubkeyAcceptedAlgorithms=+ssh-rsa root@203.0.113.10

Этот параметр относится к авторизации пользователя по публичному ключу, а не к проверке ключа сервера.

При ошибке no matching key exchange method found проблема связана уже с согласованием алгоритма обмена ключами. Приведённые выше параметры не обязательно помогут.

Использование ssh-rsa с SHA-1 снижает безопасность. Надёжнее обновить SSH-сервер и настроить современные алгоритмы. Не включайте устаревшие алгоритмы для всех серверов и обязательно проверяйте отпечаток ключа сервера.

Проверка брандмауэра и сетевых ограничений

Брандмауэр (firewall) контролирует входящие и исходящие сетевые соединения. Если он блокирует SSH-порт, подключиться к VPS не получится, даже когда SSH-сервис работает.

В Ubuntu часто используется UFW. Проверить его состояние можно командой:

sudo ufw status

Если отображается Status: inactive, UFW отключён и не блокирует подключения.

Если брандмауэр активен, проверьте, разрешён ли входящий трафик на SSH-порт. Например:

22/tcp    ALLOW    Anywhere

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

sudo ufw allow 22/tcp

Команда разрешает входящие TCP-соединения на порт 22 для любых IP-адресов, включая IPv6 при включённой поддержке IPv6 в UFW. Если SSH использует другой порт, укажите его номер.

При необходимости доступ можно ограничить только доверенными IP-адресами.

Важно: не отключайте брандмауэр полностью ради проверки SSH. Сначала изучите действующие правила и убедитесь, что проблема действительно связана с ними.

Некоторые VPS-провайдеры также предоставляют сетевой брандмауэр в панели управления.

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

Проверка правил iptables и nftables

Даже при отключённом UFW доступ может ограничиваться другими правилами фильтрации.

Через консоль VPS посмотрите правила IPv4:

sudo iptables -L INPUT -n -v --line-numbers

Команда показывает правила цепочки INPUT, которая обычно отвечает за входящие пакеты, предназначенные самому серверу. Она ничего не изменяет.

Обратите внимание на обозначения:

  • ACCEPT — разрешить прохождение пакета.
  • DROP — отбросить пакет без ответа.
  • REJECT — отклонить пакет, обычно с отправкой уведомления.

Проверьте политику цепочки INPUT, ограничения для TCP-порта SSH и вашего IP-адреса. Правила обрабатываются в определённом порядке, поэтому важно учитывать не только отдельный запрет, но и правила перед ним.

Для IPv6 используется команда:

sudo ip6tables -L INPUT -n -v --line-numbers

Эти команды не показывают абсолютно все возможные механизмы фильтрации.

В Ubuntu 24.04 также могут применяться правила nftables. Их можно просмотреть командой:

sudo nft list ruleset

Проверьте правила входящего трафика и запреты для нужного порта. Команда может отсутствовать, если утилита nft не установлена.

Если на сервере используются разные средства фильтрации, разрешение в одном из них не обязательно отменяет запрет в другом.

Не удаляйте правила наугад: они могут защищать сервер или использоваться другими службами.

Блокировка IP-адреса или порта в сети

Иногда SSH недоступен из-за фильтрации трафика вне VPS — например, у интернет-провайдера, в корпоративной сети или на промежуточном участке маршрута.

В России среди возможных механизмов сетевой фильтрации используются ТСПУ (технические средства противодействия угрозам). Однако по одному сообщению Connection timed out нельзя установить, что причина именно в ТСПУ.

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

Также проверьте доступность VPS через консоль провайдера и работоспособность SSH-сервиса.

Если соединение проходит из одной сети, но не проходит из другой, возможна проблема на сетевом пути или фильтрация по адресу либо порту. Это не доказывает конкретный механизм блокировки.

Не меняйте SSH-порт наугад: сначала исключите ошибки настроек сервера и брандмауэра.

При подозрении на сетевую блокировку обратитесь к своему интернет-провайдеру и провайдеру VPS, указав IP-адрес, порт, время проверки и результаты из разных сетей.

Ошибки пароля и SSH-ключей

Если SSH-соединение устанавливается, но сервер не разрешает вход, проблема обычно связана с авторизацией.

Например, может появиться сообщение: Permission denied (publickey,password).

Оно означает, что сервер отклонил предложенные способы авторизации.

Неправильный логин или пароль

Проверьте имя пользователя. Не все VPS позволяют подключаться под root. Например, в некоторых образах Ubuntu используется пользователь ubuntu.

Убедитесь, что пароль введён правильно. При вводе пароля в терминале символы обычно не отображаются — это нормальное поведение.

Также учитывайте, что на сервере может быть отключён вход по паролю. В таком случае потребуется SSH-ключ или другой разрешённый способ авторизации.

Если создан новый пользователь вместо root

Новый пользователь не всегда сможет сразу войти по SSH.

Сначала убедитесь, что учётная запись существует. Например, для пользователя adminuser через консоль VPS выполните:

id adminuser

Команда должна показать сведения об учётной записи.

Если пользователь ещё не создан, администратор может создать его командой:

sudo adduser adminuser

Она предложит задать пароль и другие необязательные данные.

Проверьте, какая оболочка назначена пользователю:

getent passwd adminuser

В последнем поле результата должна быть указана оболочка, подходящая для интерактивного входа, например /bin/bash.

Если указана /usr/sbin/nologin, обычная работа через SSH-терминал будет недоступна.

Также проверьте, не заблокирована ли учётная запись или пароль и не ограничен ли вход параметрами AllowUsers, DenyUsers, AllowGroups или DenyGroups в настройках SSH.

Если используются списки разрешённых пользователей или групп, новый пользователь должен соответствовать этим правилам.

Для обычного SSH-входа добавлять пользователя в группу sudo не требуется. Эта группа нужна для выполнения административных команд.

Если разрешён вход по паролю, у пользователя должен быть установлен действующий пароль, а настройки SSH должны допускать такой способ входа.

Если сервер принимает только SSH-ключи, добавьте публичный ключ в файл:

/home/adminuser/.ssh/authorized_keys

Убедитесь, что каталог .ssh и файл authorized_keys принадлежат пользователю adminuser и имеют правильные права доступа. Приватный ключ остаётся на вашем компьютере.

Подключение выполняется с именем нового пользователя:

ssh adminuser@203.0.113.10

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

Проблема с SSH-ключом

При авторизации по ключу на компьютере пользователя хранится закрытый (приватный) ключ, а на сервере — соответствующий открытый (публичный).

Если ключи не совпадают или сервер не может прочитать файл с разрешёнными ключами, вход будет отклонён.

Для пользователя root публичные ключи обычно находятся в файле:

/root/.ssh/authorized_keys

Проверьте, что в нём присутствует нужный публичный ключ.

Также важны права доступа. Для каталога .ssh и файла authorized_keys пользователя root можно использовать:

sudo chmod 700 /root/.ssh
sudo chmod 600 /root/.ssh/authorized_keys

Первая команда разрешает доступ к каталогу только владельцу. Вторая ограничивает чтение и изменение файла его владельцем.

Убедитесь также, что каталог и файл принадлежат root: неправильный владелец может мешать входу.

Для другого пользователя аналогично проверьте его домашний каталог, владельца файлов и соответствующие права.

Если подключение выполняется через PuTTY, убедитесь, что в настройках выбран правильный приватный ключ. Формат ключа должен поддерживаться используемой версией программы.

Не передавайте приватные SSH-ключи посторонним и не размещайте их в открытом доступе.

Что делать, если SSH недоступен?

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

Для просмотра последних сообщений SSH в Ubuntu выполните:

sudo journalctl -u ssh.service -u ssh.socket -n 50 --no-pager

Команда показывает до 50 последних записей журналов указанных компонентов. В них могут содержаться сведения о проблемах запуска SSH и подключениях.

Если нужных записей нет, проверьте другие системные журналы. В Ubuntu сообщения об авторизации также могут находиться в /var/log/auth.log, если соответствующее журналирование настроено.

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

Перезагрузку стоит рассматривать только после проверки состояния сервера. Она прерывает работу запущенных приложений и не гарантирует устранения проблемы.

Если провайдер предоставляет Rescue Mode — специальный режим восстановления, — с его помощью можно получить доступ к файлам и настройкам VPS при проблемах с основной системой. Этот режим требует дополнительных знаний и доступен не на всех VPS.

Как определить причину по сообщению об ошибке?

SSH-клиент обычно показывает сообщение, которое помогает определить направление поиска.

Ошибка

Возможная причина

Connection timed out

Сервер не отвечает, трафик блокируется или теряется в сети

Connection refused

На указанном адресе и порту соединение отклоняется

Permission denied

Неправильные данные авторизации или запрет входа

Connection reset by peer

Соединение принудительно закрыто другой стороной

No route to host

Проблема с маршрутом или сетевой доступностью

Host key verification failed

Ключ сервера не совпадает с ранее сохранённым или не прошёл проверку

no matching host key type found

SSH-клиент и сервер не согласовали алгоритм ключа сервера

no matching key exchange method found

Не удалось согласовать алгоритм обмена ключами

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

Отдельного внимания требует ошибка Host key verification failed. Она может появиться после переустановки VPS, смены SSH-ключей сервера или подключения к другому серверу по тому же IP-адресу.

Однако изменение ключа также может указывать на попытку перехвата соединения. Поэтому сначала необходимо проверить новый отпечаток ключа через доверенный источник. Удалять старую запись без такой проверки небезопасно.

Что проверить в первую очередь?

Если SSH перестал работать, выполняйте диагностику последовательно:

  1. Убедитесь, что VPS включён, а IP-адрес и порт указаны правильно.
  2. Проверьте доступность SSH-порта со своего компьютера.
  3. Если порт недоступен, проверьте SSH-сервис через консоль провайдера.
  4. Проверьте правила брандмауэра и сетевые ограничения.
  5. Если соединение устанавливается, но вход отклоняется, проверьте авторизацию.
  6. Если SSH-клиент сообщает о несовместимости алгоритмов, проверьте версию SSH-сервера и поддерживаемые алгоритмы.
  7. Если причина остаётся неизвестной, изучите журналы SSH.

Такой порядок позволяет избежать лишних изменений в настройках сервера и быстрее найти источник проблемы.

Комментарии ()

    Популярные статьи