Как включить SSH в Ubuntu и защитить сервер

Включаем SSH в Ubuntu: установка, запуск, открытие межсетевого экрана

За SSH в Ubuntu отвечает пакет openssh-server. Ubuntu Server предлагает установить его во время инсталляции, и почти каждый облачный образ или образ VPS поставляется с уже работающим демоном; Ubuntu Desktop не устанавливает его вовсе.

1. Установите openssh-server

sudo apt update
sudo apt install -y openssh-server

Если пакет уже установлен, apt сообщит об этом и ничего не изменит. При установке также регистрируется профиль приложения UFW с именем OpenSSH, который понадобится на шаге 3.

2. Включите и запустите службу

sudo systemctl enable --now ssh
systemctl status ssh

В Ubuntu юнит называется ssh, а sshd служит псевдонимом. enable --now запускает демон сразу и при каждой загрузке. Начиная с Ubuntu 22.10 sshd активируется через сокет: порт 22 занимает ssh.socket, который запускает ssh.service при первом входящем подключении, поэтому статус inactive (dead) с пометкой TriggeredBy: ssh.socket сразу после установки является нормой, порт открыт. Более общую картину даёт материал о просмотре списка служб через systemctl.

3. Разрешите SSH в UFW

В Ubuntu UFW по умолчанию выключен. Если вы его включаете, сначала разрешите SSH: включение межсетевого экрана до создания правила является классическим способом потерять доступ к удалённой машине.

sudo ufw allow OpenSSH
sudo ufw enable
sudo ufw status

ufw allow OpenSSH использует профиль приложения и открывает 22/tcp. Если позже вы перенесёте sshd, разрешите новый порт командой sudo ufw allow 2222/tcp и удалите старое правило. Адрес сервера покажет hostname -I.

Подключение из Windows, macOS или Linux

Во всех современных настольных операционных системах клиент OpenSSH встроен, и синтаксис везде одинаковый:

ssh username@SERVER_IP
ssh -p 2222 username@SERVER_IP      # non-default port

• Windows 10 и 11: откройте PowerShell или Windows Terminal и введите команду; клиент OpenSSH входит в состав Windows с 2018 года (версия 1809). Если команда ssh не распознаётся, добавьте компонент через «Параметры > Приложения > Дополнительные компоненты».
• macOS: та же команда в Terminal.
• Linux: любой терминал; в Ubuntu пакет openssh-client установлен по умолчанию.

При первом подключении подтвердите отпечаток ключа сервера ответом yes: он сохранится в ~/.ssh/known_hosts, и вы получите предупреждение, если он когда-нибудь изменится. Затем введите пароль учётной записи; в следующем разделе мы заменим его ключом.

Переходим на аутентификацию по ключам

Именно вход по паролю круглосуточно перебирают ботнеты; с ключами такие попытки бессмысленны. Сгенерируйте пару ключей Ed25519 на своём компьютере, а не на сервере:

ssh-keygen -t ed25519 -C "laptop-2026"

Согласитесь с путём по умолчанию (~/.ssh/id_ed25519) и задайте парольную фразу: она шифрует закрытый ключ на диске, а агент SSH позволяет вводить её один раз за сеанс. Вашу машину покидает только файл .pub.

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

В macOS и Linux это делается одной командой ssh-copy-id, которая в последний раз спросит пароль:

ssh-copy-id -i ~/.ssh/id_ed25519.pub username@SERVER_IP

В сборке OpenSSH для Windows команды ssh-copy-id нет, поэтому передайте ключ через конвейер прямо из PowerShell:

type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh username@SERVER_IP "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Оба способа дописывают ключ в файл ~/.ssh/authorized_keys этого пользователя. Права доступа важны: sshd молча игнорирует файл, если у каталога ~/.ssh права не 700 или authorized_keys доступен на запись кому-то кроме владельца. Из нового терминала команда ssh username@SERVER_IP теперь должна пускать вас без пароля учётной записи. Не переходите к следующему разделу, пока это не заработает.

Усиливаем sshd_config: без паролей, без root, со списком разрешённых пользователей

