Является ли центральное расположение для authorized_keys хорошей идеей?

Я нахожусь в процессе настройки облачного сервера для запуска следующего стека: Ruby, Passenger, Apache; под Ubuntu 10.04 (Lucid Lynx).

В процессе, чтобы упростить управление сервером, я установил ключи RSA rootи www-dataвключил их sshна сервере. То , что я не сделал , как было то , что www-data«s .sshкаталог сидел в /var/wwwкотором настроен каталог по умолчанию для Apache. Меня беспокоит то, что если Apache не настроен должным образом, .sshкаталог может быть открыт.

Я наткнулся на решение , чтобы переместить ~/.ssh/authorized_keysфайл в центре города, изменяя AuthorizedKeysFileв /etc/ssh/sshd_config. Это имеет 2 плюса: одно место для ключей, и вам не нужно беспокоиться о плохой конфигурации Apache. Единственный минус, о котором я могу подумать, заключается в том, что теперь каждый пользователь доступен для входа на сервер (очевидно, обоюдоострый меч файла центрального ключа).

Есть ли что-то, что я пропустил в этой конфигурации? Я переделал себя, или это лучшее решение, чем отдельные authorized_keysфайлы?

Я зеленый, когда дело доходит до управления сервером, но я полностью готов называться дурными именами за плохие поступки. : D

Все файлы ключей могут быть централизованы в одном каталоге и не смешиваться в одном и том же файле.

Просто настройте sshd_configфайл так:

AuthorizedKeysFile  /etc/ssh/authorized_keys/%u

На вашем сервере:

• Ключи www-данных будут в /etc/ssh/authorized_keys/www-data
• корневые ключи будут в /etc/ssh/authorized_keys/root

Что касается прав доступа, эти настройки принимаются sshd:

/etc/ssh/authorized_keysпринадлежит root:rootи имеет режим 755. Файлы ключей принадлежат root:rootи имеют режим 644.

Другие режимы могут работать, но я их не проверял.

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

В плане безопасности я также думаю, что это ужасная идея, чтобы все делили учетную запись службы: сейчас это только вы, и вы знаете, что именно вы вносите изменения. Через 5 лет, когда у вас будет 5 администраторов, вы захотите узнать, кто что изменил, и покопаться в журналах аудита, чтобы узнать, кто и какой ключ использовал, когда это королевская боль.
Вам лучше, если люди войдут в систему под своим именем и используют sudoчто-то подобное, чтобы повысить свои привилегии и делать все, что им нужно.

Если вы все еще хотите централизовать ключи SSH, я предлагаю обратиться к системе развертывания, такой как Puppet или Radmind, чтобы управлять / распространять authorized_keysфайлы в соответствующие ~user/.ssh/каталоги (или взломать собственное решение, которое использует их на месте).
При расширении до нескольких серверов вам может потребоваться поискать патч открытого ключа LDAP для более старых версий OpenSSH (или AuthorizedKeysCommandдирективы и соответствующего сценария в более новой версии OpenSSH), чтобы вы могли централизовать своих пользователей и не нуждаться в распространении их ключи по всей вашей сети, но это, вероятно, будет довольно далеко для вас.