Является ли центральное расположение для 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

— Гэвин Миллер
источник

По крайней мере, открытые ключи (открытые только для чтения) в Интернете - не самый большой риск ... (Это может позволить злоумышленникам увидеть, могут ли они войти на сервер с закрытым ключом, который они получили в другом месте, но это не не позволяют им войти в систему, просто получив это ...) (Серьезные проблемы заключаются в том, есть ли id_rsaфайл, ~/.sshи им удается это прочитать)

— Герт ван ден Берг

Ответы:

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

Просто настройте 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.

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

— Mahn
источник

+1, но я бы не стал ставить остальных. Установите право собственности на файлы% u для пользователя, чтобы в этом не было необходимости.

— Аарон Копли

Хорошее решение проблемы, когда злоумышленники могут добавлять больше открытых ключей в свои ~ / .ssh / авторизованные_ключи, предоставляя доступ другим.

— bbaassssiiee

Я только что подтвердил, что режим 600 для файла авторизованных ключей пользователя не работает; это должен быть режим 644

— Луис Э.

@bbaassssiiee Это АБСОЛЮТНО НЕ решает эту проблему. Они могут просто поделиться своим закрытым ключом с кем бы они ни хотели предоставить доступ (эта возможность, конечно, может быть уменьшена, но этот ответ делает абсолютно нулевым, чтобы смягчить его)

— DylanYoung

@DylanYoung Я допускаю, что обмен секретными ключами возможен. Но с помощью chattr я могу отозвать доступ на запись к файлам author_keys, чтобы я мог распространять их исключительно, защищая одну строку в каждом файле.

— bbaassssiiee

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

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

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

— voretaq7
источник

+1 за рассуждение Короче говоря, потому что мне потребовалось время, чтобы осознать его значение: директории ~ www-data / .ssh не должно быть вообще, поэтому нет угрозы безопасности для веб-браузера.

— thiton

Спасибо за ответ! Если я вас правильно понимаю. Я не должен иметь ни доступ, rootни www-dataчерез ключ ssh, это правильно?

— Гэвин Миллер

Наличие ~www-data/.sshкаталога - не страшная вещь (с соответствующими разрешениями это не существенный риск), но если вы собираетесь использовать ~www-data/.sshего, вероятно, лучше не иметь своего webroot ~www-data(либо переместите webroot, либо переместите www-dataдомашний каталог). ИМХО - это большая разница между пользователями - я знаю, что, если я увижу jsmithлогин, я знаю, что это Джон Смит. Если я вижу www-dataвход в систему, мне нужно больше копать, чтобы узнать, кто это был.

— voretaq7

Причина, по которой мне понадобился ключ ssh для www-данных, заключается в том, что я использую Beanstalk (инструмент SCM & deploy) для развертывания через SFTP. Должен ли я создать отдельную учетную запись для Beanstalk для выполнения ftp'ing? Каково было бы лучшее решение там?

— Гэвин Миллер

Так оно и есть на большинстве систем AuthorizedKeysFileв /etc/ssh/sshd_configдефолтов в %h/.ssh/authorized_keys. Вот %hзаполнитель для домашнего каталога. Что мешает вам установить его /some/folder/ssh_keys_by_user/%h/или даже /root/ssh_keys/%u. Вы могли бы даже предоставить соответствующему пользователю доступ для записи в его отдельный файл (и только в него), связать файл со стандартным местоположением (с ln -s /root/ssh_keys_by_user/username /home/username/.ssh/authorized_keys) и не нарушать вышеупомянутые предположения.

— con-f-use