Безопасно ли сгенерировать пару открытого / закрытого ключей на сервере, добавить открытый ключ в список authorized_keys, а затем скопировать закрытый ключ каждому клиенту, как описано здесь (http://www.rebol.com/docs/ssh-auto-login.html) Если вы сохраняете постоянный контроль над каждым клиентом? (т.е. один и тот же пользователь, много компьютеров).
Типичная процедура состоит в том, чтобы сгенерировать пару открытого / закрытого ключей на клиенте, а затем добавить открытый ключ клиента в список authorized_keys на сервере, как описано здесь (http://www.linuxproblem.org/art_9.html). При использовании этого метода, если у вас несколько клиентских компьютеров, каждый из них должен быть объединен в список authorized_keys и поддерживаться с течением времени.
Поздравляем, вы нашли в Интернете учебник с плохими советами.
Проблема с использованием одной пары ключей для нескольких компьютеров возникает, когда кто угодно компьютеров скомпрометирован. Тогда у вас нет выбора, кроме как отозвать пару ключей где угодно и переназначить каждый компьютер, который использовал эту пару ключей. Вы всегда должны использовать уникальные пары ключей для каждой машины и пользователя, чтобы ограничить ущерб, который может нанести взломанный ключ.
Что касается этого руководства, то создание пары ключей на сервер и скопируйте закрытый ключ в клиент. Это совсем наоборот. Вместо этого пара ключей должна быть создана на клиент и открытый ключ скопирован на сервер. Есть даже вспомогательный скрипт ssh-copy-id который делает именно это, и попутно проверяет правильность всех разрешений, клиент получает ключ хоста сервера и т. д.
Действительно могут быть ситуации, когда вы хотите централизованно управлять ключами идентификации пользователей, например для автоматизированных сценариев, но в этом случае вам действительно следует делать это с третьего хоста или, в идеале, из системы управления конфигурацией, такой как марионетка.
Самая большая проблема с протоколом, описанным в этом руководстве, заключается в том, что он не указывает, как вы «загружаете закрытый ключ на клиентский компьютер» безопасным способом (то есть предотвращающим перехват). Если у вас еще нет безопасного канала, вероятно, ключ будет передан в открытом виде через Интернет (HTTP, FTP, электронная почта и т. Д.). Вы можете использовать HTTPS, но если у вас нет настоящего сертификата, его можно использовать MITM, чтобы обнюхать ключ. Просто делай это так, как тебе положено; сгенерируйте пару ключей на клиентском компьютере, передайте открытый ключ на сервер и не забудьте проверить контрольную сумму файла, чтобы убедиться, что он не был изменен при передаче.