Когда я впервые узнал, как создавать ключи ssh, все учебники, которые я прочитал, указали, что следует выбрать хорошую парольную фразу. Но недавно, при настройке процесса демона, которому требуется ssh на другой компьютер, я обнаружил, что единственный способ (кажется) иметь ключ, который мне не нужно аутентифицировать при каждой загрузке, - это создать ключ с пустым кодовая фраза. Итак, мой вопрос: какие проблемы возникают при использовании ключа без ключевой фразы?
Ключ без парольной фразы зависит от того, что никто другой не сможет получить этот ключ (кто в любом случае не сможет получить доступ к ресурсам, к которым он дает доступ). Итак, если ключ предоставляет доступ к машине рядом с ним, и обе машины имеют одинаковый уровень электронной и физической безопасности, то в этом нет ничего страшного.
С другой стороны, если ваш ключ находится на машине с плохой безопасностью (возможно, у него много ненадежных пользователей, он легко физически доступен или не обновляется в режиме исправления), то вы, вероятно, не используете я не хочу хранить там ключи без парольной фразы.
В конечном итоге все сводится к уверенности в вашей настройке и взвешиванию рисков / затрат, связанных с ее выполнением - если вы можете быть достаточно уверены, что злоумышленнику нереально проще получить доступ к ключу, чем к ресурсу, к которому ключ дает вам доступ , тогда ты в порядке. Если у вас нет такой уверенности, возможно, вам стоит исправить причины, почему :)
еще одно решение, повышающее безопасность и одновременно упрощающее вашу жизнь, так что вам не нужно постоянно вводить пароль:
если вы хотите зашифровать свой закрытый ключ, вы можете использовать ssh-agent на вашей рабочей станции, чтобы «кэшировать» незашифрованный ключ. когда вы хотите сохранить свой расшифрованный ключ, вы запускаете ssh-add ~/.ssh/id_rsa или как там называется ваш закрытый ключ. вам будет предложено ввести пароль, и расшифрованный ключ будет доступен для ваших ssh-соединений, пока вы не выйдете из системы, kill ssh-agent или выключение.
ты можешь kill сохраненные ключи с ssh-agent -k и вы можете назначить время жизни ключа, чтобы он был в памяти с помощью ssh-agent -t [seconds] так например; если вы не хотите, чтобы ваш ключ был расшифрован вечно, но вы хотите много использовать ssh для своих хостов, вы можете установить тайм-аут на 5-10 минут. поэтому вам не нужно постоянно вводить пароль для вашего ключа.
опять же, все это связано с тем, насколько вы уверены в безопасности своей / рабочей станции /, что, если вы единственный, кто имеет к ней доступ, и у вас есть довольно надежный локальный пароль, а у вас нет приглашайте на себя эксплойты и руткиты, ваш закрытый ключ без парольной фразы достаточно безопасен.
если вы похожи на меня и храните свой закрытый ключ на флэш-накопителе, вы определенно захотите его зашифровать, даже если это всего лишь закрытый ключ (отдельный ключ, который я использую на своей рабочей станции, поэтому, если я потерял свой ключ, я легко могу просто удалить открытый ключ флэш-накопителя с моего сервера ~/.ssh/authorized_keyslist, который также вызывает / отличную / причину для добавления ПОЛЕЗНЫХ комментариев к вашим открытым ключам)
в вашем ответе на предыдущий ответ вы сказали, что только люди, которым вы доверяете, имеют доступ к машине с ключами. Я просто хочу уточнить, что ваш закрытый ключ НЕ должен находиться на сервере, к которому вы подключаетесь, если это то, что вы делаете. на сервере должен быть только ваш открытый ключ, и это не проблема, поэтому это «открытый» ключ.
о, я забыл упомянуть; я запускаю 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.
Вы можете посмотреть на аналогичный вопрос Я спросил о секретных ключах SSL для веб-серверов. В основном есть три варианта:
У каждого из них есть недостатки, поэтому все зависит от того, чего вы больше всего боитесь.
Для автоматического доступа, который, как вы говорите, требует ключей без парольной фразы, я всегда использую дополнительные параметры authorized_keys (см. Sshd (8)), чтобы ограничить команду, которую можно запустить.
Обычно я предоставляю на удаленном конце тщательно написанный сценарий, который выполняет именно ту работу (или задания - он может просматривать параметры), которые я хочу разрешить.
Затем я также привязываю его к IP-адресам, которые могут подключаться с помощью этого ключа (не на 100% надежный, но и с ограничением команд).
Пока никто, кроме вас, не имеет доступа к ключу, вам не требуется кодовая фраза. Фактически, вы не можете использовать парольную фразу для ключей, используемых автоматизированным программным обеспечением.
Если вы хотите использовать ssh для выполнения какой-либо автоматизированной процедуры - я имею в виду конкретно проверки Nagios - тогда вы, вероятно, не захотите использовать парольную фразу.
В этой ситуации вы, вероятно, не будете использовать это вне локальной сети, и у вас будет надежно храниться ключ на сервере, выполняющем процедуру.
В большинстве руководств, в которых обсуждается SSH, предполагается, что человек войдет в систему из внешней сети, возможно, с незащищенного компьютера, и в этом случае совет здравый.
В принципе, если вы не знаете, что есть веская причина не делать этого, создайте кодовую фразу. Слишком ленивый ввод пароля каждый раз может быть для вас достаточно веской причиной :-)