Хостинг Беларусь Хостинг Беларусь
Хостинг Беларусь Хостинг Беларусь

Блог / Статьи

Полезная информация для вашего хостинга

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

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

Категория: Блог

Содержание

Если вы только что развернули сервер на Ubuntu 24.04 LTS — поздравляем! Вы на пороге мощной, стабильной и гибкой системы. Но если вы не настроили SSH-доступ правильно, ваш сервер — как дом с открытыми дверями, стоящий на оживлённой трассе. Каждую минуту сотни ботов сканируют порт 22, пытаясь подобрать пароль, взломать root-доступ или захватить вашу инфраструктуру для ботнета. В этой статье мы не просто «настроим SSH» — мы превратим ваш сервер в непробиваемую крепость, где каждый вход — это проверка личности, а не случайный удачный клик.

Это не сухая инструкция из документации. Это — руководство от практика, который десятилетиями защищал серверы от атак, наводнений брутфорса и человеческих ошибок. Мы разберём каждый этап до мельчайших деталей: от проверки службы до настройки fail2ban, с примерами кода, логикой команд и объяснением, почему именно так, а не иначе. Готовы? Тогда начнём — без спешки, без пропусков, с полным погружением.

Проверка и запуск SSH-сервиса: убедитесь, что ваш сервер не спит

Первое, что нужно сделать после установки Ubuntu 24.04 LTS — не ставить приложения, не настраивать веб-серверы, не устанавливать Docker. Первое — проверить, жив ли SSH-демон. Потому что если вы потеряете доступ к серверу через SSH, и он не отвечает на ping, вы окажетесь в ситуации, когда никто не может помочь — ни поддержка хостинга, ни коллеги, ни даже технический отдел. Вы останетесь в тёмной комнате без ключа.

Начнём с проверки наличия пакета OpenSSH-сервера. Откройте терминал и выполните:

dpkg -l | grep openssh-server

Если вы видите строку вроде:

ii  openssh-server  1:9.6p1-3ubuntu1.5  amd64  secure shell (SSH) server

— отлично. Пакет установлен. Но установка — это ещё не запуск. Демон sshd (SSH daemon) может быть установлен, но отключен. Проверим его статус:

sudo systemctl status ssh

Вывод будет содержать несколько строк. Нас интересует одна:

Active: active (running)

Если вы видите inactive или failed — значит, служба не запущена. Причина может быть простой: после установки в некоторых образах VPS (особенно минимальных) SSH не включается автоматически. Или, что хуже, вы случайно его остановили.

Чтобы запустить и включить SSH в автозагрузку одним махом — используйте команду:

sudo systemctl enable --now ssh

Эта команда — два действия в одном:

  • enable — добавляет службу в систему автозагрузки systemd, чтобы она запускалась при каждом включении сервера.
  • --now — немедленно запускает службу, не дожидаясь перезагрузки.

Если вы работаете в удалённой сессии и не уверены, что всё сработает — не рискуйте. Проверьте, слушает ли SSH порт 22. Для этого используйте команду ss — современный, быстрый и точный аналог netstat:

ss -tnlp | grep ssh

Расшифровка флагов:

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

Ожидаемый вывод:

tcp   LISTEN 0  128  0.0.0.0:22  0.0.0.0:*  users:(("sshd",pid=1234,fd=3))
tcp   LISTEN 0  128  [::]:22     [::]:*   users:(("sshd",pid=1234,fd=4))

Если вы видите 0.0.0.0:22 — SSH слушает все IPv4-адреса сервера. Если [::]:22 — слушает все IPv6-адреса. Это нормально для большинства серверов. Если вы видите только 127.0.0.1:22 — значит, SSH доступен ТОЛЬКО локально. Это ошибка. Нужно исправлять конфигурацию.

Теперь — брандмауэр. Даже если SSH работает, он может быть заблокирован ufw (Uncomplicated Firewall), который в Ubuntu 24.04 включён по умолчанию. Проверьте статус:

sudo ufw status

Если вы видите Status: active, но нет правила для SSH — вы не сможете подключиться. Добавьте его:

sudo ufw allow ssh

Эта команда не просто открывает порт 22 — она добавляет правило с именем ssh, которое привязано к службе в /etc/services. Это надёжнее, чем вводить порт вручную. После этого проверьте:

sudo ufw status verbose

Убедитесь, что в списке есть строка:

22/tcp (ssh) ALLOW IN

Теперь — последняя проверка. Откройте новое окно терминала на вашем клиенте (не на сервере!) и попробуйте подключиться:

ssh Адрес электронной почты защищен от спам-ботов. Для просмотра адреса в браузере должен быть включен Javascript.

