Перейти к содержанию

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

В этой статье

Подключение к серверу по SSH из Linux

Для подключения к вашему серверу по SSH из Linux выполните следующие шаги:

  1. Проверьте наличие IP-адреса сервера. Убедитесь, что вы знаете IP-адрес сервера. Если вы не знаете его, вы можете найти его в панели управления Invapi.

  2. Установите SSH-клиент (если необходимо). SSH-клиент обычно уже установлен по умолчанию в большинстве дистрибутивов Linux. Чтобы проверить это, откройте терминал и выполните команду:

    ssh --version

    Если клиент установлен, вы увидите версию программы.

    Если SSH-клиент не установлен, установите его с помощью менеджера пакетов вашего дистрибутива:

    • Для Ubuntu/Debian: 
      sudo apt update
sudo apt install openssh-client
    • Для CentOS/RHEL: 
      sudo yum install openssh-clients

  3. Подключитесь к серверу. Для этого откройте терминал и введите следующую команду:

    ssh <имя пользователя>@<IP-адрес сервера>
    Например:

    ssh root@192.168.0.100

  4. Вводите пароль. После подключения система запросит ввод пароля для указанного пользователя. Логин и Пароль от сервера приходит вам на электронную почту при его сдаче.

Подключение к серверу по SSH из Windows

  1. Проверьте наличие IP-адреса сервера. Убедитесь, что вы знаете IP-адрес сервера. Если вы не знаете его, вы можете найти его в панели управления Invapi на сайте HOSTKEY.ru по ссылке https://invapi.hostkey.ru.

  2. В Windows 11 есть несколько способов подключения к серверу через SSH:

Использование OpenSSH (встроенное приложение)

  • С версии Windows 10 October 2018 Update SSH-клиент включен по умолчанию. Чтобы проверить, запустите PowerShell и выполните:

    ssh

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

  • Если SSH-клиент не установлен, включите его через Настройки:

    1. Перейдите в Настройки > Система > Дополнительные компоненты.

    2. Найдите Клиент OpenSSH и установите его.

  • Подключитесь к серверу. Для этого откройте PowerShell и введите следующую команду:

    ssh <имя пользователя>@<IP-адрес сервера>

    Например:

    ssh root@192.168.0.100

  • Введите пароль. После подключения система запросит ввод пароля для указанного пользователя. Логин и Пароль от сервера приходит вам на электронную почту при его сдаче.

Использование PuTTY (альтернативный клиент):

  • Скачайте PuTTY с официального сайта https://www.putty.org.
  • Запустите PuTTY и введите IP-адрес сервера в поле "Host Name (or IP address)".
  • Укажите тип соединения как SSH и нажмите Открыть.
  • Подключитесь к серверу:
    • Введите IP-адрес сервера в поле Host Name (or IP address).
    • Укажите порт SSH (обычно 22), если он изменен.
    • Нажмите Открыть. В появившемся окне введите имя пользователя и пароль.
  • Введите пароль. После подключения система запросит ввод пароля для указанного пользователя. Логин и Пароль от сервера приходит вам на электронную почту при его сдаче.

Примечание

  • Рекомендуется использовать SSH-ключи вместо паролей для более надежной аутентификации. Инструкции по настройке SSH-ключей можно найти в документации вашего дистрибутива или в нашей инструкции.
  • Если вы получаете ошибку Connection refused, убедитесь, что SSH-сервер работает на целевом сервере и порт 22 открыт в брандмауэре.

Диагностика проблем подключения к SSH

Выполнив данную диагностику, вы сможете понять, где теряется SSH-соединение: на вашей стороне, на сервере (sshd, файрвол, настройки) или по пути из Российской Федерации (провайдер, блокировки). Выполняйте шаги по порядку и сохраняйте вывод команд — он понадобится поддержке.

Внимание

В командах ниже замените SERVER_IP на IP-адрес вашего сервера. Команды на сервере выполняются от root или через sudo. Если SSH на сервер недоступен, зайдите через веб-консоль (VNC/KVM) в панели хостинга.

Шаг 1. Проверка с вашего компьютера

Цель — понять, доступен ли сервер вообще и отвечает ли порт 22. Команды выполняются на том компьютере, с которого вы подключаетесь.

  1. Доступность сервера по сети

    ping -c 4 SERVER_IP

    Ответа нет — это ещё не ошибка: ICMP часто закрыт файрволом. Главная проверка — следующая.

  2. Отвечает ли порт 22

    nc -vz -w 5 SERVER_IP 22

# если nc нет:
timeout 5 bash -c '</dev/tcp/SERVER_IP/22' && echo OPEN || echo CLOSED
    Результат Что значит
    succeeded / open Порт открыт, сеть в порядке — проблема в авторизации или настройках sshd (Шаг 4)
    Connection refused Сервер доступен, но на порту 22 никто не слушает или файрвол отвечает REJECT (Шаги 2–3)
    timed out Пакеты теряются: файрвол DROP, фильтр у хостера или блокировка по пути (Шаги 3 и 5)
    No route to host Нет маршрута до сервера или сервер выключен (проверьте его статус в панели)

  3. Точная проверка через nmap

    Показывает состояние порта и что на нём работает. Установка: sudo apt install nmap или sudo dnf install nmap.

    # состояние порта 22 и версия SSH-сервера
