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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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