Подключение и настройка SSH на VPS

Первый и самый важный шаг – отказ от примитивной аутентификации по паролю в пользу криптографических ключей. Почему?

Уязвимость паролей: Даже сложные пароли уязвимы к перебору (brute-force). Боты делают это тысячи раз в секунду. Ключи же требуют наличия уникального криптографического файла.
Сила асимметрии: SSH использует пару ключей: приватный (Private Key) и публичный (Public Key). Приватный ключ – это ваш супер-секретный, никому не передаваемый ключ, хранящийся ТОЛЬКО на вашем доверенном компьютере. Публичный ключ – это, условно, "замок", который вы вешаете на сервер. Даже зная публичный ключ (а он часто не секрет), вычислить приватный за разумное время современными средствами невозможно. Это фундамент математической безопасности.
Passphrase – последний рубеж: Генерация ключа включает создание passphrase – длинной фразы-пароля, которой шифруется сам приватный ключ на вашем диске. Даже если злоумышленник украдет файл приватного ключа, без passphrase он бесполезен. Это двойная защита.

Генерация ключей:

Алгоритм

Ed25519 (на основе эллиптических кривых): Современный золотой стандарт. Быстрый, компактный (короткие ключи), невероятно криптостойкий. Самый рекомендуемый выбор сегодня. Генерация: ssh-keygen -t ed25519 -C "your_comment_here".
RSA: Старый, проверенный временем, но требует большей длины ключа для сопоставимой с Ed25519 безопасности. Минимально приемлемая длина сегодня – 4096 бит (-b 4096). Избегайте 2048 бит – их стойкость уже под вопросом. Генерация: ssh-keygen -t rsa -b 4096 -C "your_comment_here".
ECDSA: Также на эллиптических кривых, но менее популярен, чем Ed25519. Требует выбора размера кривой (-b 521 для аналога RSA 15360 бит!). Генерация: ssh-keygen -t ecdsa -b 521 -C "your_comment_here".
Вывод: Используйте Ed25519, если ваш клиент и сервер его поддерживают (большинство современных систем поддерживают). Если нет – RSA 4096 бит.

Генерация

Запустите ssh-keygen с выбранными параметрами в терминале вашего локального компьютера (не на сервере!).
Система предложит место сохранения. Стандартный путь (~/.ssh/id_algorithm, например ~/.ssh/id_ed25519) обычно оптимален. Нажмите Enter.
Ключевой момент: Введите надежную passphrase. Не пароль! Длинную, уникальную фразу, которую вы сможете запомнить или хранить в надежном менеджере паролей. Это ваша последняя линия обороны! Не оставляйте поле пустым!

Результат: В папке ~/.ssh появятся два файла:

id_ed25519 (или id_rsa) – ПРИВАТНЫЙ КЛЮЧ. Храните его как зеницу ока. Никогда, никому, ни при каких условиях не передавайте, не копируйте на сомнительные устройства, не отправляйте по почте/мессенджерам. Это ваша цифровая личность.
id_ed25519.pub (или id_rsa.pub) – ПУБЛИЧНЫЙ КЛЮЧ. Его вы смело размещаете на сервере. Он не секретен.

Итак, сервер запущен, вы получили от провайдера данные для доступа: IP-адрес, SSH-порт (чаще всего 22), имя пользователя (обычно root) и его пароль. Цель этого этапа: безопасно войти и подготовить почву для установки вашего криптоключа.

Подключение: Откройте терминал (Linux/macOS) или PowerShell/терминал Windows (с поддержкой OpenSSH) и выполните:
ssh root@ваш_ip_адрес -p 22
(Замените ваш_ip_адрес на реальный IP вашего VPS).

Предупреждение о неизвестном хосте: При самом первом подключении вы увидите сообщение вроде:

The authenticity of host 'xxx.xxx.xxx.xxx (xxx.xxx.xxx.xxx)' can't be established.
ECDSA key fingerprint is SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Что это? Сервер представляет свой "отпечаток пальца" (fingerprint) – криптографическую сводку его уникального ключа хоста. Клиент проверяет, не менялся ли сервер с момента вашего последнего подключения (это мог бы быть признак атаки "man-in-the-middle").
Что делать? В этот самый первый раз вам нужно независимо проверить этот отпечаток! Как?
Идеально: Если ваш хостинг-провайдер отображает fingerprint сервера в панели управления (в разделе VPS, сервера, иногда при переустановке ОС). Сравните его с тем, что показывает терминал. Совпадает? Смело вводите yes.
Альтернатива (менее безопасная): Если панель не показывает fingerprint, и вы абсолютно доверяете каналу связи (например, работаете через безопасную сеть) и провайдеру, можно принять риск и ввести yes. Но это ослабляет защиту первого подключения.

