Как настроить SSH-доступ к серверу без лишних рисков

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

Я не теоретик. Настраивал доступ к серверам в хостерских дата-центрах, поднимал VPS для бухгалтерий, вытаскивал данные после атак шифровальщиков и восстанавливал серверы, куда админы сами себя заперли, отключив пароль раньше, чем проверили ключ. Поэтому расскажу без воды: как сделать SSH-доступ действительно безопасным, но не превратить сервер в бункер, куда самому не попасть.

Почему SSH нужно настраивать сразу и правильно

Когда заказываешь новый VPS у хостера или ставишь систему с нуля, SSH обычно сконфигурирован по шаблону, который безопасным не назовёшь. Дефолтная картина выглядит примерно так:

• доступ открыт по паролю, причём иногда root вообще без пароля — видел такие чудеса на дешёвых VPS-площадках;
• root может заходить напрямую;
• порт 22 торчит на весь белый свет;
• нет ограничений по IP — стучаться могут откуда угодно, хоть с ботнета в Юго-Восточной Азии;
• ключи не настроены, список доверенных пользователей никак не ограничен.

Для злоумышленника такой сервер — не цель, а статистика. Сканеры шарят по диапазонам IP круглосуточно. Находят открытый 22-й порт — и пошла жара: перебор логинов по словарю, проверка типовых паролей вроде admin/admin или root/toor, попытки эксплуатации старых уязвимостей в SSH-сервере. Я однажды ради эксперимента поднял «голый» сервер с дефолтными настройками — первые попытки подбора пароля начались через 14 минут после того, как IP появился в интернете. Четырнадцать минут.

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

Базовый принцип безопасного SSH

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

• вход только по криптографическому ключу, парольная аутентификация отключена как класс;
• прямой root-доступ запрещён — сначала заходим под обычным пользователем, потом через sudo повышаем привилегии;
• SSH открыт только для конкретных пользователей, а не для всех учётных записей в системе;
• сервер не светит SSH наружу без необходимости — либо фильтрация по IP, либо вход через VPN;
• активен механизм защиты от перебора, который банит назойливых стукачей;
• ведутся логи, и администратор хотя бы раз в неделю в них заглядывает.

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

Что нужно подготовить перед настройкой

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

Что должно быть под рукой:

• консольный доступ через панель управления хостера — KVM, VNC или что там предоставляет провайдер. Без этого на удалённом сервере вообще не экспериментируйте;
• альтернативный способ входа, если основной SSH отвалится — та же консоль, IPMI, удалённый рабочий стол;
• актуальная резервная копия текущего конфигурационного файла /etc/ssh/sshd_config, чтобы в случае чего откатиться;
• чёткое понимание, кто именно и зачем должен иметь доступ к серверу — не «на всякий случай», а по факту рабочих задач.

Главная ошибка новичков: берут и сразу отключают парольную аутентификацию вместе с root-доступом, а ключ ещё не проверили. Одна сессия закрыта, вторая уже не открывается, сервер далеко, hands-on консоли нет. Всё, приехали. Поэтому любое изменение проверяем параллельно в отдельной сессии, не закрывая текущую, пока не убедимся, что новый вход работает стабильно.

Шаг 1. Создайте отдельного пользователя для администрирования

Сидеть на сервере под root через SSH — это как ходить по стройке без каски. Вроде удобно, но одна неловкая команда, и последствия фатальны. Любая опечатка в rm -rf или chmod может положить систему. Поэтому первым делом создаём обычного пользователя и даём ему права на повышение через sudo.

Пример:

adduser adminuser
usermod -aG sudo adminuser

Теперь adminuser — обычная учётная запись без суперсилы, но при необходимости он может выполнить sudo и сделать то, что нужно. В чём профит:

• снижается шанс случайно убить систему одной неосторожной командой — под обычным пользователем для разрушительных действий нужен явный sudo;
• появляется аудит: в логах видно, кто именно и когда использовал повышенные привилегии;
• если учётную запись скомпрометируют, злоумышленник получит не root, а ограниченного пользователя, и ему ещё придётся повышать права через уязвимости или подбор пароля к sudo.

В своей практике я всегда завожу минимум двух администраторов с sudo, особенно если сервер рабочий и downtime критичен. Человеческий фактор никто не отменял: уволится админ, уедет в отпуск, заболеет — должен остаться тот, кто сможет зайти.

Шаг 2. Настройте вход по SSH-ключу

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

Создаём пару ключей на своей машине — я рекомендую Ed25519, он быстрее и компактнее старого RSA, а безопасность на уровне, который пока никто не сломал:

ssh-keygen -t ed25519 -C "комментарий_для_себя"

