Как настроить SSH-доступ на Ubuntu 24.04

Содержание

Настройка SSH-доступа — основа безопасности любого сервера на Ubuntu 24.04. Из статьи вы узнаете, как правильно настроить OpenSSH: как генерировать ключи, отключить вход по паролю, ограничить доступ по IP-адресам, сменить стандартный порт и настроить защиту от брутфорс-атак.

Первое, с чего стоит начать после установки Ubuntu 24.04 LTS на сервер или VPS, — это настройка SSH-доступа. Через SSH происходит установка приложений, обновление конфигураций и удалённое администрирование сервера.

Ubuntu 24.04 в большинстве случаев включает OpenSSH-сервер по умолчанию, особенно если вы разворачивали серверный образ, но его конфигурация далека от оптимальной. В этой статье мы разберём, как настроить SSH-доступ в Ubuntu 24.04 LTS правильно: от включения и проверки службы до создания ключей, ограничения логина по IP и добавления защиты от брутфорса.

Аренда VPS/VDS от 219 руб/месяц

Преимущества VPS в AdminVPS:

✓ Бесплатное администрирование

✓ Только быстрые NVMe-диски

✓ Защита от DDoS-атак

✓ Быстрая техподдержка

Аренда VPS/VDS виртуального сервера от AdminVPS — это прозрачная и честная услуга с доступной ценой

Проверка и запуск SSH-сервиса

Сначала стоит проверить, установлен ли на сервере OpenSSH. Чтобы убедиться, есть ли нужный пакет, выполните следующую команду:

dpkg -l | grep openssh-server

Если в выводе будет строка с openssh-server, значит пакет установлен. Если нет — придётся установить его вручную. Для этого выполните:

sudo apt update
sudo apt install openssh-server

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

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

sudo systemctl status ssh

Если вы увидите строку Active: active (running) — всё работает. Если статус другой, например inactive или failed, нужно перезапустить сервис:

sudo systemctl restart ssh

Команда restart останавливает sshd, если он уже работает, и запускает заново — это полезно при изменении конфигурации. Если вы только что установили openssh-server, можете использовать:

sudo systemctl enable ssh --now

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

Ещё один способ убедиться, что порт 22 действительно слушается, — использовать ss:

ss -tnlp | grep ssh

Расшифровка команды:

-t — показывает только TCP-соединения;
-n — не пытается разрешать имена хостов и портов (вывод быстрее и чище);
-l — показывает только прослушиваемые сокеты;
-p — показывает PID и имя процесса, который слушает порт.

Если в выводе вы видите, что sshd слушает на 0.0.0.0:22 или [::]:22 — значит, подключение доступно извне.

Если вы уже настроили брандмауэр (например, через ufw), не забудьте разрешить порт 22:

sudo ufw allow ssh

Эта команда добавит правило для порта, обозначенного как ssh (обычно это порт 22).

После этого сервер готов принимать подключения.

Базовая настройка: отключение входа по паролю и включение авторизации по SSH-ключу

Почти каждый сканер сети первым делом проверяет, открыт ли порт 22, и если он отвечает — сразу начинается автоматический перебор логина и пароля. Даже сложный пароль не гарантирует безопасность: автоматические сканеры могут перебрать его со временем. Лучшее решение в такой ситуации — вообще отключить возможность входа по паролю и использовать только SSH-ключи.

Начните с генерации ключей. Создайте пару ключей (id_rsa и id_rsa.pub) на вашем клиентском компьютере:

ssh-keygen -t ed25519 -C "ваш.email@example.ru"

Здесь:

-t ed25519 — указывает тип ключа. Формат ED25519 современнее и безопаснее RSA, при этом он быстрее работает и меньше по размеру.
-C — добавляет комментарий к ключу (обычно для идентификации владельца, например, по имени или e-mail).

Команда спросит путь для сохранения ключа. Если вы нажмёте Enter, файлы будут созданы в директории по умолчанию — ~/.ssh/id_ed25519 и ~/.ssh/id_ed25519.pub. Также вас попросят указать парольную фразу (passphrase) — лучше её задать, иначе ключ можно будет использовать без дополнительной защиты.

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

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@ip.вашего.сервера

Эта команда:

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

Если ssh-copy-id недоступен (например, в минимальной сборке системы), можно сделать то же вручную:

cat ~/.ssh/id_ed25519.pub | ssh user@ip.вашего.сервера 'mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys'

Здесь:

