SSH (Secure Shell) — это стандартный способ безопасного удалённого доступа к серверу: весь трафик шифруется, а сервер и клиент взаимно проверяют подлинность. В Linux чаще всего используется OpenSSH: клиент ssh и демон sshd. В отличие от Telnet/FTP, логины, команды и файлы идут по защищённому каналу, а аутентификация ключами избавляет от передачи паролей.
В этой статье мы разберём установку и базовую настройку SSH на сервере (на примерах Ubuntu/Debian, с параллелями для RHEL/Alma/Rocky/Fedora и Arch), пройдёмся по ключевым параметрам конфигурации и рекомендациям по безопасности.
Как установить SSH
Во многих дистрибутивах OpenSSH-сервер уже предустановлен (включая наши облачные VDS). Начнём с проверки, а затем — с установки, если потребуется.
# сервис активен?
sudo systemctl status sshd || sudo systemctl status ssh
# слушает ли порт по факту:
sudo ss -lptn 'sport = :22' # или lsof -i :22 -nP
Если сервис не найден или не активен — установите openssh-server и включите автозапуск (как описано ниже для вашего дистрибутива).
Установка OpenSSH Server
# Debian-based (Ubuntu, Debian, Astra Linux):
sudo apt update
sudo apt install -y openssh-server
# RHEL-based (RHEL, AlmaLinux, Rocky, Fedora):
sudo dnf install -y openssh-server
# Arch Linux:
sudo pacman -S openssh
После установки, службу требуется запустить и включить автозапуск. У разных семейств имя сервиса может отличаться (ssh или sshd) — попробуйте по порядку:
# Универсально: один из вариантов отработает
sudo systemctl enable --now sshd || sudo systemctl enable --now ssh
Подключение по SSH
SSH-сервер по умолчанию прослушивает соединения на порту 22, а также требует аутентификации сторон. Есть несколько вариантов проверки соединения.
Базовая авторизация (пароль)
Это удобно для первого логина, но для постоянной работы небезопасно, рекомендуем использовать ключ для авторизации.
Подключение:
ssh user@SERVER_IP
Далее потребуется ввести пароль пользователя для авторизации.
Обычно 22 порт слушается демоном после установки. Если подключение не идёт — проверьте локальный фаервол (UFW/firewalld/nftables) и внешние правила (ACL/роутер). Для быстрого внешнего теста пригодится наш онлайн-сканер портов.
Создание ключа для авторизации
Ключевая аутентификация безопаснее пароля. На клиенте хранится закрытый ключ, на сервере — открытый. При подключении сервер криптографически убеждается, что у клиента действительно есть соответствующий закрытый ключ; никакие ключевые файлы по сети не передаются. Это устраняет риск перехвата пароля и делает вход устойчивым к перебору.
1. Генерируем пару ключей на локальной машине (клиенте)
ssh-keygen -t ed25519 -a 64 -C "yourname@yourhost"
Основные параметры:
-t— тип ключа (rsa,ed25519,ecdsa)-b— длина ключа в битах (для RSA — обычно 4096)-C— комментарий (часто указывают email)-f— путь для сохранения ключа (по умолчанию ~/.ssh/id_rsa или id_ed25519)
По умолчанию ключ будет создан по пути ~/.ssh/id_ed25519 (private) и ~/.ssh/id_ed25519.pub (public)
2. Копируем публичный ключ на сервер
Чтобы авторизоваться по ключу, нужно передать публичный ключ на сервер.
Самый простой и удобный способ — команда ssh-copy-id:
ssh-copy-id user@SERVER_IP
# если нестандартный порт:
ssh-copy-id -p 2222 user@SERVER_IP
Если команда не срабатывает, можно скопировать ключ вручную:
cat ~/.ssh/id_ed25519.pub | ssh user@SERVER_IP "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"
Где
~/.ssh/id_ed25519.pubэто путь до вашего публичного ключа на локальной машине.
В результате содержимое файла с публичным ключом id_ed25519.pub будет скопировано в файл ~/.ssh/authorized_keys на сервере, и в дальнейшем вы сможете устанавливать соединение с сервером без ввода пароля.
3. Проверка подключения
ssh user@SERVER_IP
Если всё настроено правильно — вы войдете без ввода пароля (или только введёте пароль от ключа, если он установлен).
Рекомендации по безопасности SSH
Смена порта для SSH
По умолчанию SSH слушает порт 22. Смена порта не повышает криптографическую безопасность, но снижает «шум» от массовых сканеров. Выбирайте не привилегированный порт выше 1024, обычно из «высокого» диапазона 49152–65535, и убедитесь, что он открыт в фаерволе и (для RHEL-based) разрешён в SELinux. Желательно подбирать номера, в которых все цифры отличаются, например 56893.
Изменить порт требуется в файле конфигурации /etc/ssh/sshd_config
Раскомментируйте строку Port 22. Вместо 22 укажите другой номер — например, Port 56893. Сохраните изменения и закройте файл.
Чтобы применить конфигурацию, перезапустите службу:
sudo systemctl reload sshd || sudo systemctl reload ssh
После успешного перезапуска убедитесь, что теперь подключение проходит по другому порту:
ssh -p 56893 user@ip_server
Также перед выходом из SSH, проверьте что новый порт доступен и не блокируется firewall на сервере. Если порт недоступен, то его требуется открыть. Подробная инструкция по работе с портами.
Отключение авторизации по паролю
Вход по паролю удобен на старте, но с точки зрения безопасности ключи лучше: их нельзя «подобрать», а пароль нередко приходится хранить небезопасно. После проверки входа по ключу имеет смысл выключить пароли в sshd_config — так сервер будет принимать только ключевую аутентификацию.
Важно помнить:
- при утере закрытого ключа или порче
~/.ssh/authorized_keysвы лишитесь доступа; - перед отключением пароля обязательно проверьте вход по ключу из отдельного терминала;
- держите резервный доступ (второй ключ/учётная запись или доступ через консоль панели/облака), чтобы не «запереть» себя.
Как только удостоверились, что вход по ключу работает, выключаем пароли. Откройте файл /etc/ssh/sshd_config и измените параметр PasswordAuthentication.
Вместо Yes установите значение No.
PasswordAuthentication no
Примените изменения:
sudo systemctl reload sshd || sudo systemctl reload ssh
После этого исчезнет возможность использовать для авторизации пароли. Подключиться можно будет только с помощью SSH ключей.
Безопасный конфиг: важные параметры sshd_config
Помимо основных параметров безопасности можно использовать дополнительные по собственному усмотрению. Ниже — набор /etc/ssh/sshd_config, который комфортен в проде: пример целиком и пояснения к ключевым опциям.
# ===== Основы =====
Protocol 2
AddressFamily any
# Port 22 # если меняли порт, раскомментируйте и задайте новое значение
# ListenAddress 0.0.0.0 # по умолчанию слушаем на всех интерфейсах; можно ограничить
# ===== Аутентификация =====
PubkeyAuthentication yes
PasswordAuthentication no # выключаем пароли после проверки входа по ключам
ChallengeResponseAuthentication no
UsePAM yes
# ===== Root и доступ =====
PermitRootLogin prohibit-password # или 'no' — полный запрет
#AllowUsers user1 user2
#AllowGroups sshusers
# ===== Таймауты и защита от перебора =====
MaxAuthTries 3
LoginGraceTime 30s
ClientAliveInterval 60
ClientAliveCountMax 3
# ===== Диагностика (включайте на время настройки) =====
#LogLevel VERBOSE
Пояснения к параметрам:
Protocol 2— современная версия протокола SSH.AddressFamily any / inet / inet6— на каких семьях адресов слушать. Можно явно оставить только IPv4 (inet) или IPv6 (inet6).Port— порт SSH. Если меняете, не забудьте фаервол и (на RHEL-based) SELinux.ListenAddress— при необходимости ограничьте прослушивание конкретным интерфейсом/адресом.PubkeyAuthentication yes— включаем вход по ключам.PasswordAuthentication no— выключаем пароли (после проверки ключей).ChallengeResponseAuthentication no— отключаем устаревшие интерактивные методы.UsePAM yes— оставляем PAM (обычно «как есть»).PermitRootLogin prohibit-password / no— ограничаем или запрещаем вход под root.AllowUsers / AllowGroups— белые списки пользователей/групп; удобно на общих хостах.MaxAuthTries / LoginGraceTime— ограничиваем число попыток и время на логин.ClientAliveInterval / ClientAliveCountMax— серверные keepalive, завершение «зависших» сессий.LogLevel VERBOSE— больше деталей в логах на этапе настройки; в проде можно вернутьINFO.
После внесения изменений в файл конфигурации, нужно их применить:
sudo systemctl reload sshd || sudo systemctl reload ssh
Отладка и решение проблем
Диагностика подключения через ssh -v
Клиент умеет подробно логировать ход подключения:
-v (verbose), -vv, -vvv (максимум деталей).
ssh -v user@SERVER_IP
ssh -vv -p 2222 user@SERVER_IP
В логах видно: какой ключ пробуется, почему отвергнут метод, к какому адресу/порту действительно идёт соединение, как прошла проверка ключа хоста (host key).
Частые ошибки и способы их устранения
Permission denied (publickey)
Публичный ключ не в ~/.ssh/authorized_keys, не те права (~/.ssh — 700, файл — 600), логинитесь не тем пользователем/в не тот home. Проверьте владельца и путь.
Host key verification failed / WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!
Часто после переустановки ОС/смены сервера. Удалите старую запись о ключе хоста:
ssh-keygen -R SERVER_IP
# затем переподключитесь и примите новый host key
Connection timed out / No route to host
Демон не слушает (sudo ss -lptn | grep :22), порт закрыт в UFW/firewalld/nftables, либо фильтрация/маршрутизация вне сервера. Проверьте локальный фаервол и внешние правила (клауд-ACL, роутер). Для внешней валидации удобно использовать наш Port Scanner.
Connection closed by remote host
Сработал fail2ban/sshguard, недостаточны лимиты (MaxAuthTries), проблемы PAM. Смотрите логи:
journalctl -u sshd -b
SELinux/AppArmor блокирует нестандартный порт
Для SELinux добавьте порт в ssh_port_t
sudo semanage port -a -t ssh_port_t -p tcp 2222 2>/dev/null || \
sudo semanage port -m -t ssh_port_t -p tcp 2222
И проверьте AVC-события:
sudo ausearch -m avc -ts today
Клиент (локальный сервер) использует не тот ключ
Укажите явно или настройте ~/.ssh/config:
ssh -i ~/.ssh/id_ed25519 user@SERVER_IP
# ~/.ssh/config
Host myserver
HostName SERVER_IP
User user
Port 22
IdentityFile ~/.ssh/id_ed25519
IdentitiesOnly yes
Заключение
Настройка SSH на сервере Linux — важный шаг для безопасности и удобства удалённого управления. В статье мы прошли установку, первое подключение, перевод на ключевую аутентификацию, базовые параметры sshd_config и короткую диагностику. Следуя этим рекомендациям, вы снизите риск несанкционированного доступа и сделаете администрирование надёжнее и спокойнее.
Помните: безопасность держится на регулярных обновлениях, аккуратной конфигурации и проверках. Используйте ключи вместо паролей, следите за логами, периодически ревизуйте доступы.