Система спросит, куда сохранить ключ и задать ли passphrase. Насчёт passphrase отдельно: обязательно задайте. Если вашу рабочую машину украдут или к ней получат доступ, без passphrase приватный ключ сольют мгновенно. С passphrase у атакующего появляется дополнительный барьер.

Дальше закидываем публичный ключ на сервер:

ssh-copy-id adminuser@your-server-ip

Если утилита ssh-copy-id по каким-то причинам недоступна — например, вы работаете с минималистичной системой или Windows без WSL, — то действуем вручную. Копируем содержимое файла ~/.ssh/id_ed25519.pub и добавляем его на сервере в файл /home/adminuser/.ssh/authorized_keys. Права на файл должны быть 600, иначе SSH откажется его читать из соображений безопасности.

Важные моменты, за которые меня дёргали после аудитов чужих серверов:

• не используйте один ключ для всего парка машин — если он утечёт, под угрозой окажется всё сразу;
• не храните приватные ключи в мессенджерах, облаках и общих папках — это прямой путь к компрометации;
• если есть подозрение, что ключ скомпрометирован, немедленно удаляйте его из authorized_keys на всех серверах, а не через неделю, когда найдёте время.

Шаг 3. Отключите вход по паролю

Когда вход по ключу протестирован и работает стабильно, парольную аутентификацию можно и нужно отключить. Это отсекает 99% автоматических атак — брутфорс просто теряет смысл, потому что подбирать нечего.

Открываем конфиг SSH-сервера:

sudo nano /etc/ssh/sshd_config

Находим или добавляем параметры:

PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM yes

После этого демона нужно перезапустить:

sudo systemctl restart ssh

В некоторых дистрибутивах служба называется sshd, не перепутайте.

Снова заклинаю: никогда не отключайте пароль, не проверив вход по ключу в отдельной сессии. Это как запирать дверь, не убедившись, что ключ от неё у вас в кармане, а не остался внутри. Типовая ситуация из практики: админ правит конфиг, сохраняет, перезапускает SSH и закрывает текущую сессию. Открывает новую — доступ не идёт ни по ключу, ни по паролю. Итог: потеря доступа, вызов в дата-центр или восстановление через rescue-режим. Держите рабочую сессию открытой, пока не убедитесь, что свежий вход с нового окна терминала проходит без проблем.

Шаг 4. Запретите прямой вход под root

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

В конфиге SSH правим параметр:

PermitRootLogin no

После этого зайти под root через SSH невозможно в принципе — только сначала под обычным пользователем, а потом sudo. Схема простая и надёжная.

Ситуации, когда это особенно критично:

• сервер доступен напрямую из интернета — тут без вариантов, root должен быть закрыт;
• на сервере установлена панель управления вроде ISPmanager или VestaCP, куда заходят несколько администраторов — каждый должен работать под своей учётной записью;
• к машине имеют доступ подрядчики или фрилансеры, которым вы даёте временный доступ — root им точно не нужен;
• сервер обслуживает компанию, где важен аудит и разграничение ответственности — логи с sudo показывают, кто и что делал, а безликий root скрывает конкретного исполнителя.

Шаг 5. Ограничьте список пользователей и групп

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

Явно ограничиваем круг допущенных:

AllowUsers adminuser

Или через группу:

AllowGroups sshusers

В группу sshusers добавляем только тех, кому действительно нужен удалённый доступ к серверу. Право находиться в системе и право входить по SSH — это два разных уровня. Сервисный пользователь nginx или mysql не должен иметь SSH-доступа по определению.

Практический смысл здесь двойной: уменьшается поверхность атаки, и при аудите сразу видно, кто вообще может стучаться к серверу. Не придётся через полгода гадать, что за учётная запись tester123 с паролем qwerty делает в списке допущенных.

Шаг 6. Смените порт только после базовой защиты

Смена порта — мера спорная, но в комплексе с остальными работает неплохо. Сама по себе она не сделает SSH безопасным, зато снижает количество мусорного трафика от автоматических сканеров и ботов, которые долбятся на порт 22 по всем известным диапазонам IP. Меньше шума — проще замечать действительно подозрительную активность в логах.

Меняем порт, когда ключи уже настроены и парольная аутентификация отключена:

Port 2222

После изменения не забудьте:

• открыть новый порт в брандмауэре, иначе SSH просто не пройдёт;
• протестировать вход на новом порту до того, как закроете старую сессию;
• не отключать старый порт, пока не убедитесь, что на новом всё работает.

Честно скажу: смена порта от целенаправленной атаки не защитит. Профессионал просканирует все открытые порты и найдёт SSH, на каком бы порту он ни висел. Это именно мера против автоматического шума и пассивных сканеров.

Шаг 7. Настройте брандмауэр и доступ по IP