mkdir -p ~/.ssh — создаёт каталог .ssh, если его нет;
chmod 700 ~/.ssh — задаёт правильные права (доступ только владельцу);
cat >> ~/.ssh/authorized_keys — добавляет ключ в файл авторизации;
chmod 600 ~/.ssh/authorized_keys — ограничивает права доступа к ключам.

После этого вы можете подключаться к серверу по ключу:

ssh user@ip.вашего.сервера

И только убедившись, что вход по ключу работает, можно отключить логин по паролю. Для этого отредактируйте конфигурационный файл OpenSSH-сервера:

sudo nano /etc/ssh/sshd_config

Найдите (или добавьте) строки:

PasswordAuthentication no
ChallengeResponseAuthentication no

Эти параметры отвечают за вход с использованием пароля и интерактивные методы (например, через PAM). После изменения файла примените настройки:

sudo systemctl reload ssh

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

Настройка доступа по SSH-ключам

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

Публичные ключи хранятся в файле:

~/.ssh/authorized_keys

в домашнем каталоге конкретного пользователя на сервере. Это значит, что доступ на уровне SSH регулируется индивидуально — в пределах каждого юзер-аккаунта.

Чтобы выдать доступ новому пользователю, сначала нужно создать для него учётную запись:

sudo adduser <имя_пользователя>

Затем — создать для него каталог .ssh с правильными правами:

sudo mkdir /home/<имя_пользователя>/.ssh
sudo chmod 700 /home/<имя_пользователя>/.ssh
sudo chown <имя_пользователя>:<группа> /home/<имя_пользователя>/.ssh

Далее — добавить в файл authorized_keys его публичный ключ:

sudo nano /home/<имя_пользователя>/.ssh/authorized_keys

Вставьте строку из его .pub-файла. Сохраните, закройте редактор и установите нужные права:

sudo chmod 600 /home/<имя_пользователя>/.ssh/authorized_keys
udo chown <имя_пользователя>:<группа> /home/<имя_пользователя>/.ssh/authorized_keys

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

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

Усиление безопасности SSH

Первый шаг к усилению безопасности вы уже сделали — вход по паролю отключён. Следующий шаг — ограничить круг пользователей, которым разрешено подключение по SSH. Это важно, если в системе есть служебные или тестовые аккаунты, не предназначенные для внешнего доступа. Добавьте директиву AllowUsers в sshd_config и перечислите нужные логины через пробел:

AllowUsers admin deployer

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

Затем нужно сменить порт, на котором работает SSH. По умолчанию это 22, и он регулярно сканируется ботами. Смена порта на другой незанятый порт, например 2222 или 2288, снизит количество автоматических попыток входа, хотя и не защитит от целенаправленной атаки. В файле конфигурации найдите строку:

Port 22

И замените на:

Port 2288

Если вы используете брандмауэр, не забудьте разрешить новый порт:

sudo ufw allow 2288/tcp

Также, если вы подключаетесь через нестандартный порт, его нужно указывать явно при подключении:

ssh -p 2288 user@ip

Следующий уровень защиты — ограничение доступа по IP-адресам. Если вы точно знаете, откуда будут подключаться пользователи (например, офис, VPN, IP администратора), можно разрешить вход только с этих адресов. Это делается на уровне sshd_config (строка ListenAddress), через файлы hosts.allow и hosts.deny или более гибким способом — с помощью файрвола:

sudo ufw allow from 203.0.113.5 to any port 2288 proto tcp

Также полезно ограничить число попыток входа. Установите пакет fail2ban, который будет отслеживать логи SSH и временно блокировать IP после нескольких неудачных попыток:

sudo apt install fail2ban

После установки он работает по умолчанию с преднастройками для SSH. При необходимости можно скорректировать параметры — например, количество попыток, интервал блокировки, список исключений. Это делается в конфигурационных файлах в каталоге /etc/fail2ban/.

Заключение

Настройка SSH-доступа в Ubuntu 24.04 — обязательная часть администрирования и основа безопасности сервера. От правильной конфигурации зависит, кто и как сможет получить доступ к вашей системе. Использование ключей, отключение паролей, фильтрация по IP и ограничение прав — всё это снижает риски и делает сервер безопаснее.

Читайте в блоге:

Как настроить SSH-доступ в Ubuntu 24.04 LTS: пошаговое руководство

Проверка и запуск SSH-сервиса

Базовая настройка: отключение входа по паролю и включение авторизации по SSH-ключу

Настройка доступа по SSH-ключам

Усиление безопасности SSH

Заключение