Вопрос или проблема
Как я могу обеспечить соблюдение политики использования парольных фраз для фраз, используемых для шифрования закрытого ключа SSH?
Мне нравилось использовать модуль PAM pam_pwquality для обеспечения сложности пароля учетной записи пользователя, но я не думаю, что смогу использовать его с парольными фразами для ключей SSH.
Как я могу обеспечить соблюдение политики использования парольных фраз для фраз, используемых для шифрования закрытого ключа SSH?
В общем, вы не можете. Шифрование закрытого ключа – это процесс на стороне клиента, и большинство широко используемых клиентов SSH не имеют подобных функций (например, ничего похожего на интеграцию с групповыми политиками), тем более что очень легко обойти такие ограничения, используя другой SSH-клиент для повторного шифрования ключа.
Лучший подход может заключаться в хранении закрытых ключей на аппаратном уровне (например, чип TPM2 или его эквивалент для Apple, или Yubikey в режиме PIV/CCID), чтобы не существовало файла, который мог бы быть украден или скопирован. Такие аппаратные токены могут ограничивать количество попыток ввода PIN-кода, и, следовательно, можно безопасно использовать более слабый PIN-код (т.е. не усложняя жизнь вашему персоналу).
Для Linux, посмотрите на ssh-tpm-agent или tpm2_pkcs11. (Если все ваши машины имеют TPM2, то специальный ssh-agent легче использовать. С другой стороны, если у вас есть смешение TPM2 и Yubikey или других смарт-карт, вам придется много работать с PKCS#11.) Для Windows, к сожалению, собственного интеграции OpenSSH с CryptoAPI нет, но PuTTY-CAC должен хорошо работать с “Platform Key Storage Provider”, и возможно подключить OpenSSH к Pageant-CAC вместо ssh-agent.
В качестве альтернативы используйте одну из систем “SSH Certificate Authority”, которые выпускают краткосрочные пары ключей на основе другого вида аутентификации – сотрудники входят утром и получают SSH-сертификат, который можно использовать только в этот день (т.е. аналогично тому, как работает Kerberos). Это не совсем X.509 сертификаты, как в TLS, но концептуально похоже – вы создаете CA и выдаете сертификаты пользователям с помощью ssh-keygen.
Я полагаю, что последняя версия PuTTY поддерживает SSH-сертификаты, так что этот метод больше не ограничен только OpenSSH. Различные компании создали такие системы внутренне и опубликовали их на GitHub, часто адаптированные под свои собственные рабочие процессы; программное обеспечение step-CA возможно подойдет для этой задачи.
Наконец, если вы используете эту систему в сети Active Directory, вы также можете использовать реальный Kerberos, который уже есть в AD, вместо открытых ключей. Эта функция называется “GSSAPI authentication” в SSH; для этого требуется, чтобы у каждого сервера была учетная запись машины и keytab. В этом случае единственным паролем или парольной фразой будет тот же пароль AD, который уже подлежит проверке сложности пароля. (Это также можно настроить без AD.)
.
Ответ или решение
Как обеспечить сложность паролей для шифрования частных ключей SSH
При обеспечении безопасности в IT-инфраструктуре одним из ключевых аспектов является защита SSH ключей. Шифрование частных ключей SSH с паролями — это основной метод защиты от несанкционированного доступа. Однако, в отличие от пользовательских паролей, где модули вроде pam_pwquality позволяют задавать правила сложности, применение таких инструментов к паролям SSH-ключей сталкивается с рядом сложностей.
Технические ограничения
Во-первых, управление паролями для шифрования частных ключей SSH находится на стороне клиента. Большинство часто используемых SSH клиентов не поддерживают возможности интеграции с групповой политикой или иными инструментами enforce complexity. Даже если такие ограничения будут установлены, их легко обойти с помощью другого клиента, перешифровав ключ.
Альтернативные подходы
1. Аппаратные токены
Наилучшим решением может стать хранение частных ключей в безопасных аппаратных хранилищах, таких как чип TPM2 или токены Yubikey в режиме PIV/CCID. Эти устройства не только усложняют задачу несанкционированного копирования ключей, но и могут ограничить количество попыток ввода PIN-кода, таким образом предоставляя возможность использования более слабой, но удобной для пользователя аутентификации.
- Для Linux: Рассмотрите использование инструментов, таких как ssh-tpm-agent или tpm2_pkcs11.
- Для Windows: Несмотря на ограниченную поддержку CryptoAPI в OpenSSH, вы можете использовать PuTTY-CAC с поддержкой "Platform Key Storage Provider".
2. Системы сертификатов SSH
Другим методом является использование систем SSH сертификатов, которые выдают краткосрочные пары ключей на основе другой аутентификации. Такой подход позволяет сотруднику получать валидный SSH сертификат только на рабочий день, аналогично работе Kerberos.
- Программные решения, такие как step-CA, могут помочь в органиции такой инфраструктуры.
3. Аутентификация GSSAPI
На сетях с Active Directory рекомендуется использовать уже встроенную систему аутентификации Kerberos, известную как "GSSAPI аутентификация". Это позволяет применять те же политики сложности к паролям, что и внутри Active Directory.
Заключение
Обеспечение сложности паролей для частных ключей SSH требует комплексного подхода. Соблюдая указанные выше рекомендации, вы сможете значительно повысить безопасность вашей IT-инфраструктуры. Не забывайте постоянно обновлять вашу политику безопасности в соответствии с современными вызовами.