sudo nmap -Pn -sV -p 22 SERVER_IP

# с причиной состояния и маршрутом до сервера
sudo nmap -Pn -p 22 --reason --traceroute SERVER_IP

# сравнить 22 с другими портами (фильтруется только 22 или всё?)
sudo nmap -Pn -p 22,80,443,2222 --reason SERVER_IP

# алгоритмы SSH – если скрипт отработал, обмен ключами проходит
nmap -Pn -p 22 --script ssh2-enum-algos SERVER_IP

    -Pn нужен, чтобы nmap не считал сервер выключенным, если ping закрыт.

    Состояние в nmap Что значит
    open (reason syn-ack) Порт открыт, sshd отвечает; в -sV должна быть версия OpenSSH
    closed (reason reset) Сервер доступен, но sshd не слушает порт (Шаг 2)
    filtered (reason no-response) Пакеты теряются: файрвол DROP или блокировка по пути (Шаги 3 и 5)
    filtered (reason admin-prohibited) Файрвол отвечает отказом — правило REJECT на сервере или у хостера (Шаг 3)
    open, но -sV без версии или tcpwrapped TCP проходит, но SSH-баннер не доходит — TCP Wrappers, fail2ban или DPI (Шаги 4–5)

    Если в --traceroute ответы обрываются на узлах российского провайдера, а 80/443 при этом open — это сильный признак фильтрации именно порта 22. Сохраните вывод для поддержки: добавьте к команде -oN nmap.txt.

  4. Подробный лог подключения

    Показывает, на каком этапе обрыв:

    ssh -vvv -o ConnectTimeout=10 user@SERVER_IP 2>&1 | tee ssh_debug.log
    • Зависание на Connecting to — проблема сети.
    • Обрыв после Connection established (например, на SSH2_MSG_KEXINIT или Connection reset by peer) — типичный признак DPI-фильтрации или fail2ban.
    • Permission denied — сеть в порядке, неверный ключ или пароль.

  5. Маршрут до сервера именно по TCP-порту 22

    sudo traceroute -T -p 22 SERVER_IP

# или сводка по потерям:
sudo mtr -T -P 22 -r -c 50 SERVER_IP > mtr.txt

    Посмотрите, на каком узле ответы прекращаются. Обрыв внутри сети вашего провайдера или на границе Российской Федерации указывает на фильтрацию по пути, а не на сервер.

  6. Исключите свою сеть

    Повторите пункт 2 через мобильный интернет (раздача с телефона) и проверьте, не закрыт ли исходящий порт 22 на рабочем/корпоративном файрволе.

Шаг 2. Запущен ли SSH-сервер

Выполняется на сервере (через веб-консоль хостинга). В Debian/Ubuntu служба называется ssh, в CentOS/RHEL/Alma/Rocky — sshd.

  1. Статус службы

    systemctl status ssh || systemctl status sshd

    Должно быть active (running). Если inactive или failed — запустите и включите автозапуск:

    sudo systemctl enable --now ssh   # или sshd

    Если служба не стартует, причина будет в журнале.

  2. Пакет не установлен

    Ошибка Unit ssh.service could not be found:

    sudo apt install openssh-server   # Debian/Ubuntu
sudo dnf install openssh-server   # CentOS/RHEL/Alma/Rocky

  3. Какой порт и адрес слушает sshd

    sudo ss -tlnp | grep -E 'sshd|:22'
    Вывод Что значит
    0.0.0.0:22 или [::]:22 Всё в порядке, слушает все интерфейсы
    127.0.0.1:22 Слушает только локально — исправьте ListenAddress (Шаг 4)
    Другой порт, например :2222 Подключайтесь на него: ssh -p 2222 user@SERVER_IP
    Пусто sshd не запущен или не смог занять порт — см. журнал выше

  4. Ubuntu 22.10+ и socket-активация

    Там порт задаётся в ssh.socket, а не только в sshd_config. Проверка:

    systemctl status ssh.socket

    После смены порта выполните:

    sudo systemctl daemon-reload && sudo systemctl restart ssh.socket

  5. Проверка с самого сервера

    ssh -v localhost

    Работает локально, но не снаружи — дело в файрволе или сети (Шаги 3 и 5).

Шаг 3. Файрвол на сервере

На сервере обычно работает один из трёх файрволов: ufw (Ubuntu), firewalld (CentOS/RHEL) или чистые iptables/nftables. Проверьте все три — иногда активны сразу два.

Внимание

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

ufw

sudo ufw status verbose

# если 22/tcp нет в списке ALLOW:
sudo ufw allow 22/tcp

firewalld

sudo firewall-cmd --state
sudo firewall-cmd --list-all

# если ssh нет в services:
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reload

iptables / nftables

sudo iptables -L INPUT -n -v --line-numbers
sudo nft list ruleset

