Безопасные пароли для админки и SSH: живой пример

Владелец небольшого магазина использовал один пароль для админки сайта, почты и SSH-доступа к серверу. После утечки пароля злоумышленнику не пришлось подбирать ключи: достаточно было проверить несколько знакомых адресов. Ниже — практический сценарий для Linux-сервера с OpenSSH 9.x и веб-админки: как развести секреты, перейти на SSH-ключи и не отрезать себе вход при настройке.

Сценарий: один пароль оказался в трёх местах

Представим сервер с сайтом, панелью управления CMS и отдельной учётной записью администратора. Пароль у неё короткий, используется повторно, а вход по SSH разрешён для этой же учётной записи. Такой набор опасен не из-за одной конкретной настройки, а из-за цепочки:

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

Безопасная схема начинается не с «самого сложного пароля», а с разделения точек входа: отдельный пароль для админки, отдельная учётная запись и ключ для SSH.

Термин: SSH-ключ — пара из закрытой и открытой частей. Закрытая хранится у вас и не передаётся серверу, открытая записывается в учётную запись на сервере. Сервер проверяет, что у подключающегося есть соответствующий закрытый ключ.

Что выбрать для админки и SSH

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

Практика: приводим доступы в порядок

1. Сначала составьте карту входов

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

Проверка результата: у каждого сервиса есть отдельный логин и понятный план смены секрета.

2. Замените пароль админки

Сгенерируйте в менеджере паролей случайную последовательность. Длина и допустимые символы зависят от конкретной CMS, поэтому ориентируйтесь на её форму смены пароля. Не превращайте фразу вроде Site-2025! в «сложный пароль»: предсказуемые шаблоны не компенсируют повторное использование.

Сохраните новый пароль только в менеджере. Затем завершите активные сессии в админке, если такая возможность есть, и войдите заново. Включите 2FA через приложение-аутентификатор или аппаратный ключ, если CMS и ваш тариф это поддерживают. Коды восстановления храните отдельно от основного пароля.

Проверка результата: вход работает с новым секретом, старый пароль отклоняется, а второй фактор запрашивается в новом сеансе.

3. Создайте отдельную учётную запись для SSH

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

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

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

4. Создайте ключ Ed25519 на своём компьютере

Для актуального клиента OpenSSH 9.x команда выглядит так:

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_admin

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

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

5. Добавьте открытый ключ и проверьте вход

Добавьте содержимое файла ~/.ssh/id_ed25519_admin.pub в файл ~/.ssh/authorized_keys новой учётной записи. Сделать это можно штатным способом, который поддерживает ваш сервер, или через уже работающий сеанс. Права на каталог .ssh и файл ключей должны соответствовать требованиям OpenSSH; если они слишком широкие, сервер может проигнорировать ключ.

Подключитесь в новом окне, явно указав закрытый ключ:

ssh -i ~/.ssh/id_ed25519_admin adminuser@server.example

Замените adminuser и server.example на свои значения. Не вставляйте в команду парольную фразу или закрытый ключ. Проверка результата: новое соединение открывается по ключу, а старое соединение всё ещё доступно для отката.

6. Только после проверки отключите вход по паролю

Настройка обычно находится в конфигурации демона SSH, но путь к файлу и имя службы зависят от дистрибутива. Перед изменением сделайте резервную копию конфигурации. В конфигурации OpenSSH 9.x параметр входа по паролю задаётся как PasswordAuthentication no. Если вы также запрещаете вход root, сначала убедитесь, что новая учётная запись действительно может выполнять необходимые операции.

Проверьте конфигурацию командой, которую предоставляет установленный OpenSSH:

sshd -t

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

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

Что обычно ломается

• Permission denied (publickey). Сервер не принял ключ. Проверьте имя пользователя, путь к открытому ключу, права на .ssh и соответствие закрытой и открытой частей.
• Bad permissions. OpenSSH считает файл ключей или каталог слишком доступными для других пользователей. Исправьте владельца и права по документации вашего дистрибутива, затем повторите подключение.
• Connection refused. На указанном адресе и порту никто не принимает соединение, служба остановлена или доступ блокирует сетевой фильтр. Это не ошибка пароля.
• Ключ работает только на одном компьютере. Это ожидаемо, если закрытый ключ есть только на нём. Для второго устройства создайте отдельную пару, а не копируйте закрытый ключ без необходимости.
• После отключения паролей никто не входит. Вернитесь через сохранённую сессию или консоль хостинга, проверьте конфигурацию и наличие открытого ключа. Если резервного канала нет, настройку лучше не начинать в удалённом сервере.

Когда схема ломается и что проверить дальше

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

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