После ввода yes отпечаток сохранится в локальном файле ~/.ssh/known_hosts. При последующих подключениях клиент сверит полученный отпечаток с сохраненным и предупредит только в случае несоответствия (что будет серьезным красным флагом!).

Ввод пароля: После подтверждения хоста, введите пароль пользователя root (или другого, предоставленного провайдером). При вводе пароль не отображается (ни звездочек, ни точек) – это нормально. Нажмите Enter. Если пароль верен, вы окажетесь в командной строке сервера под пользователем root (признак – приглашение обычно заканчивается на #).

Вы вошли. Теперь root – это ваша безграничная власть, но и огромная ответственность. Одно неверное действие – и сервер может стать недоступным. Действуем методично и осторожно.

Обновление системы

Только что установленный образ ОС часто содержит устаревшие пакеты с известными уязвимостями. Обновление закрывает эти дыры.

Выполните (для Debian/Ubuntu):

apt update # Обновить списки пакетов из репозиториев
apt upgrade -y # Установить все доступные обновления (-y автоматически отвечает "yes" на запросы)

Для CentOS/RHEL:

yum update -y # или dnf update -y для современных Fedora/RHEL 8+

Для OpenSUSE:

zypper refresh # Обновить репозитории
zypper update -y # Установить обновления

Важно: Если обновление затрагивает критически важные компоненты (ядро, системные библиотеки), может потребоваться перезагрузка (reboot). Сделайте ее, если об этом явно сказано в выводе команд. После перезагрузки снова войдите как root.

Установка ключа:

Цель: Разрешить вход только по вашему криптографическому ключу и запретить вход по паролю для выбранного пользователя. Сначала создадим пользователя (если используем не root, что крайне рекомендуется).

Создание непривилегированного пользователя (сильно рекомендуется!):

adduser ваш_новый_пользователь # Следуйте подсказкам, задайте надежный пароль (он нам понадобится временно)
usermod -aG sudo ваш_новый_пользователь # Debian/Ubuntu: Добавляем в группу 'sudo' для прав администратора
# ИЛИ
usermod -aG wheel ваш_новый_пользователь # CentOS/RHEL: Добавляем в группу 'wheel'

Почему не root? Пользователь root всем известен, он главная цель атак. Ошибка под root может иметь фатальные последствия. Работа под обычным пользователем с правами sudo для административных команд безопаснее и предотвращает случайные фатальные ошибки.

Подготовка каталога SSH:

Переключимся на нового пользователя (пока еще с паролем): su - ваш_новый_пользователь

Создаем скрытый каталог .ssh и файл authorized_keys с правильными правами:

mkdir -p ~/.ssh # Создать каталог (если нет)
touch ~/.ssh/authorized_keys # Создать пустой файл авторизованных ключей
chmod 700 ~/.ssh # Права: Владелец - чтение/запись/вход; Группа и Остальные - ничего
chmod 600 ~/.ssh/authorized_keys # Права: Владелец - чтение/запись; Группа и Остальные - ничего

Эти права очень важны! SSH сервер просто откажется использовать ключи, если права на каталог или файл слишком открыты (например, 755 или 777).

Установка публичного ключа:

На вашем ЛОКАЛЬНОМ компьютере откройте файл публичного ключа: cat ~/.ssh/id_ed25519.pub (или id_rsa.pub). Вы увидите одну длинную строку, начинающуюся с ssh-ed25519 AAAAC3... или ssh-rsa AAAAB3....
Скопируйте ВСЮ эту строку.
На сервере, под вашим новым пользователем, откройте файл ~/.ssh/authorized_keys в текстовом редакторе (nano прост в использовании: nano ~/.ssh/authorized_keys).
Вставьте скопированную строку с вашим публичным ключом. Если это первый ключ, она будет единственной. Если вы добавляете ключ для другого устройства/пользователя, вставьте его с новой строки.
Сохраните файл (в nano: Ctrl+O, Enter) и выйдите из редактора (Ctrl+X).

Проверка (пока еще в сессии root): Не выходя из сессии root, откройте новое окно терминала на вашем локальном компьютере. Попробуйте войти под новым пользователем с использованием ключа:
ssh ваш_новый_пользователь@ваш_ip_адрес -p 22 -i ~/.ssh/id_ed25519
(Используйте путь к вашему приватному ключу). Если запросит passphrase ключа (а должен!) и после ее ввода вы попадете на сервер – ключ работает! Если нет – проверьте шаги: правильность скопированного ключа, права на файлы (700 на ~/.ssh, 600 на authorized_keys), имя пользователя, IP.

Переконфигурация SSH-Демона: cердце безопасности (sshd_config)

Теперь, когда ключ работает, можно кардинально усилить защиту, отредактировав главный конфигурационный файл SSH сервера. Это самый ответственный этап. Одна ошибка – и вы потеряете доступ!

Резервная Копия: Прежде чем что-либо менять, сделайте копию! cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak. Это ваша страховка.
Открываем Конфиг: Используем текстовый редактор с правами root (либо будучи root, либо через sudo от нового пользователя: sudo nano /etc/ssh/sshd_config).

Ищем и меняем критичные параметры (раскомментируйте строки, убрав # в начале, если необходимо):

Port 22 -> Port ваш_новый_порт (например, Port 24596):

Зачем? Порт 22 сканируется постоянно. Смена порта резко снижает уровень шума в логах и затрудняет работу автоматизированных ботов, ищущих легкую добычу. Это не "скрытие" (security through obscurity – слабая защита), а эффективный фильтр первичного шума. Запомните/запишите этот порт!

#PermitRootLogin yes -> PermitRootLogin no (или PermitRootLogin prohibit-password):

Зачем? Полное отключение входа под root (no) – лучшая практика. Атаки сразу теряют главную цель. Если вам крайне необходимо когда-либо зайти под root (что сомнительно), используйте prohibit-password – вход по паролю запрещен, но теоретически возможен по ключу (хотя вход под обычным юзером + sudo -i или sudo su - всегда предпочтительнее).

#PasswordAuthentication yes -> PasswordAuthentication no:

Зачем? Это ключевое изменение! Полностью запрещает аутентификацию с использованием паролей для всех пользователей. Вход возможен только по криптографическим ключам. Уничтожает риск перебора паролей. Убедитесь, что ваш ключ работает ДО включения этой опции!

PubkeyAuthentication yes:

Зачем? Явно разрешает аутентификацию по публичному ключу. Должно быть yes.

ChallengeResponseAuthentication no:

Зачем? Обычно используется для PAM-аутентификации (пароли), которая нам не нужна. Отключаем.

UsePAM no (Используйте осторожно, может быть необходимо для некоторых функций):

Зачем? Pluggable Authentication Modules – мощный механизм, но для чистого ключевого доступа без дополнительных факторов (типа 2FA через PAM) часто можно отключить. Проверьте! На некоторых системах (особенно Ubuntu) отключение UsePAM может сломать вход, даже по ключу. Если не уверены – оставьте UsePAM yes.

X11Forwarding no:

Зачем? Позволяет перенаправлять графический интерфейс с сервера на ваш компьютер. Если вы не работаете с графическими приложениями на сервере – отключайте, это уменьшает поверхность атаки.

AllowUsers ваш_новый_пользователь (или AllowUsers user1 user2):

Зачем? Явно перечисляет пользователей, которым разрешен вход по SSH. Даже если злоумышленник каким-то чудом получит действующий ключ для пользователя, не входящего в этот список, войти он не сможет. Мощный ограничитель.

PermitEmptyPasswords no:

Зачем? Запрещает вход пользователям с пустым паролем. Должно быть no.

ClientAliveInterval 300 и ClientAliveCountMax 2 (Опционально, но полезно):

Зачем? Автоматически разрывает "зависшие" соединения. ClientAliveInterval 300 означает "посылать клиенту проверочный пакет каждые 300 секунд (5 минут)". Если за ClientAliveCountMax 2 таких интервала (т.е. 10 минут) ответа нет – соединение разрывается.

MaxAuthTries 3 (Опционально):

Зачем? Ограничивает количество попыток аутентификации за одно соединение. Помогает против перебора, но основную работу сделает fail2ban.

LoginGraceTime 60 (Опционально):

Зачем? Время (в секундах), в течение которого пользователь должен успешно аутентифицироваться после подключения. По истечении – соединение разрывается. Уменьшает окно для атаки.

Сохраните файл конфигурации (в nano: Ctrl+O, Enter). Выйдите из редактора (Ctrl+X).

Применение изменений:

Не закрывайте текущую активную SSH сессию! Это ваш спасательный круг.
Проверьте конфигурацию на синтаксические ошибки: sshd -t. Если команда не вывела ничего – конфиг в порядке. Если есть ошибки – исправьте их немедленно в открытом файле.

Перезапустите SSH-демон:

sudo systemctl restart sshd # На большинстве современных систем (Systemd)
# ИЛИ
sudo service ssh restart # На старых системах (SysVinit)

Критическая проверка: Откройте новое, третье окно терминала на своем локальном компьютере. Попробуйте подключиться с новыми параметрами:
ssh ваш_новый_пользователь@ваш_ip_адрес -p ваш_новый_порт
(Например: ssh deploy@203.0.113.42 -p 24596).

Система должна запросить passphrase вашего приватного ключа (если вы ее задавали).
После ввода passphrase вы должны успешно войти на сервер под вашим новым пользователем.
Попробуйте войти под root: ssh root@ваш_ip_адрес -p ваш_новый_порт. Должно быть категорически отказано.
Попробуйте войти с паролем (даже зная пароль нового пользователя): ssh ваш_новый_пользователь@ваш_ip_адрес -p ваш_новый_порт. Должен быть запрошен пароль, но после его ввода (правильного!) – должно быть отказано в доступе (Permission denied (publickey)). Это подтверждает, что PasswordAuthentication no работает.

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

Теперь, когда SSH перенастроен, нужно настроить сетевой экран, чтобы он пропускал только нужные нам соединения и блокировал все остальные.

UFW (Uncomplicated Firewall) - Для Debian/Ubuntu:

sudo apt install ufw -y # Установить UFW, если не установлен
sudo ufw allow ваш_новый_порт/tcp # Разрешить входящие подключения на новый SSH порт
sudo ufw deny 22/tcp # Явно запретить входящие подключения на старый порт 22 (не обязательно, но рекомендуется)
sudo ufw enable # Включить брандмауэр
sudo ufw status verbose # Показать статус и активные правила

Firewalld - Для CentOS/RHEL/Fedora:

sudo firewall-cmd --permanent --add-port=ваш_новый_порт/tcp # Разрешить порт
sudo firewall-cmd --permanent --remove-service=ssh # Удалить правило для порта 22 (разрешающее по умолчанию)
sudo firewall-cmd --reload # Применить изменения
sudo firewall-cmd --list-all # Показать все правила

nftables/iptables - Мощь и Гибкость (Для Продвинутых):

Это более низкоуровневые инструменты. Пример базового правила для разрешения нового SSH порта:

# Для nftables (современная замена iptables)
sudo nft add rule inet filter input tcp dport ваш_новый_порт ct state new,established accept
sudo nft add rule inet filter input tcp dport 22 drop # Явный запрет 22
# ... и сохранить правила в соответствии с дистрибутивом

Использование iptables или nftables требует глубокого понимания и аккуратности, чтобы не заблокировать себя.

Брандмауэр – ваш активный защитник на сетевом уровне, дополняющий безопасность самого SSH.

Даже с ключами, сменой порта и брандмауэром, злоумышленники будут стучаться. Fail2Ban – это ваш "умный охранник", который анализирует логи SSH и автоматически блокирует IP-адреса, проявляющие подозрительную активность (например, множество неудачных попыток входа).

Установка и Базовая Настройка:

# Debian/Ubuntu
sudo apt install fail2ban -y
sudo systemctl enable fail2ban
sudo systemctl start fail2ban

# CentOS/RHEL (часто требует EPEL)
sudo yum install epel-release -y
sudo yum install fail2ban -y
sudo systemctl enable fail2ban
sudo systemctl start fail2ban

# Fedora
sudo dnf install fail2ban -y
sudo systemctl enable fail2ban
sudo systemctl start fail2ban

Как это работает? Fail2Ban мониторит файл логов SSH (обычно /var/log/auth.log или /var/log/secure). При обнаружении нескольких неудачных попыток входа (например, 5 за 10 минут – настраивается) с одного IP, он добавляет временное правило блокировки в брандмауэр системы (iptables/nftables/firewalld) для этого IP. Через заданный таймаут (например, 1 час) блокировка снимается.

Конфигурация (обычно не требуется сразу): Базовая конфигурация (/etc/fail2ban/jail.conf и переопределения в /etc/fail2ban/jail.local) часто достаточна. Основные параметры для SSH ([sshd]):

enabled = true
maxretry = 5 (Количество попыток до бана)
findtime = 10m (Окно времени для подсчета maxretry)
bantime = 1h (Время блокировки)
port = ваш_новый_порт (Укажите ваш порт SSH!)
logpath = /var/log/auth.log (Или /var/log/secure для RHEL)

После изменения конфига: sudo systemctl restart fail2ban.

Проверка статуса: sudo fail2ban-client status sshd покажет список забаненных IP.

Fail2Ban – автоматизированный ответ на настойчивые атаки, значительно снижающий нагрузку на ваш сервер.

Для экстремальной безопасности (например, на серверах с критически важными данными) можно добавить второй фактор аутентификации. Даже если приватный ключ будет скомпрометирован (кража устройства + знание passphrase), злоумышленник не сможет войти без одноразового кода.

Как работает? После успешной проверки SSH-ключа сервер запрашивает одноразовый код (TOTP - Time-based One-Time Password), который генерируется приложением на вашем телефоне (Google Authenticator, Authy, FreeOTP).

Установка (на сервере):

# Debian/Ubuntu
sudo apt install libpam-google-authenticator -y

# CentOS/RHEL
sudo yum install google-authenticator -y # Возможно из EPEL

# Fedora
sudo dnf install google-authenticator -y

Настройка для пользователя:

Войдите под пользователем, для которого настраиваете 2FA.

Выполните: google-authenticator. Ответьте на вопросы:

Do you want authentication tokens to be time-based (y/n) -> y
Отсканируйте QR-код в приложении аутентификатора на телефоне (или введите секрет вручную).
Запишите/сохраните в надежном месте резервные коды (emergency scratch codes)! Они нужны, если телефон потерян.
Do you want me to update your "/home/пользователь/.google_authenticator" file (y/n) -> y
Do you want to disallow multiple uses of the same authentication token? -> y (Увеличивает безопасность)
Do you want to increase the time window? -> n (Окно по умолчанию оптимально)
Do you want to enable rate-limiting? -> y (Защита от перебора кодов)

Настройка PAM и SSH:

Отредактируйте файл PAM для SSH: sudo nano /etc/pam.d/sshd
Добавьте строку: auth required pam_google_authenticator.so (обычно в конец, но перед @include common-auth если он есть и если PasswordAuthentication отключен). Порядок может быть критичен!

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

ChallengeResponseAuthentication yes # Разрешить challenge-response (необходимо для 2FA)
UsePAM yes # Обязательно должно быть включено
AuthenticationMethods publickey,keyboard-interactive # Сначала ключ, потом 2FA
# ИЛИ publickey keyboard-interactive (без запятой, в старых версиях)

Перезапустите SSH: sudo systemctl restart sshd.

Тестирование: При следующем входе по SSH после запроса passphrase ключа вас спросят: Verification code:. Введите код, показанный в вашем приложении-аутентификаторе. После этого вход завершится.

2FA добавляет серьезный барьер, но усложняет вход. Используйте его там, где это оправдано уровнем риска.

Безопасность – это процесс, а не разовая настройка.

Управление ключами:

Несколько ключей: Имеет смысл генерировать отдельные ключи для разных устройств (рабочий ПК, ноутбук, домашний ПК) или разных серверов/ролей. Удаляйте с сервера публичные ключи устройств, которые больше не используются или потеряны.

Агент SSH (ssh-agent): Программа, которая хранит ваши расшифрованные приватные ключи в памяти во время сеанса работы. Позволяет вводить passphrase только один раз при старте сессии и затем использовать ключи без повторного ввода для подключений к другим серверам или SCP/SFTP. Включен по умолчанию в большинстве окружений.

Конфиг SSH клиента (~/.ssh/config): Упрощает подключение:

Host myserver
HostName ваш_ip_адрес
Port ваш_новый_порт
User ваш_новый_пользователь
IdentityFile ~/.ssh/id_ed25519_myserver

Теперь вместо ssh -p 24596 deploy@203.0.113.42 можно просто ssh myserver.

Ротация ключей: Периодически (раз в 6-12 месяцев или при подозрении на компрометацию) генерируйте новые пары ключей. Удаляйте старые публичные ключи с серверов.

Аудит и мониторинг:

Просмотр логов SSH: Регулярно проверяйте /var/log/auth.log (Debian/Ubuntu) или /var/log/secure (RHEL/CentOS). Ищите подозрительные попытки входа (особенно на root или известные имена пользователей, на старый порт 22).
Команда last: Показывает историю входов пользователей. last -i показывает IP-адреса.
Команда who или w: Показывает текущих пользователей на сервере.

Резервное копирование конфигов: Регулярно копируйте критически важные конфиги (/etc/ssh/sshd_config, /etc/fail2ban/jail.local, /etc/ufw/* или правила firewalld/nftables) на безопасное внешнее хранилище. Это спасет при сбое сервера.