Лучшая защита — не показывать SSH тому, кому он не нужен. Если вы подключаетесь к серверу только из офиса, из дома или через VPN, ограничьте доступ по IP-адресам. В идеальной картине мира у каждого администратора статический или закреплённый IP, и брандмауэр пропускает только их.

Логика простая:

• разрешаем входящие подключения по SSH только с доверенных адресов;
• всё остальное блокируется на уровне файрвола;
• если IP динамический и постоянно меняется, то доступ организуем через VPN или через промежуточный bastion-хост с фиксированным адресом.

Инструменты зависят от дистрибутива: ufw для Ubuntu, firewalld для CentOS, iptables для старых систем. Суть одна: SSH не должен торчать наружу для всего интернета, если к нему подключаются два человека из известных сетей.

Таблица: что даёт каждая мера

Шаг 8. Включите защиту от перебора

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

Стандартный инструмент — fail2ban. Он мониторит логи и временно банит IP-адреса, с которых идёт слишком много неудачных попыток подключения за короткий промежуток времени.

Установка:

sudo apt install fail2ban

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

Fail2ban особенно полезен, если:

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

Шаг 9. Проверьте параметры безопасности SSH-конфига

В sshd_config есть ряд настроек, которые часто оставляют по умолчанию, а зря. Я всегда проверяю и правлю эти параметры, потому что дефолтные значения рассчитаны на совместимость, а не на безопасность.

PermitEmptyPasswords no
X11Forwarding no
AllowAgentForwarding no
ClientAliveInterval 300
ClientAliveCountMax 2

Что даёт каждый параметр:

• PermitEmptyPasswords no — категорически запрещает вход с пустым паролем. Казалось бы, очевидно, но я встречал системы, где это было разрешено;
• X11Forwarding no — отключает пересылку графического вывода через SSH. В серверной среде это почти никогда не нужно и только расширяет поверхность атаки;
• AllowAgentForwarding no — снижает риск злоупотребления SSH-агентом. Если агент проброшен на скомпрометированный сервер, атакующий может использовать его для прыжка на другие машины;
• ClientAliveInterval и ClientAliveCountMax — помогают автоматически разрывать зависшие сессии, которые иначе могут болтаться часами и создавать ненужные риски.

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

Шаг 10. Включите двухфакторную аутентификацию, если риск высокий

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

Вторым фактором может быть:

• TOTP-код из приложения вроде Google Authenticator или его аналогов;
• аппаратный ключ типа YubiKey — самый надёжный вариант, но требует физического устройства;
• комбинация SSH-ключа и единоразового пароля.

Когда 2FA действительно оправдана

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

Когда можно обойтись без неё

• небольшая домашняя лаборатория с тестовыми проектами;
• сервер без чувствительных данных, где потеря не критична;
• доступ только через VPN и строго по ключам с ограничением IP;
• жёстко зафиксированный список адресов, с которых возможен вход.

Я ставлю 2FA на серверы, где крутится что-то важное и куда могут заходить люди, не всегда следующие лучшим практикам безопасности. Лишняя страховка не помешает, если цена ошибки высока.

Практический сценарий безопасной настройки SSH

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

1. Создайте обычного пользователя с sudo-правами — не пропускайте этот шаг, root через SSH должен уйти в прошлое.
2. Сгенерируйте ключевую пару Ed25519 и настройте вход по ключу.
3. Откройте вторую SSH-сессию и проверьте, что вход по ключу работает без ошибок.
4. Только после успешной проверки запретите парольную аутентификацию.
5. Отключите прямой вход под root.
6. Ограничьте список пользователей или групп, которым разрешён SSH.
7. При необходимости смените порт — но помните, что это косметическая мера, а не панацея.
8. Настройте брандмауэр так, чтобы SSH был открыт только с доверенных IP-адресов.
9. Подключите fail2ban для защиты от автоматических переборов.
10. Финальная проверка: сделайте контрольный вход с новой сессии, убедитесь, что всё работает.

Частые ошибки при настройке SSH

За годы работы я наступал на все эти грабли и вытаскивал из них коллег. Вот самые частые и болезненные ошибки.

1. Отключили пароль раньше проверки ключа

Самая популярная и самая фатальная. Особенно горько, когда сервер физически находится в дата-центре на другом конце страны, а консольного доступа нет. Лечится только выездом или долгими переговорами с техподдержкой провайдера. Всегда держите минимум две активные сессии во время настройки.

2. Оставили root-вход «на всякий случай»

Этот «всякий случай» обычно и становится точкой входа. Если root открыт, то именно его будут атаковать в первую очередь — это самая очевидная цель с максимальными привилегиями. Нет никакого случая, ради которого стоит оставлять PermitRootLogin yes.

3. Переоценили смену порта

