Альтернативы SSH x509 logon
У меня есть машина с Windows 7, которая не является частью домена, и машина с Linux.
Я хочу войти в Linux из Windows, используя сертификат x509, хранящийся в хранилище сертификатов Windows.
Является ли это возможным?
Цитата Как настроить OpenSSH для использования PKI x509 для аутентификации?
Я не имею в виду просто помещать открытый ключ RSA сертификата x.509 в ~/.ssh/authorized_keys - я ищу способ настроить ssh таким образом, чтобы сертификаты x.509, подписанные предопределенным CA, автоматически предоставляется доступ к связанной учетной записи пользователя. RFC 6187, кажется, предлагает такую функциональность
Я не хочу устанавливать ключи для каждого пользователя, а не просто сертификат CA и сертификат компьютера и сопоставление DN сертификата для размещения имен пользователей для авторизации.
С https://serverfault.com/questions/417518/windows-ca-to-issue-certificate-to-authenticate-ssh-to-a-linux-server?lq=1 кажется, что это возможно только с раздвоенным OpenSSH сервер. После ответа там
Я не склонен отклоняться от основной ветки OpenSSH, безопасность слишком важна, и у меня нет ресурсов, чтобы правильно проверить это существенное изменение
Длина патча - 200 КБ, слишком легко стрелять себе в ногу с помощью такого небезопасного языка, как C, без большого сообщества, которое есть в основной ветке OpenSSH. Более того, кажется, что вместо RFC 6187 реализован более старый проект
Сообщество OpenSSH не заинтересовано в x509, потому что работать с такой большой спецификацией сложно:
Разработчики утверждают, что сложность сертификатов X.509 создает неприемлемую поверхность атаки для sshd. Вместо этого они [недавно] внедрили альтернативный формат сертификата, который намного проще анализировать и, таким образом, представляет меньший риск.
Вышеупомянутый "альтернативный формат сертификата" для меня тоже не очень хорошая идея. X.509 широко поддерживается, поэтому 2 сертификата и 1 закрытый ключ могут использоваться во многих различных местах, например, в TLS, IPSec, S/MIME и других приложениях CMS. Более того, централизованный отзыв, аналогичный CRL, не поддерживается, поэтому отзыв "альтернативных сертификатов" с скомпрометированными закрытыми ключами утомителен и подвержен ошибкам.
Пока что единственно приемлемым вариантом является GSSAPI - он даже поддерживается PuTTY.
Есть ли что-нибудь еще, чтобы упростить управление ключами SSH?
2 ответа
Существует ряд патчей для добавления поддержки сертификатов X.509 в OpenSSH, поддерживаемый Руменом Петровым. Это позволяет вам использовать клиентские сертификаты X.509 для аутентификации соединений SSH.
Например, вы можете что-то подобное в ~/.ssh/authorized_keys:
# X.509 by DN
x509v3-sign-rsa DN /C=US/O=Example org/OU=Administrators/CN=David Coles
Недостатком является то, что вам также понадобится такой же исправленный клиент OpenSSH для подключения к этим серверам или сторонний клиент SSH, который поддерживает сертификаты X.509 (например, SecureCRT). Кроме того, очень немногие дистрибутивы Linux содержат эти исправления, поэтому вам, вероятно, придется применить исправления и собрать сервер OpenSSH самостоятельно.
Немного другой подход, который не требует модификации клиента, состоит в том, чтобы использовать обычную аутентификацию с открытым ключом, но использовать OpenSSH AuthorizedKeysCommand опция конфигурации для поиска ключа SSH в централизованной базе данных (например, из атрибута LDAP для этого пользователя).
Я считаю, что GSSAPI с запасным паролем является хорошим вариантом.
Вышеупомянутый "альтернативный формат сертификата" для меня тоже не очень хорошая идея. X.509 широко поддерживается, поэтому 2 сертификата и 1 закрытый ключ могут использоваться во многих различных местах, например, в TLS, IPSec, S/MIME и других приложениях CMS. Более того, централизованный отзыв, аналогичный CRL, не поддерживается, поэтому отзыв "альтернативных сертификатов" с скомпрометированными закрытыми ключами утомителен и подвержен ошибкам.
Да, это очень плохая идея - повторно использовать один закрытый ключ в двух разных сертификатах. На самом деле, это плохая идея использовать один закрытый ключ для разных целей / протоколов. Несмотря на то, что технически возможно использовать один сертификат x509v3 для TLS, IPSec, S/MIME и т. Д. В то же время, это криптографическая практика, называемая повторным использованием ключа.