Если вы видите запрос пароля — значит, SSH работает. Если вы получаете Connection refused — ищите проблему в брандмауэре, сетевых настройках VPS или в том, что SSH не слушает внешние интерфейсы. Если вы видите Permission denied — это хорошо. Это значит, что SSH работает, но вы пока не авторизованы. Это нормально — мы это исправим дальше.

ssh05

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

Вы только что подключились по паролю. Отлично. Теперь — забудьте о паролях. Навсегда. Потому что пароли — это уязвимость. Даже если вы используете пароль из 20 символов, с цифрами, спецсимволами и заглавными буквами — он всё равно может быть подобран. Почему? Потому что боты не устают. Они перебирают миллионы комбинаций в секунду. Они знают стандартные логины: root, admin, ubuntu, user. Они знают словари паролей из утечек. Они не спят. Они не устают. Они не умрут.

Ваша задача — полностью отключить вход по паролю. И заменить его на SSH-ключи. Это не «лучшая практика» — это единственно правильный способ. И мы сделаем это шаг за шагом.

Генерация SSH-ключа: Почему ED25519 — это будущее

На вашем клиентском компьютере (не на сервере!) выполните:

ssh-keygen -t ed25519 -C "Адрес электронной почты защищен от спам-ботов. Для просмотра адреса в браузере должен быть включен Javascript."

Здесь:

  • -t ed25519 — указывает алгоритм. ED25519 — это современный, быстрый и криптографически стойкий алгоритм на основе эллиптических кривых. Он короче, чем RSA, быстрее при аутентификации и не подвержен атакам, которые могут повредить RSA-ключи при плохой энтропии.
  • -C — комментарий. Используйте email или идентификатор. Это поможет вам позже понять, чей ключ где лежит.

Команда спросит:

Enter file in which to save the key (/home/ваш-логин/.ssh/id_ed25519):

Нажмите Enter — сохраните в стандартное место. Затем:

Enter passphrase (empty for no passphrase):

Не оставляйте пустым! Даже если вы работаете на локальном ноутбуке — добавьте passphrase. Это — второй фактор аутентификации. Даже если кто-то украдёт ваш файл id_ed25519, он не сможет его использовать без пароля. Это как ключ от машины + код от сигнализации. Даже если ключ украден — машина не заведётся.

После выполнения вы увидите:

Your identification has been saved in /home/ваш-логин/.ssh/id_ed25519
Your public key has been saved in /home/ваш-логин/.ssh/id_ed25519.pub

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

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

Перенос публичного ключа на сервер: Два способа — и почему второй важнее

Способ 1: ssh-copy-id — самый простой. Если он есть на вашем клиенте (а в Ubuntu 24.04 он есть по умолчанию), выполните:

ssh-copy-id -i ~/.ssh/id_ed25519.pub Адрес электронной почты защищен от спам-ботов. Для просмотра адреса в браузере должен быть включен Javascript.

Эта команда:

  • Подключается к серверу по SSH (по паролю — пока ещё).
  • Автоматически создаёт каталог ~/.ssh, если его нет.
  • Устанавливает права 700 на каталог.
  • Добавляет ваш публичный ключ в файл authorized_keys.
  • Устанавливает права 600 на файл.
  • Проверяет, что файл принадлежит пользователю.

Это — идеальный способ для быстрого старта. Но что, если вы работаете на Windows с WSL? Или на минимальной системе без ssh-copy-id? Тогда — способ 2: вручную.

Скопируйте содержимое публичного ключа:

cat ~/.ssh/id_ed25519.pub

Скопируйте всю строку — она начинается с ssh-ed25519 AAAA.... Теперь подключитесь к серверу:

ssh Адрес электронной почты защищен от спам-ботов. Для просмотра адреса в браузере должен быть включен Javascript.

И выполните команду, которая создаст структуру, скопирует ключ и установит права — одним махом:

mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys

Затем вставьте скопированную строку ключа. Нажмите Ctrl+D, чтобы завершить ввод. Команда cat >> ждёт ввод, и только после Ctrl+D сохраняет его.

Теперь — проверьте. Закройте текущую сессию. Откройте новую. Попробуйте подключиться снова:

ssh Адрес электронной почты защищен от спам-ботов. Для просмотра адреса в браузере должен быть включен Javascript.

Если вас попросили ввести passphrase — вы на правильном пути. Введите её. Если вы вошли — отлично. Теперь вы можете подключаться по ключу. Это — ваша первая победа.

Отключение входа по паролю: Безопасность, которая не ждёт

Теперь — самое важное. Вы уже подключились по ключу. Проверили. Убедились. Теперь — отключите пароли навсегда.

Подключитесь к серверу (по ключу!) и откройте конфигурационный файл SSH:

sudo nano /etc/ssh/sshd_config

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

PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no

