Аутентификация открытого ключа SSH — всегда требует, чтобы пользователи генерировали свою собственную пару ключей?

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

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

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

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

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

Я вполне уверен, это - БАКАЛАВР НАУК. Частный должен быть сгенерирован случайным образом. Таким образом, пока нет никакой предвзятости в этой случайности между различными закрытыми ключами не может быть соединения.

Случайное семя обычно прибывает из/dev/random. Если Вы в некотором роде не изменили ssh-keygen для использования другого случайного семени (Вы знали бы, сделали ли Вы), очень маловероятно, что любой смог бы наткнуться на тот ключ, чтобы выяснить, как генерировать новый ключ для взламывания системы.