Когда я впервые узнал, как создавать ssh-ключи, все прочитанные уроки показали, что следует выбрать хорошую фразу-пароль. Но недавно, при настройке процесса-демона, которому требуется ssh, на другую машину, я обнаружил, что единственный способ (кажется) иметь ключ, который мне не нужно авторизовать при каждой загрузке, - это создать ключ с пустым кодовая фраза. Итак, мой вопрос: каковы проблемы с использованием ключа без ключевой фразы?
Ответы:
Ключ без ключевой фразы зависит от того, что никто другой не сможет получить доступ к этому ключу (кто не сможет получить доступ к ресурсам, к которым он все равно дает доступ). Таким образом, если ключ предоставляет доступ к машине, находящейся рядом с ним, и обе машины имеют одинаковый уровень электронной и физической безопасности, то это не имеет большого значения.
С другой стороны, если ваш ключ находится на машине с плохой безопасностью (возможно, у него много ненадежных пользователей, он легко физически доступен или недостаточно актуален с режимом исправления), то вы, вероятно, не я не хочу хранить там ключи без паролей.
В конечном счете, все зависит от уверенности в вашей настройке и взвешивания рисков / затрат на ее выполнение - если вы можете быть уверены, что злоумышленнику не так просто получить доступ к ключу, как к ресурсу, к которому ключ дает доступ. тогда ты в порядке. Если у вас нет такой уверенности, вы, вероятно, должны исправить причины :)
другое решение, повышающее безопасность и облегчающее вашу работу, поэтому вам не нужно постоянно вводить пароль:
если вы хотите зашифровать свой закрытый ключ, вы можете использовать его ssh-agentна своей рабочей станции для «кэширования» незашифрованного ключа. когда вы хотите сохранить расшифрованный ключ, вы запускаете ssh-add ~/.ssh/id_rsaили любой другой ваш закрытый ключ называется. Вам будет предложено ввести пароль, и дешифрованный ключ будет доступен для ваших соединений ssh до тех пор, пока вы не выйдете из системы, не завершите работу ssh-agentили не завершите работу.
вы можете killсохранить сохраненные ключи ssh-agent -kи назначить срок действия ключа, который будет храниться в памяти, ssh-agent -t [seconds]например; если вы не хотите, чтобы ваш ключ был дешифрован вечно, но вы хотите выполнять много сшинга вокруг своих хостов, вы можете установить тайм-аут на 5-10 минут. поэтому вам не нужно постоянно вводить пароль вашего ключа.
опять же, все это связано с тем, насколько вы уверены в безопасности своей / рабочей станции /, которая, если вы единственный, кто имеет к ней доступ, и у вас есть довольно безопасный локальный пароль, и вы не пригласите на себя эксплойты и руткиты, ваш личный секретный ключ без паролей достаточно надежен.
если вы похожи на меня и храните свой закрытый ключ на флэш-накопителе, вы определенно захотите зашифровать его, даже если это просто закрытый ключ (отдельный, из которого я использую свою рабочую станцию, так что если я теряю свой ключ, я могу легко удалить открытый ключ флэш-накопителя из ~/.ssh/authorized_keysсписка моего сервера , что также вызывает / отлично / причину добавить ПОЛЕЗНЫЕ комментарии к вашим открытым ключам)
в своем ответе на предыдущий ответ вы сказали, что только люди, которым вы доверяете, имеют доступ к машине с ключами. Я просто хочу уточнить, что ваш закрытый ключ НЕ должен находиться на сервере, к которому вы подключаетесь, в случае, если вы этим занимаетесь. только ваш открытый ключ должен быть на сервере, и это не проблема, поэтому это «открытый» ключ.
о, я забыл упомянуть; я запускаю ssh-agentпри запуске X, в противном случае зашифрованные ключи, которые я храню ssh-add, не сохраняются в разных xtermсеансах, и мне приходится повторно вводить пароль каждый раз, когда я закрываю xtermзапущенный файл ssh-add. в моем ~/.xinitrcфайле, у меня есть:
if [ -x /usr/bin/ssh-agent ]; then
eval $(/usr/bin/ssh-agent)
fi
у меня есть вызов ssh-agentобернутого, evalпотому что ssh-agent возвращает некоторые переменные окружения, которые должны быть установлены, когда он запускается и запускается ~/.xinitrc, переменные окружения постоянны в течение сеанса X.
ssh-agentи используете ssh -A -i privkey user@hostэто, то разрешите пересылку агента ssh, что позволит вам получить доступ к серверу с исходного сервера, не размещая свой личный ключ на первом сервере. Цепочка ssh не рекомендуется, даже если не включена переадресация ключей ssh, и ssh -Aимеет свои собственные проблемы безопасности. нет причины, по которой ключ на сервере не может быть зашифрован, в то время как ключ на вашей рабочей станции не имеет парольной фразы.
Вы можете взглянуть на аналогичный вопрос, который я задавал о секретных ключах SSL для веб-серверов. В основном, есть три варианта:
Каждый из них несовершенен, поэтому все зависит от того, чего вы боитесь больше всего.
Для автоматического доступа, который, как вы говорите, требует ключей без парольной фразы, я всегда использую дополнительные параметры authorized_keys (см. Sshd (8)), чтобы ограничить команду, которая может быть запущена.
Обычно я предоставляю тщательно написанный сценарий на удаленном конце, который выполняет именно ту работу (или задания - она может смотреть на параметры), которую я хочу разрешить.
Затем я также фиксирую его на IP-адресах, которые могут соединяться с этим ключом (не на 100% надежно, но также и с ограничением команд).
Пока никто, кроме вас, не имеет доступа к ключу, вам не требуется пароль. Фактически, вы не можете использовать фразу-пароль для ключей, используемых автоматизированным программным обеспечением.
Если вы хотите использовать ssh для выполнения каких-либо автоматизированных процедур - я имею в виду, в частности, проверки Nagios - тогда вам, вероятно, не захочется использовать фразу-пароль.
В этой ситуации вы, вероятно, не будете использовать это вне локальной сети, и у вас будет надежно храниться ключ на сервере, выполняющем процедуру.
Большинство учебных пособий, обсуждающих SSH, будут ожидать, что человек войдет в систему из внешней сети, возможно, с незащищенного компьютера, и в этом случае совет будет правильным.
По сути, если вы не знаете, что для этого есть веская причина, создайте парольную фразу. Быть ленивым, чтобы вводить пароль каждый раз, может быть достаточно веской причиной для вас :-)