Иметь систему, у которой срок действия ключей SSH истекает каждые 90 дней

Используя AuthorizedKeysCommand , на стороне сервера может быть реализован некоторый механизм истечения срока действия. От простой проверки метки времени файла до чего-то более сложного.

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

Обычно пользователи думают о паролях, которые они изменили, как о «уже не секретных». Они могут стать одноразовыми паролями для малоценных сайтов, онлайновыми дескрипторами / псевдонимами, анекдотами и т. Д., А любая бумага, на которой они написаны, может стать разоблаченным мусором.

Для парольной фразы, используемой для шифрования закрытого ключа , это не так ! Парольная фраза должна храниться в секрете навсегда , если все привилегии, связанные с ключом, не были отозваны (и следующее не относится к ssh-ключам, но если парольная фраза предназначена для ключа, используемого не только для подписи, но и для получения личных сообщений навсегда означает навсегда ). Это связано с возможностью того, что зашифрованный файл закрытого ключа был получен злоумышленником или где-то хранится (например, в резервной копии), где он может быть получен злоумышленником в будущем. Если кодовая фраза когда-либо раскрывается, она затем скомпрометирована.

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

Теперь вернемся к вашей проблеме.

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

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

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

Ответ на ваш первый вопрос: «Можно ли изменить пароль для существующего ключа SSH?» - да. С openssh это так же просто, как ssh-keygen -p [-P old_passphrase] [-N new_passphrase] [-f keyfile]

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

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

Добавьте многофакторную аутентификацию, если вам нужна дополнительная безопасность для учетной записи.

Но мне любопытно, что сделали другие люди, чтобы решить ваши серьезные проблемы.

Вы можете использовать ключевой агент, который включает временные одноразовые пароли (TOTP). Теперь ваш "пароль" меняется каждую минуту.

_{Все остальные здесь правы: это глупо.}

Вы можете использовать такой инструмент, как Hashicorp's Vault, для создания недолговечных подписанных ключей SSH . Каждый пользователь будет получать новый ключ каждый день (или около того). Вы должны пройти аутентификацию в Vault, чтобы получить сертификат, используя то, что вы используете сегодня, например, сервер LDAP.

Усилия по настройке этого не огромны, но, по моему опыту, больше, чем то, на что @Mark ссылался в своем комментарии. По сути, вы заменяете одну проблему (невежественные требования клиента) другой ( управление шардом ).

Но он позволяет реализовать несколько других сценариев, таких как простая генерация внутренних сертификатов X509 и управление паролями базы данных, секретами приложений в текстовом файле. Вы судите об усилиях и рентабельности инвестиций.

Также обратите внимание, что версия с открытым исходным кодом не имеет возможностей аварийного восстановления (в ней есть все остальное).

Одной из возможностей, которой может быть, а может и не хватить, является использование CA пользователя SSH, который позволяет вам установить время жизни для подписанного ключа. Независимо от того, какую автоматизацию вы используете для подписания ключей, вы можете отказаться от подписи более 90 дней. Затем добавьте открытый ключ для вашего пользовательского ЦС в TrustedUserCAKeys в / etc / ssh / sshd_config и установите для AuthorizedKeysFile значение none.