SSH: Безопасно ли для клиента размещать закрытый ключ RSA?

Безопасно ли создавать пару открытого / закрытого ключа на сервере, добавить открытый ключ в список авторизованных ключей, а затем скопировать закрытый ключ каждому клиенту, как описано здесь ( http://www.rebol.com/docs/ ssh-auto-login.html ) Предполагается, что вы поддерживаете постоянный контроль над каждым клиентом? (т.е. один и тот же пользователь, много компьютеров).

Типичная процедура состоит в том, чтобы сгенерировать пару открытый / закрытый ключ на клиенте, а затем добавить открытый ключ клиента в список авторизованных ключей на сервере, как описано здесь ( http://www.linuxproblem.org/art_9.html ). С помощью этого метода, если у вас есть несколько клиентских компьютеров, каждый из них должен быть присоединен к списку авторизованных ключей и поддерживаться с течением времени.

Поздравляем, вы нашли интернет-учебник с плохим советом.

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

Что касается этого урока, то это удивительно плохой совет - генерировать пару ключей на сервере и копировать закрытый ключ клиенту . Это полностью отсталый. Вместо этого пара ключей должна быть сгенерирована на клиенте, а открытый ключ скопирован на сервер. Есть даже вспомогательный сценарий, ssh-copy-idкоторый делает именно это, и в процессе этого проверяет, все ли разрешения правильны, клиент получает ключ хоста сервера и т. Д.

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

Самая большая проблема с протоколом, описанным в этом руководстве, заключается в том, что он не определяет, каким образом вы «загружаете закрытый ключ на клиентский компьютер» безопасным способом (т. Е. Он предотвращает прослушивание). Если у вас еще нет безопасного канала, ключ, вероятно, будет передан в открытом виде через Интернет (HTTP, FTP, электронная почта и т. Д.). Вы можете использовать HTTPS, но если у вас нет реального сертификата, это может быть MITM, чтобы понюхать ключ. Просто сделай это так, как ты должен; сгенерируйте пару ключей на клиентском компьютере, передайте открытый ключ на сервер и не забудьте проверить контрольную сумму файла, чтобы убедиться, что он не был изменен при передаче.