SSH-ключи вместо пароля для нескольких администраторов сервера

MAATRIX GAMES

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

Почему общий пароль по SSH — это плохая идея

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

Второй момент — пароли по SSH нормально брутфорсятся. Боты сканируют весь диапазон IP и долбят порт 22 подбором стандартных логинов (root, admin, ubuntu) со словарями паролей круглые сутки — это не гипотетическая угроза, а фоновый шум интернета, который увидит любой сервер с открытым портом. Слабый или переиспользованный пароль рано или поздно попадёт под раздачу, а если у вас ещё и включён PasswordAuthentication yes — это открытая дверь.

SSH-ключи решают обе проблемы разом: подобрать приватный ключ перебором нереально (это не пароль из 8 символов, а пара чисел на 256+ бит), а доступ каждого конкретного человека привязан к его собственному ключу и отзывается независимо от остальных.

Как устроена связка ключей: коротко о механике

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

Рекомендуемый тип ключа на 2026 год — ed25519: короче, чем RSA, генерируется и проверяется быстрее, а криптостойкость выше при том же уровне защиты. RSA на 4096 бит тоже приемлем и нужен, если у кого-то в команде древний клиент без поддержки ed25519, но для новой команды выбирайте ed25519 по умолчанию.

Генерация ключа для каждого админа

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

ssh-keygen -t ed25519 -C "ivan@maatrix-team"

Флаг -C — просто комментарий-метка, обычно имя или email, чтобы потом в списке ключей на сервере было понятно, чей это доступ. При генерации ssh-keygen спросит путь для сохранения (по умолчанию ~/.ssh/id_ed25519) и passphrase — пароль на сам ключ. Passphrase настоятельно рекомендуется ставить: если ноутбук админа украдут или взломают, голый приватный ключ без пароля — это мгновенный доступ на сервер, а с passphrase у злоумышленника есть только бесполезный файл.

После генерации получаются два файла:

• ~/.ssh/id_ed25519 — приватный ключ, остаётся только у владельца, никогда не покидает его машину;
• ~/.ssh/id_ed25519.pub — публичный ключ, его и нужно передать вам для добавления на сервер (по почте, в Discord, как угодно — это не секрет, публичный ключ бесполезен без пары к нему).

Добавление ключей на сервер: authorized_keys

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

Самый быстрый способ добавить ключ, если у вас уже есть доступ по паролю — ssh-copy-id с машины админа:

ssh-copy-id -i ~/.ssh/id_ed25519.pub admin@ваш-ip

Команда сама допишет содержимое .pub-файла в authorized_keys на сервере и выставит правильные права. Если ssh-copy-id недоступен (например, доступ с Windows без WSL) — добавьте вручную с сервера:

mkdir -p ~/.ssh && chmod 700 ~/.ssh
echo "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... ivan@maatrix-team" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

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

Если у вас несколько админов ходят под одним системным пользователем (например, все под admin с sudo) — просто добавляйте по одному публичному ключу на строку в тот же файл, каждый со своим комментарием в конце строки для узнаваемости. Если у каждого свой личный аккаунт в системе (что правильнее с точки зрения ролей и разделения прав) — у каждого пользователя свой authorized_keys в своей домашней папке.

Ограничение ключа: что он может делать

Опционально, но полезно для доступа с ограниченными правами — можно навесить на конкретную строку в authorized_keys префикс с ограничениями, например запретить проброс портов и X11 для ключа, который используется только для деплоя или мониторинга:

restrict,command="/usr/local/bin/deploy-check.sh" ssh-ed25519 AAAAC3... deploy-bot

Директива restrict разом отключает port-forwarding, agent-forwarding, X11 и pty — то есть ключ можно использовать только для того, что явно разрешено command=. Для живых людей-админов это обычно избыточно, но пригодится, если заведёте отдельный сервисный ключ для CI/CD-скрипта или бота, который перезапускает сервер по расписанию.

Отзыв доступа при уходе администратора

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

nano ~/.ssh/authorized_keys

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

Практика для команды больше двух-трёх человек — держать список активных ключей и их владельцев в отдельном документе (Notion, обычный текстовик, что угодно), синхронизированном с реальным списком команды. Раз в 1-2 месяца сверяйте его с authorized_keys на сервере — забытый ключ уволенного полгода назад человека находят обычно только во время инцидента, а не планового аудита.

Отключение входа по паролю совсем

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

Редактируете /etc/ssh/sshd_config (на Ubuntu/Debian) и приводите к такому виду:

PasswordAuthentication no
PermitRootLogin prohibit-password
PubkeyAuthentication yes

PermitRootLogin prohibit-password — компромиссный вариант: root по-прежнему может зайти, но только по ключу, не по паролю (полностью PermitRootLogin no — ещё строже, но тогда сначала убедитесь, что sudo-доступ у не-root пользователей настроен и работает, иначе рискуете остаться без входа вообще). После правки — перезапуск демона:

systemctl restart sshd

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

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

Частые вопросы