Ищите правила с dpt:22 или tcp dport 22 и действием DROP / REJECT, а также политику policy DROP без разрешающего правила для 22. Обратите внимание на правила, ограничивающие доступ по источнику (-s) или по стране (модули geoip, списки ipset): из-за них сервер может быть доступен отовсюду, кроме России.

Временно разрешить SSH в начале цепочки (до перезагрузки):

sudo iptables -I INPUT 1 -p tcp --dport 22 -j ACCEPT

Если после этого подключение заработало — причина найдена, сохраните правило через ваш файрвол (ufw/firewalld) или iptables-save.

Шаг 4. Настройки sshd и средства защиты

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

  1. Итоговая конфигурация sshd

    С учётом файлов в sshd_config.d/:

    sudo sshd -T | grep -Ei '^(port|listenaddress|permitrootlogin|passwordauthentication|pubkeyauthentication|allowusers|allowgroups|denyusers|maxstartups)'

    Проверьте:

    • port 22;
    • listenaddress 0.0.0.0 (не 127.0.0.1);
    • что ваш пользователь есть в allowusers, если этот параметр задан;
    • permitrootlogin и passwordauthentication — нужные вам значения.

  2. Проверка синтаксиса перед перезапуском

    После любой правки /etc/ssh/sshd_config сначала проверьте синтаксис, потом перезапускайте:

    sudo sshd -t && sudo systemctl restart ssh   # или sshd

  3. fail2ban

    Мог заблокировать ваш IP после неудачных попыток входа:

    sudo fail2ban-client status sshd

# разблокировать свой IP:
sudo fail2ban-client set sshd unbanip YOUR_IP

    Свой внешний IP можно узнать на клиентском компьютере командой curl -4 ifconfig.me. Аналогично проверьте CrowdSec или sshguard, если они установлены.

  4. TCP Wrappers (в старых системах)

    cat /etc/hosts.allow /etc/hosts.deny 2>/dev/null

    Строка sshd: ALL в hosts.deny блокирует всех, кто не указан в hosts.allow.

  5. Что видит сервер во время вашей попытки подключения

    Запустите на сервере, затем подключайтесь с клиента:

    sudo journalctl -u ssh -u sshd -f

# во втором окне – доходят ли пакеты до сервера:
sudo tcpdump -ni any tcp port 22 and host YOUR_IP
    • Если tcpdump ничего не показывает — пакеты не доходят до сервера, проблема по пути (Шаг 5).
    • Пакеты приходят, а в журнале sshd пусто — их отбрасывает файрвол сервера (Шаг 3).

Шаг 5. Недоступность именно из Российской Федерации

Если на сервере всё в порядке (Шаги 2–4), а пакеты из РФ не доходят, нужно сравнить доступность порта из РФ и из других стран.

  1. Проверка порта с внешних точек

    Сервис check-host.net → вкладка TCP port, введите SERVER_IP:22. Посмотрите результаты для российских и зарубежных узлов.

    Из РФ Из других стран Вывод
    Не работает Работает Фильтрация по пути из РФ или геоблокировка на стороне сервера/хостера
    Не работает Не работает Проблема на сервере — вернитесь к Шагам 2–4
    Работает Работает Проблема у вашего провайдера или в локальной сети

  2. Сравните провайдеров внутри РФ

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

  3. Проверьте, затронут ли именно порт 22

    На сервере временно добавьте второй порт в /etc/ssh/sshd_config (старая строка Port 22 остаётся):

    Port 22
Port 2222

    Разрешите 2222/tcp в файрволе (Шаг 3), выполните:

    sudo sshd -t && sudo systemctl restart ssh

    И подключитесь:

    ssh -p 2222 user@SERVER_IP

    На SELinux-системах (CentOS/RHEL) дополнительно:

    sudo semanage port -a -t ssh_port_t -p tcp 2222

    Работает на 2222, но не на 22 — фильтруется именно стандартный порт.

  4. Признаки DPI-фильтрации

    TCP-соединение устанавливается (nc показывает open), но ssh -vvv обрывается на обмене ключами; или соединение работает пару секунд и зависает. В этом случае настройки сервера ни при чём — передайте логи в поддержку.

  5. Проверьте реестр блокировок

    Поиск по IP на blocklist.rkn.gov.ru. Если IP или его подсеть там есть — решение только сменой IP-адреса через поддержку хостинга.

Что прислать в сообщении в техподдержку

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

  • IP сервера и ваш внешний IP (curl -4 ifconfig.me), город и провайдер;
  • файл nmap.txt и результат nc -vz -w 5 SERVER_IP 22;
  • файл ssh_debug.log (Шаг 1, пункт 4);
  • файл mtr.txt или вывод traceroute -T -p 22;
  • вывод с сервера: systemctl status ssh, ss -tlnp | grep :22, правила файрвола (ufw status verbose / firewall-cmd --list-all / iptables -L INPUT -n -v);
  • ссылку на результат проверки TCP-порта на check-host.net;
  • работает ли подключение через мобильный интернет и на порту 2222 (если проверяли).

Внимание

Не отправляйте пароли и приватные ключи. Лог ssh -vvv их не содержит, но перед отправкой просмотрите его.

question_mark
Я могу вам чем-то помочь?
question_mark
ИИ Помощник ×