Почему именно эти три?

  • PasswordAuthentication no — запрещает вход по паролю для всех пользователей.
  • ChallengeResponseAuthentication no — отключает интерактивные методы аутентификации, такие как OTP, PAM-модули, которые могут обойти запрет на пароли.
  • UsePAM no — отключает PAM (Pluggable Authentication Modules). Хотя в Ubuntu 24.04 PAM по умолчанию не используется для SSH, это — дополнительный слой защиты. PAM может быть настроен на обход ограничений.

Также найдите и убедитесь, что строка:

PubkeyAuthentication yes

— включена. Она должна быть по умолчанию, но лучше проверить.

После изменений — не перезапускайте SSH. Перезагрузите его. Почему? Потому что reload — это «попробуй применить конфиг, не убивая соединения». А если вы сделали ошибку — вы потеряете доступ. restart — останавливает службу, потом запускает. Если конфиг неверный — вы останетесь без доступа. Поэтому — проверьте синтаксис до перезагрузки:

sudo sshd -t

Если вы видите no errors found — всё хорошо. Теперь — перезагрузите SSH:

sudo systemctl restart ssh

Но! Не закрывайте текущее окно терминала. Откройте новое окно и попробуйте подключиться снова. Если вы вошли — значит, всё работает. Теперь вы можете закрыть старое окно. И только после этого — считайте, что вход по паролю отключён навсегда. Вы — в безопасности.

ssh01

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

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

Правило: Один пользователь — один ключ. Один ключ — один человек.

Предположим, вы хотите добавить пользователя dev-team. Создайте его:

sudo adduser dev-team

Система спросит пароль — введите что-то сложное. Это временный пароль. Он вам понадобится только один раз — для копирования ключа. После этого он будет отключён.

Теперь — создайте директорию .ssh для нового пользователя:

sudo mkdir /home/dev-team/.ssh

Установите права:

sudo chmod 700 /home/dev-team/.ssh
sudo chown dev-team:dev-team /home/dev-team/.ssh

Теперь — скопируйте публичный ключ от пользователя dev-team в файл authorized_keys. Допустим, вы получили ключ от него по защищённому каналу. Вставьте его в файл:

sudo nano /home/dev-team/.ssh/authorized_keys

Вставьте строку ключа — например:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... dev-team@workstation

Сохраните и закройте. Теперь — права на файл:

sudo chmod 600 /home/dev-team/.ssh/authorized_keys
sudo chown dev-team:dev-team /home/dev-team/.ssh/authorized_keys

Теперь — проверьте. Подключитесь как dev-team:

ssh Адрес электронной почты защищен от спам-ботов. Для просмотра адреса в браузере должен быть включен Javascript.

Если вы ввели passphrase, и вошли — успех. Теперь — отключите пароль для этого пользователя. Для этого снова откройте /etc/ssh/sshd_config и добавьте:

AllowUsers admin dev-team

Это — не просто ограничение. Это — белый список. Только эти пользователи могут входить. Все остальные — даже если у них есть ключ — не смогут войти. Это — ваша защита от случайных аккаунтов, тестовых пользователей, забытых учеток.

Почему это важно? Потому что в Ubuntu 24.04 по умолчанию есть пользователь ubuntu в некоторых образах. Он может быть скомпрометирован. Или кто-то создал аккаунт test для «теста» — и забыл. Если вы не ограничите доступ — эти аккаунты могут быть использованы для входа, если у злоумышленника есть ключ от другого пользователя. Белый список — ваш щит.

И ещё один важный момент: никогда не используйте root для SSH. Всегда входите как обычный пользователь, а затем — через sudo. Это — стандарт безопасности. Чтобы запретить вход root-а, добавьте в sshd_config:

PermitRootLogin no

Это — обязательное правило. Даже если вы думаете, что «у меня и так всё надёжно» — нет. Это правило есть в любом гайде по безопасности. И его нарушение — первый признак непрофессионализма.

Усиление безопасности SSH: от порта до Fail2Ban — стратегия полного прикрытия

Вы уже отключили пароли. Вы настроили ключи. Вы ограничили пользователей. Но это — только начало. Теперь — переход на уровень военной безопасности.

Смена порта SSH: Скрытие от сканеров

Порт 22 — как номер двери в доме, который написан на табличке. Каждый бот знает: «Порт 22 — SSH. Попробуем подобрать». Смените его на нестандартный. Это не защита от целенаправленной атаки. Но это — защита от автоматических сканеров. Они не будут искать порт 2288. Они не будут тратить ресурсы на ваш сервер.

Откройте /etc/ssh/sshd_config и найдите строку:

#Port 22

Раскомментируйте её и измените на:

Port 2288

Можно выбрать любой порт от 1024 до 65535. Избегайте портов, которые используются другими сервисами: 80, 443, 3306, 5432. 2288 — идеальный выбор: нестандартный, легко запомнить, не конфликтует.

Теперь — обновите брандмауэр:

sudo ufw allow 2288/tcp
sudo ufw delete allow ssh

