Почему я использую несколько SSH-ключей вместо одного?

Это перевод оригинальной статьи Why I Run Multiple SSH Keys Instead of Just One.

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

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

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

🛑 Риск подхода «один ключ для всего»

Если вы используете один и тот же приватный SSH-ключ для всего, то даже малейшая компрометация может привести к катастрофическим последствиям:

Потеряли ноутбук? Теперь под угрозой каждый сервер, к которому имел доступ этот ключ.
Ключ был украден в менее защищённом окружении? Злоумышленники могут получить доступ к критически важным системам.
Нужно сменить ключи? Теперь вам приходится в спешке менять их везде.

Это классический пример проблемы радиуса поражения (blast radius).

🧩 Как я сегментирую свои ключи

Я использую отдельные SSH-ключи для:

1. Production

Хранится в аппаратном токене или защищенном хранилище ключей.
Используется только для критически важных серверов.
Никогда не покидает защищенные устройства

2. Staging/Test

Отдельно от production
Хранятся на рабочем ноутбуке
Легко заменяемы

3. Личные проекты

Для домашних лабораторий, персональных VPS, Raspberry Pi
Никогда не смешивайте с рабочими системами

4. Одноразовые/Временные

Создано для краткосрочных проектов или для доступа подрядчиков
Удаляется после использования

🛠 Мой рабочий процесс

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

ssh-keygen -t ed25519 -C "prod-key" -f ~/.ssh/id_ed25519_prod
ssh-keygen -t ed25519 -C "test-key" -f ~/.ssh/id_ed25519_test

Пример конфигурации SSH ( ~/.ssh/config):

Host prod-server
    HostName prod.example.com
    User admin
    IdentityFile ~/.ssh/id_ed25519_prod

Host staging-server
    HostName staging.example.com
    User dev
    IdentityFile ~/.ssh/id_ed25519_test

Таким образом, мне не нужно запоминать, какой ключ использовать — SSH автоматически выбирает правильный.

🧠 Почему это работает

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

📌 Заключение

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

Один ключ для всего может быть удобным… пока не станет проблемой.

На этом все! Спасибо за внимание! Если статья была интересна, подпишитесь на телеграм-канал usr_bin, где будет еще больше полезной информации.