Как часто нужно обновлять SSH ключи?

Коротко: большинство экспертов рекомендуют менять SSH‑ключи раз в 6 - 12 месяцев, но частота зависит от уровня риска и требований безопасности. Современные рекомендации подчёркивают, что ключи нельзя оставлять "вечными", потому что со временем они превращаются в скрытый риск для инфраструктуры.

1. Для личных проектов и своего сервера

Рекомендуемая частота: Раз в 1 год (или даже реже).

Для личного использования (если вы единственный администратор) частая смена ключей может создать больше проблем, чем пользы (например, риск потерять доступ при неправильной замене). Главное правило: Меняйте ключ немедленно, если:

• Вы потеряли ноутбук или флешку с ключом.

• Вы подозреваете, что ваш компьютер был заражен вирусом.

• Вы случайно "засветили" приватный ключ (выложили на GitHub, отправили в чат и т.д.).

2. Для работы и продакшна (Лучшая Практика)

Рекомендуемая частота: Раз в 3-6 месяцев.

В корпоративной среде риски выше.

• Стандарт PCI DSS (для работы с картами), из-за него многие корпоративные регламенты требуют ротацию каждые 90 дней (корпоративной среде существует огромная разница между "что написано в стандарте" и "что требуют аудиторы / безопасники на местах".)

• Это защищает от сценария, когда ключ был украден тихо (без вашего ведома) и злоумышленник использует его месяцами.

PCI DSS (Payment Card Industry Data Security Standard) - это "золотой стандарт" безопасности для любой организации, которая хранит, обрабатывает или передает данные банковских карт (Visa, Mastercard, МИР).

SSH - это главная дверь для управления сервером. Если ваш сервер имеет отношение к платежам или картам, то настройки SSH становятся объектом пристального внимания аудиторов PCI DSS.

Даже если вы не банк, требования PCI DSS полезно знать, потому что это готовая инструкция "как сделать действительно безопасно".

1. Запрет прямого входа root (Требование 8.6)

• Что требует стандарт: Каждое действие на сервере должно быть привязано к конкретному человеку. Если все заходят под общим логином root, то в логах будет видно «root удалил базу данных», но непонятно, кто именно это был - Вася или Петя.

• Ваша ситуация: Вы только что создали личного пользователя (h...) и отключили PermitRootLogin. Это полное соответствие стандарту. Теперь в логах будет видно: "Пользователь h... повысил права до root и удалил базу".

2. Запрет простых паролей и использование криптографии (Требование 2.3)

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

• Ваша ситуация: SSH сам по себе шифрует трафик. А отключение входа по паролю (PasswordAuthentication no) и переход на ключи - это лучшая практика (Best Practice), которую аудиторы очень любят.

3. Регулярная смена ключей (Требование 3.6.4)

• Что требует стандарт: Криптографические ключи (Ключи шифрования данных (Data Encryption Keys)) должны меняться по расписанию (обычно каждые 90 дней), а старые - уничтожаться.

• Что это: Это ключи, которыми шифруется сама база данных с номерами карт. Если хакер украдет этот ключ и дамп базы, он сможет прочитать номера карт.

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

4. Не использовать "дефолтные" настройки (Требование 2.1)

• Что требует стандарт: Нельзя использовать пароли и настройки, которые идут "из коробки" (vendor-supplied defaults).

• Ваша ситуация: Вы уже изменили порт (если меняли?), отключили рута, создали своего юзера. Вы уже не используете дефолт.

Стандарт PCI DSS настоятельно рекомендует (а версия 4.0 требует) двухфакторную аутентификацию (MFA) даже для администраторов. PCI DSS не предписывает конкретный метод, например "SSH‑ключ + код Google Authenticator". Он требует наличия MFA, а конкретная реализация остаётся на усмотрение организации!

3. Критические ситуации (Менять немедленно)

В этих случаях расписание не имеет значения - нужно действовать сразу:

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

2. Скомпрометированное устройство. Логика "я почистил компьютер антивирусом, значит всё в порядке" здесь не работает. Вирусы (трояны, стилеры) настроены искать именно файлы в папке .ssh. Как только вирус попадает на компьютер, он мгновенно копирует эти файлы и отправляет их злоумышленнику. Вы можете возразить: "Но у меня ключ защищен паролем (passphrase)!". Если устройство скомпрометировано, скорее всего, на нем работал кейлоггер (программа, записывающая нажатия клавиш). Когда вы вводили пароль, чтобы разблокировать ключ, хакер получил и файл ключа, и пароль к нему.

3. Смена алгоритмов шифрования. Если вы использовали старые ключи RSA-1024 или DSA (которые сейчас считаются слабыми), их нужно срочно заменить на современные Ed25519 или RSA-4096.

Частая ошибка при обновлении

Многие думают, что создание нового ключа автоматически отменяет старый. Это не так. SSH-сервер пускает по списку ключей. Если вы добавите новый ключ, но забудете удалить строку со старым ключом из файла ~/.ssh/authorized_keys, то старый ключ продолжит работать.

Правильный алгоритм ротации:

1. Сгенерировать новую пару ключей (ssh-keygen -t ed25519).

2. Добавить новый публичный ключ на сервер.

3. Проверить вход с новым ключом.

4. Удалить старый публичный ключ из файла authorized_keys на сервере.

5. Удалить старый приватный ключ с локального компьютера.