Проверьте:

sudo ufw status

Убедитесь, что есть только 2288/tcp, а не 22/tcp.

Теперь — попробуйте подключиться:

ssh -p 2288 Адрес электронной почты защищен от спам-ботов. Для просмотра адреса в браузере должен быть включен Javascript.

Если вы вошли — отлично. Теперь — обязательно сохраните этот порт в своей записной книжке, в менеджере паролей, в документации. Если вы забудете — вы потеряете доступ. Это — ваша новая «ключевая точка».

Ограничение по IP-адресам: Только с доверенных мест

Если вы работаете из офиса, из дома, из VPN — вы знаете свои IP-адреса. Зачем открывать сервер всему миру? Запретите вход с любых IP, кроме ваших.

В sshd_config можно использовать директиву ListenAddress, но она ограничивает интерфейсы. Лучше — использовать ufw для фильтрации по источнику:

sudo ufw allow from 203.0.113.5 to any port 2288 proto tcp
sudo ufw allow from 192.168.1.100 to any port 2288 proto tcp
sudo ufw deny 2288

Это значит: «Разрешить вход только с 203.0.113.5 и 192.168.1.100. Всё остальное — запрещено».

Если у вас динамический IP — используйте VPN. Подключайтесь к VPN, получайте статический IP внутри него — и разрешайте только IP VPN-сервера. Это — стандарт для компаний, работающих с GDPR, HIPAA, PCI-DSS.

Fail2Ban: Автоматический страж, который не спит

Вы отключили пароли. Вы сменили порт. Вы ограничили IP. Но что, если кто-то попытается подобрать ключ? Или кто-то попытается войти как root? Или кто-то использует уязвимость в другом сервисе, чтобы получить доступ и пытаться подключиться по SSH?

Ответ: Fail2Ban.

Установите его:

sudo apt update
sudo apt install fail2ban

Он работает по умолчанию. Но — настройте его правильно. Скопируйте шаблон в локальный конфиг:

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Откройте его:

sudo nano /etc/fail2ban/jail.local

Найдите секцию [sshd] и измените параметры:



[sshd]
enabled = true
port = 2288
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 3600
findtime = 600

Расшифровка:

  • port = 2288 — слушаем наш нестандартный порт.
  • maxretry = 3 — после трёх неудачных попыток — блокировка.
  • findtime = 600 — за 10 минут (600 секунд).
  • bantime = 3600 — блокировка на 1 час. Можно увеличить до 86400 (1 день) или даже 604800 (неделя).

Перезапустите fail2ban:

sudo systemctl restart fail2ban

Проверьте статус:

sudo fail2ban-client status sshd

Вы увидите что-то вроде:



Status for the jail: sshd
|- Filter
|  |- Currently failed: 0
|  |- Total failed:     0
|  `- File list:        /var/log/auth.log
`- Actions
   |- Currently banned: 0
   |- Total banned:     0
   `- Banned IP list:

Теперь — попробуйте подключиться с неверным ключом 3 раза. Через минуту вы увидите, что ваш IP заблокирован. Это — ваша защита. Это — ваша безопасность. Это — автоматический щит, который работает, когда вы спите.

ssh04

Заключение: SSH — не инструмент. Это философия безопасности

Вы только что прошли путь от «я включил сервер» до «я построил крепость». Вы отключили пароли. Вы настроили ключи. Вы сменили порт. Вы ограничили IP. Вы установили fail2ban. Вы знаете, как работают права доступа. Вы понимаете, почему authorized_keys должен быть 600, а .ssh — 700. Вы понимаете, почему PermitRootLogin no — это не рекомендация, а требование.

Это — не просто «настройка SSH». Это — философия системного администрирования. Это — мышление, при котором вы не доверяете ничего. Вы не предполагаете, что «всё будет хорошо». Вы строите защиту на каждом уровне. Вы делаете так, чтобы даже если один слой сломается — остальные останутся целыми.

Ubuntu 24.04 LTS — это не просто ОС. Это платформа для создания надёжных систем. И SSH — это ваш первый и самый важный шлюз. Если вы сделаете его надёжным — вы защитите всё, что находится за ним: базы данных, веб-серверы, API, контейнеры, криптовалютные кошельки, данные клиентов.

Помните:

  • Никогда не используйте пароли для SSH.
  • Всегда используйте ED25519 с passphrase.
  • Всегда ограничивайте доступ по IP.
  • Всегда меняйте порт.
  • Всегда включайте fail2ban.
  • Никогда не входите как root.
  • Никогда не делитесь приватными ключами.

Если вы сделаете всё это — ваш сервер будет одним из самых защищённых в интернете. Не потому, что вы использовали «самый дорогой хостинг». Не потому, что у вас «крутой брандмауэр». А потому, что вы понимаете: безопасность — это не продукт. Это привычка.