Мы передаем файлы на удаленный сервер в нашем приложении, и требуемый метод аутентификации - использовать SSH-ключи.
Итак, я создал свою пару ключей с помощью ssh-keygen и отправил свой открытый ключ для вставки в файл authorized_keys удаленного хоста. Однако ИТ-безопасность отклонила это предложение, заявив, что они сгенерируют для меня пару ключей и отправят мне закрытый ключ. Причина: «Нам нужны SSH-ключи, которые должны быть подписаны командой ИТ-безопасности. Это необходимо для того, чтобы мы могли лидировать в отслеживании и подотчетности».
Очевидно, у меня с этим проблемы. То, что закрытый ключ сгенерирован кем-то другим, означает, что этот человек может маскироваться под меня без моего ведома. Я пытаюсь найти способы опровергнуть этот аргумент.
Насколько я могу Google, похоже, не существует известного способа подписать ключи, чтобы он помогал отслеживать человека, который вошел в систему. Тот факт, что я отправил свой открытый ключ, означает, что он принадлежит мне, и любой, кто входит на удаленный сервер с этим ключом, по умолчанию идентифицируется как я. Как подпись поможет? И как бы они вообще подписали?
Кто-нибудь, пожалуйста, подскажите, если я ошибаюсь, спасибо!
Хорошо, теперь, когда мы определили, что нет возможности подписать ключи SSH, мне нужно показать ИТ-безопасности, как они могут действительно отслеживать, кто вошел в систему (я думаю, это должно быть конструктивно, если не начнется самоуправство ). На моем собственном сервере я установил для sshd LogLevel значение DEBUG. Итак, теперь, когда я вхожу в систему, я вижу следующий фрагмент:
Found matching DSA key: xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
Похоже, это хеш-значение. Как мне связать это с тем, какой открытый ключ в файле authorized_keys был использован? Я знаю, что есть еще одна строчка:
debug1: matching key found: file /home/bofh/.ssh/authorized_keys2, line 1
но это не так полезно, поскольку номера строк можно легко изменить, если бы я вставил ключ в верхнюю часть файла, нажав исходные клавиши вниз.
Спасибо!
С тех пор, как вы задали свой вопрос, Вселенная изменилась.
Openssh5.4 добавил поддержку именно тех сертификатов, которые вам нужны. См. Примечания к выпуску на http://www.openssh.org/txt/release-5.4 (и страницы руководства) для получения дополнительной информации, или, если вы действительно хотите быть безумным, посмотрите PROTOCOL.certkeys для кровавых подробностей
Мое первое впечатление при чтении вашего вопроса состоит в том, что ИТ-специалист перепутал SSH и SSL (он должен быть подписан нами), а также не понимает, как на самом деле работает подписывание SSL.
В любом случае нет способа подписать ключ SSH (о котором я знаю).
Что-то не так в этой просьбе.
Если он доставляет подписанные файлы на сервер,
Я ожидал, что это будет сделано как минимум.
my-key-privatemy-key-pub расшифровать файлЕсть и другие способы делать такие вещи,
Однако получение пары ключей, созданной кем-то другим, бесполезно в качестве схемы аутентификации..
Это означает, что вы доверяете им так же, как доверяете себе.
Это первые вопросы, которые вы можете задать своему ИТ-отделу.
Если подотчетность - это проблема для ИТ,
Нет причин, по которым вы не могли бы использовать сертификаты X.509 для аутентификации SSH вместо голых ключей - на самом деле, я бы предпочел, чтобы OpenSSH работал таким образом! Но стандартная версия OpenSSH этого не делает, и в наши дни это доминирующая реализация.
Я видел несколько пропатченных версий OpenSSH, которые существуют, и коммерческая реализация SSH.com, похоже, также поддерживает аутентификацию X.509. Итак, если ваша организация использует один из них, требование подписи ключей центральным органом имеет смысл.
Тем не менее, нет оправдания требованию создания закрытого ключа сторонней организацией! Если они идут по маршруту X.509, они должны попросить вас сгенерировать пару ключей и запрос на подпись сертификата, как и с любым другим сертификатом X.509, используемым для SSL и т. Д.