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

Если пароль от панели управления повторяется на почте, а SSH пускает по короткой комбинации, взлом одного аккаунта может открыть доступ и к серверу. Для админки используйте уникальный пароль и многофакторную аутентификацию, для SSH — ключ вместо пароля. Настроить и проверить это можно за 15–30 минут; ниже — порядок действий для Linux-сервера с OpenSSH 9.x и обычного компьютера.

Что подготовить

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

Команды ниже рассчитаны на OpenSSH 9.x. На клиенте выполните ssh -V, чтобы увидеть версию. В Linux-системах путь к настройкам сервера, имя службы и наличие команды ssh-copy-id могут различаться. Если команда установки ключа недоступна, используйте альтернативный вариант из шага 2.

Шаги настройки

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

ssh-keygen -t ed25519 -C "laptop-ssh"

Комментарий laptop-ssh — только метка, в неё не нужно помещать пароль или личные данные. Проверка: программа сообщает, что создала пару ключей; файлы обычно находятся в каталоге ~/.ssh. Закрытый файл, например id_ed25519, никому не отправляйте. Серверу передают только открытый файл с расширением .pub.

1. Установите открытый ключ на сервер. Если на клиенте есть ssh-copy-id, выполните команду, заменив имя и адрес на свои. При первом подключении она может запросить пароль серверной учётной записи.

ssh-copy-id -i ~/.ssh/id_ed25519.pub USERNAME@SERVER

Если команды нет, откройте файл ~/.ssh/id_ed25519.pub, скопируйте его содержимое и добавьте одной строкой в файл ~/.ssh/authorized_keys нужного пользователя на сервере. Не копируйте туда закрытый ключ. Проверка: открытый ключ добавлен именно в аккаунт, под которым вы подключаетесь.

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

ssh -i ~/.ssh/id_ed25519 USERNAME@SERVER

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

1. Только после проверки отключайте вход по SSH-паролю. В настройках сервера параметр PasswordAuthentication можно установить в no, если всем нужным пользователям уже доступен ключевой вход. Перед применением проверьте конфигурацию командой sshd -t; если она завершилась с ошибкой, не перезагружайте службу. Название службы и команда перезагрузки зависят от дистрибутива. Оставьте прежнюю сессию открытой и проверьте подключение в новом окне после применения настроек. Проверка: ключевой вход работает, а новый вход без ключа не проходит. Если это не так — верните прежнюю настройку из действующей сессии или консоли провайдера.

Если не получилось

• Permission denied (publickey). Сервер не принял ключ. Проверьте имя пользователя, адрес, путь к открытому ключу и наличие его содержимого в authorized_keys именно этого пользователя. Проверьте также права на домашний каталог и SSH-файлы: слишком открытые права могут заставить OpenSSH игнорировать ключ.
• ssh-copy-id: command not found. На клиенте нет этой утилиты. Установите пакет с клиентскими утилитами OpenSSH для своей ОС или добавьте открытый ключ вручную, как описано выше.
• Соединение завершилось сразу после изменения настроек. Не закрывайте оставшуюся сессию. Проверьте конфигурацию через sshd -t, исправьте ошибку и проверьте имя службы для своего дистрибутива. Если активной сессии уже нет, используйте консоль управления сервером у провайдера.
• Админка не принимает код второго фактора. Проверьте время на устройстве и выберите доступный способ восстановления. Не отключайте второй фактор по ссылке из неожиданного письма; используйте официальный адрес панели.

Где защита не поможет

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

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

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

Что делать дальше

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