Во время правки держите текущий сеанс открытым: если новая конфигурация что-то сломает, это ваш путь обратно. Файл /etc/ssh/sshd_config начинается со строки Include /etc/ssh/sshd_config.d/*.conf, а sshd запоминает первое прочитанное значение каждого параметра, поэтому drop-in перекрывает всё, что идёт ниже в основном файле. Кроме того, облачные образы часто содержат /etc/ssh/sshd_config.d/50-cloud-init.conf с директивой PasswordAuthentication yes, и именно поэтому правка основного файла так часто ни на что не влияет. Решение даёт файл drop-in, имя которого сортируется первым:

sudo nano /etc/ssh/sshd_config.d/00-hardening.conf

Вставьте следующее, заменив username на свой логин:

PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
PermitRootLogin no
AllowUsers username
MaxAuthTries 3
LoginGraceTime 30
X11Forwarding no
ClientAliveInterval 300
ClientAliveCountMax 2

Директива PermitRootLogin no предполагает, что у вас есть непривилегированная учётная запись с правами sudo. Если до сих пор вы работали под root, создайте пользователя с sudo в Linux и скопируйте ему свой ключ, прежде чем применять файл. Затем проверьте синтаксис, перезагрузите конфигурацию и посмотрите, какие значения sshd действительно использует после слияния всех include-файлов; именно это выводит sshd -T:

sudo sshd -t
sudo systemctl reload ssh
sudo sshd -T | grep -Ei 'passwordauthentication|permitrootlogin|allowusers|port'

Откройте второй терминал и войдите по ключу, прежде чем закрывать первый. Что делает каждая директива:

У keepalive есть и клиентская сторона: параметр ServerAliveInterval 60 в файле ~/.ssh/config на вашей машине не даёт NAT-маршрутизаторам обрывать простаивающие сеансы.

Смена порта SSH не является защитой

Совет перенести sshd с порта 22 очень популярен. На деле он даёт лишь меньше строк в логах. Массовые сканеры проходят все 65 535 портов и находят sshd на 2222 за считаные часы; тот, кто целится именно в вас, найдёт его за секунды с помощью nmap. Защиту дают ключи, запрет входа для root, список разрешённых пользователей и fail2ban; порт остаётся косметикой. На нагруженном сервере смена порта всё же помогает сохранить журнал аутентификации читаемым. Просто никогда не считайте её уровнем защиты.

Если всё же меняете, соблюдайте порядок: откройте новый порт в UFW, измените порт, перезапустите службу, проверьте из второго терминала и только потом удалите старое правило. Раскомментируйте строку #Port 22 в /etc/ssh/sshd_config, укажите новый порт, затем:

sudo ufw allow 2222/tcp
sudo sshd -t
sudo systemctl daemon-reload
sudo systemctl restart ssh.socket    # Ubuntu 22.10 and later
sudo systemctl restart ssh           # Ubuntu 22.04 and earlier

В выпусках с активацией через сокет порт выбирает не sshd, а сокет-юнит; в Ubuntu есть генератор systemd, который во время daemon-reload читает Port из конфигурации sshd и обновляет ssh.socket. Проверьте результат командой sudo ss -tlnp | grep sshd; разобраться в выводе поможет руководство о проверке открытых портов в Linux. Если sshd упорно остаётся на 22, отключите активацию через сокет и позвольте службе занять порт самостоятельно: sudo systemctl disable --now ssh.socket && sudo systemctl enable --now ssh.service. Как только ssh -p 2222 заработает из нового терминала, выполните sudo ufw delete allow OpenSSH.

Добавляем fail2ban и рассматриваем двухфакторную аутентификацию

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

sudo apt install -y fail2ban
sudo nano /etc/fail2ban/jail.local

Поместите в файл следующее:

[sshd]
enabled = true
port = ssh
backend = systemd
maxretry = 5
findtime = 10m
bantime = 1h

sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

Никогда не правьте jail.conf: он перезаписывается при обновлениях, а jail.local его переопределяет. Значение port = ssh разрешается через /etc/services, поэтому при переносе демона укажите port = 2222. Параметр backend = systemd читает журнал напрямую и работает независимо от того, пишет ли ваш образ файл /var/log/auth.log. Команда fail2ban-client status sshd показывает заблокированные адреса, а sudo fail2ban-client set sshd unbanip 203.0.113.7 снимает блокировку с одного из них. По умолчанию правила fail2ban обрабатываются раньше правил UFW, так что оба инструмента прекрасно уживаются.

Двухфакторная аутентификация

Если ключа с парольной фразой мало, пакет libpam-google-authenticator добавляет к ключу одноразовый код по времени: установите его, запустите google-authenticator от имени рабочего пользователя, добавьте строку auth required pam_google_authenticator.so в /etc/pam.d/sshd (и закомментируйте там строку @include common-auth), затем задайте в sshd KbdInteractiveAuthentication yes и AuthenticationMethods publickey,keyboard-interactive. Реальный выигрыш на случай кражи ноутбука, но и ещё одна вещь, которую можно потерять: резервные коды храните вне сервера.

Диагностика: connection refused, timed out, permission denied

Connection refused

Сервер ответил, но на этом порту никто не слушает: sshd остановлен, привязан к другому порту, либо вы указали неверный порт. Через консоль провайдера выполните systemctl status ssh и sudo ss -tlnp | grep ssh. Синтаксическая ошибка вообще не даёт sshd запуститься: sudo sshd -t покажет проблемную строку, а journalctl -u ssh -n 50 покажет последний запуск.

Connection timed out

Пакеты отбрасываются, а не отклоняются, и это почти всегда межсетевой экран: UFW без разрешающего правила (sudo ufw status verbose), группа безопасности в панели провайдера или ваша собственная сеть, блокирующая исходящий порт 22; проверить это можно, раздав интернет с телефона. Команда ssh -v username@SERVER_IP покажет, на каком этапе застревает рукопожатие.

Permission denied (publickey)

Сервер доступен и отклоняет вас. Проверьте по порядку: имя пользователя; содержит ли authorized_keys этого пользователя тот ключ, который вы предъявляете (ssh -i ~/.ssh/id_ed25519 -v принудительно выбирает конкретный ключ); права на каталог ~/.ssh; и не отсутствует ли логин в списке AllowUsers. На сервере причину назовёт journalctl -u ssh -n 30: сообщение Authentication refused: bad ownership or modes указывает на описанную выше проблему с правами.

Предупреждение о ключе хоста

Сообщение WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED после переустановки системы ожидаемо: выполните ssh-keygen -R SERVER_IP и подключитесь заново. Если вы ничего не переустанавливали, выясните причину, прежде чем где-либо вводить пароль. Потеряли доступ полностью? Вернуться поможет консоль провайдера.

Всё вышесказанное предполагает машину, где у вас есть root и где можно позволить себе сломать sshd и починить его из консоли. Linux VPS от rdp.monster и есть такая машина: полный root-доступ, выделенные CPU и RAM, безлимитный трафик (fair-use), без KYC, оплата криптовалютой или фиатом, от $8.99 в месяц, а сервер готов примерно через 10 секунд после подтверждения оплаты, и времени более чем достаточно, чтобы разложить ключи до того, как первый сканер найдёт порт 22.

Часто задаваемые вопросы

Включён ли SSH в Ubuntu по умолчанию?

В Ubuntu Desktop нет, а в Ubuntu Server и большинстве облачных образов да.

Ubuntu Desktop устанавливает только клиент SSH, поэтому на порту 22 никто не слушает, пока вы не выполните sudo apt install openssh-server. Ubuntu Server во время установки спрашивает, ставить ли сервер OpenSSH, и заодно может импортировать ваши ключи с GitHub или Launchpad. В облачных образах и образах VPS пакет openssh-server почти всегда уже установлен, включён и принимает подключения, потому что иначе провайдер просто не сможет передать вам машину. Проверить состояние можно командой systemctl status ssh.

Как проверить, работает ли SSH в Ubuntu?

Выполните systemctl status ssh, затем убедитесь через ss, что порт 22 прослушивается.

systemctl status ssh показывает, активна ли служба и включена ли она в автозагрузку. Поскольку Ubuntu 22.10 и новее используют активацию через сокет, служба вполне законно может отображаться как inactive (dead) с пометкой TriggeredBy: ssh.socket, когда никто не подключён, поэтому надёжнее команда sudo ss -tlnp | grep ssh: строка с 0.0.0.0:22 или [::]:22 означает, что SSH слушает порт. С другой машины проверку от начала до конца выполнит ssh -v username@SERVER_IP.

Безопасно ли оставлять SSH на порту 22?

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

Порт 22 постоянно притягивает автоматические попытки входа, но против сервера с PasswordAuthentication no и парой ключей они бесполезны, а fail2ban убирает большую часть шума. Перенос sshd на 2222 или 22222 скрывает его лишь от самых ленивых сканеров: nmap и masscan находят его за минуты, а глобальные индексы интернета всё равно его перечисляют. Считайте нестандартный порт мерой гигиены логов, а не средством защиты, и никогда не отказывайтесь от ключей на том основании, что вы сменили порт.

Чем отличаются ssh и sshd в Ubuntu?

ssh служит клиентской программой, sshd служит серверным демоном, юнит которого в Ubuntu называется ssh, а sshd является псевдонимом.

ssh представляет собой клиент, который вы запускаете на своём ноутбуке, чтобы открыть соединение; он входит в пакет openssh-client. sshd представляет собой демон, отвечающий на сервере, из пакета openssh-server; он настраивается в /etc/ssh/sshd_config (клиент читает ssh_config). В Ubuntu и Debian юнит systemd называется ssh.service, а sshd.service объявлен псевдонимом, поэтому systemctl restart ssh и systemctl restart sshd делают одно и то же; в Fedora, RHEL и Arch юнит называется просто sshd.