Порт 2222 вместо 22 не спасёт, если root открыт и пароль password123. Смена порта — дополнение к базовой защите, а не замена ей. Не обманывайте себя ложным чувством безопасности.

4. Хранят приватный ключ без защиты

Если приватный ключ лежит в открытом виде и его украли вместе с ноутбуком или слили через облако, вся ваша SSH-защита рушится мгновенно. Обязательно используйте passphrase на ключ и не храните его там, где могут найти посторонние.

5. Не контролируют, у кого есть доступ

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

6. Не проверяют логи

Без регулярного просмотра логов вы просто не узнаете, что сервер атакуют, пока не случится что-то серьёзное. А по логам можно заранее увидеть подозрительную активность, заблокировать адреса и понять, какие меры нужно усилить.

Как проверить, что SSH настроен нормально

Перед тем как закрывать тикет по настройке и идти пить чай, пробегитесь по короткому чек-листу. Лучше потратить пять минут сейчас, чем потерять доступ к серверу потом.

• вход по ключу работает — проверено в свежей сессии, а не в той, где вы правили конфиг;
• парольный вход отключён — попытка зайти без ключа или с неправильным ключом должна немедленно получать отказ;
• root через SSH не входит — проверьте фактически, а не только по конфигу;
• доступ разрешён только нужным пользователям — лишних учёток в AllowUsers или AllowGroups нет;
• лишние порты не открыты — брандмауэр настроен, SSH слушает только то, что должно;
• логи SSH пишутся, и вы знаете, где их смотреть;
• конфигурационный файл забэкаплен — в случае неудачных экспериментов всегда можно откатиться;
• вы знаете, как восстановить доступ через консоль провайдера, если SSH внезапно умрёт.

Мини-чек-лист для администратора

• Создан отдельный пользователь для входа.
• Настроен ключ ED25519.
• Парольная аутентификация отключена.
• PermitRootLogin no.
• Ограничены пользователи или группы.
• Брандмауэр пропускает SSH только от нужных адресов.
• При необходимости подключён fail2ban.
• Есть резервный способ входа.
• Проверен вход после перезапуска сервиса.

Когда лучше использовать VPN вместо прямого SSH

Идеальный сценарий, к которому я стараюсь привести все проекты — SSH не торчит наружу вообще. Сервер висит во внутренней сети или за VPN-шлюзом, и прежде чем получить доступ к командной строке, администратор должен сначала подключиться к защищённому туннелю. Это дополнительный рубеж, который отсекает практически все автоматические атаки.

Такой подход особенно хорош, если:

• у вас не один сервер, а парк из десятков машин — управлять доступом удобнее через единую точку входа;
• доступ нужен только сотрудникам с проверенными устройствами и клиентами VPN;
• важна сегментация сети и чёткое разделение, кто куда может подключаться;
• сервер находится на белом IP, и его постоянно сканируют боты.

Настроить WireGuard или OpenVPN один раз проще, чем потом разгребать последствия атаки. И да, заодно решается проблема с фильтрацией по IP, даже если у администраторов динамические адреса.

Вывод

Безопасный SSH — это не магия и не одна галочка в конфигурационном файле. Это последовательность простых, логичных и проверенных временем решений: ключи вместо паролей, запрет прямого root-доступа, ограничение круга пользователей, защита от перебора и строгий контроль сетевого доступа. Если внедрить всё это методично и без спешки, SSH останется удобным инструментом для администрирования и перестанет быть дырой, в которую рано или поздно постучатся.

FAQ

Можно ли оставить SSH на порту 22?

Да, без проблем. Порт 22 сам по себе не угроза, если вход только по ключу, root отключён, доступ ограничен по IP или через VPN. Менять порт имеет смысл скорее для уменьшения шума в логах, чем для реальной защиты.

Что безопаснее: пароль или ключ?

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

Нужно ли менять порт SSH?

Можно, но это вторичная мера. Она уменьшает количество автоматических попыток входа и засорение логов, но не заменяет отключение пароля, запрет root и фильтрацию по IP. Смену порта я делаю после того, как всё основное уже настроено.

Что делать, если потерян доступ после настройки?

Использовать консоль провайдера — KVM, VNC, IPMI, что даёт хостинг. Если такой возможности нет, загружаться в rescue-режим и править конфиг оттуда. Поэтому все изменения вносим только после того, как проверили новый способ входа в отдельной сессии.

Нужен ли fail2ban, если пароль отключён?

Да, это осмысленная дополнительная защита. Во-первых, он блокирует сам факт назойливого сканирования. Во-вторых, защищает не только SSH, но и другие сервисы. В-третьих, снижает нагрузку от мусорного трафика, который всё равно пытается долбиться к серверу.