Это типичный пример компромисса между безопасностью и удобством. К счастью, есть несколько вариантов. Наиболее подходящее решение зависит от сценария использования и желаемого уровня безопасности.
ssh-ключ с парольной фразой, нет ssh-agent
Теперь пароль необходимо вводить каждый раз, когда ключ используется для аутентификации. Хотя это лучший вариант с точки зрения безопасности, он предлагает худшее удобство использования. Это также может привести к тому, что слабый пароль будет выбран для того, чтобы уменьшить нагрузку на его повторный ввод.
SSH-ключ с парольной фразой, с ssh-agent
Добавление следующего к ~/.bash_profile
автоматически запустит ssh-agent
и загрузит ssh-ключ (ы) при входе в систему:
if [ -z "$SSH_AUTH_SOCK" ] ; then
eval `ssh-agent -s`
ssh-add
fi
Теперь пароль должен вводиться при каждом входе в систему. Хотя это немного лучше с точки зрения удобства использования, у него есть недостаток, который ssh-agent
запрашивает парольную фразу независимо от того, должен ли ключ использоваться или нет во время сеанса входа в систему. Каждый новый логин также порождает отдельный ssh-agent
экземпляр, который продолжает работать с добавленными ключами в памяти даже после выхода из системы, если он явно не уничтожен.
Чтобы убить ssh_agent
при выходе из системы, добавьте следующее в~/.bash_logout
if [ -n "$SSH_AUTH_SOCK" ] ; then
eval `/usr/bin/ssh-agent -k`
fi
или следующее ~/.bash_profile
trap 'test -n "$SSH_AUTH_SOCK" && eval `/usr/bin/ssh-agent -k`' 0
Создание нескольких ssh-agent
экземпляров можно избежать, создав постоянный сокет связи с агентом в фиксированном месте в файловой системе, например, в ответе Коллина Андерсона . Это улучшение по сравнению с порождением нескольких экземпляров агентов, за исключением случаев, когда явно дешифрованный ключ остается в памяти после выхода из системы.
На настольных компьютерах ssh-агенты, включенные в среду рабочего стола, такие как агент SSH Gnome Keyring , могут быть лучшим подходом, поскольку их обычно можно использовать для запроса парольной фразы при первом использовании ssh-ключа во время сеанса входа и сохранить расшифрованный закрытый ключ в памяти до конца сеанса.
SSH-ключ с парольной фразой, с ssh-ident
ssh-ident
это утилита, которая может управлять ssh-agent
от вашего имени и при необходимости загружать идентификационные данные. Он добавляет ключи только один раз, когда они необходимы, независимо от того, сколько терминалов, ssh или сеансов входа в систему требуют доступа к ssh-agent
. Он также может добавлять и использовать другой агент и другой набор ключей в зависимости от хоста, к которому подключен, или от каталога ssh, из которого вызывается. Это позволяет изолировать ключи при использовании переадресации агента с разных хостов. Это также позволяет использовать несколько учетных записей на таких сайтах, как GitHub.
Чтобы включить ssh-ident
, установите его и добавьте следующий псевдоним ~/bash_profile
:
alias ssh='/path/to/ssh-ident'
SSH-ключ с парольной фразой, с keychain
keychain
это небольшая утилита, которая работает ssh-agent
от вашего имени и позволяет ssh-agent
продолжать работу после завершения сеанса входа в систему. При последующих входах в систему keychain
будет подключаться к существующему ssh-agent
экземпляру. На практике это означает, что парольную фразу необходимо вводить только во время первого входа в систему после перезагрузки. При последующих входах в систему используется незашифрованный ключ из существующего ssh-agent
экземпляра. Это также может быть полезно для разрешения аутентификации RSA / DSA cron
без пароля в заданиях без ssh-ключей без пароля.
Чтобы включить keychain
, установите его и добавьте что-то вроде следующего ~/.bash_profile
:
eval `keychain --agents ssh --eval id_rsa`
С точки зрения безопасности, ssh-ident
и keychain
хуже , чем ssh-agent
случаях ограничивается временем жизни конкретной сессии, но они предлагают высокий уровень удобства. Чтобы повысить безопасность keychain
, некоторые люди добавляют --clear
опцию в свой ~/.bash_profile
вызов цепочки для ключей. При этом необходимо повторно вводить парольные фразы при входе в систему, как указано выше, но cron
задания по-прежнему будут иметь доступ к незашифрованным ключам после выхода пользователя из системы. На keychain
вики-странице есть больше информации и примеров.
SSH-ключ без ключевой фразы
С точки зрения безопасности это наихудший вариант, поскольку закрытый ключ полностью незащищен в случае его раскрытия. Это, однако, единственный способ убедиться, что пароль не нужно вводить повторно после перезагрузки.
SSH-ключ с ключевой фразой, с ssh-agent
, передавая парольную фразу ssh-add
из сценария
Хотя может показаться простой идеей передать парольную фразу ssh-add
из сценария, например echo "passphrase\n" | ssh-add
, это не так просто, как кажется ssh-add
, не считывает парольную фразу из stdin
, но открывает ее /dev/tty
непосредственно для чтения .
Это можно обойти с expect
помощью инструмента для автоматизации интерактивных приложений. Ниже приведен пример скрипта, который добавляет ssh-ключ, используя фразу-пароль, хранящуюся в скрипте:
#!/usr/bin/expect -f
spawn ssh-add /home/user/.ssh/id_rsa
expect "Enter passphrase for /home/user/.ssh/id_rsa:"
send "passphrase\n";
expect "Identity added: /home/user/.ssh/id_rsa (/home/user/.ssh/id_rsa)"
interact
Обратите внимание, что поскольку фраза-пароль хранится в текстовом виде в сценарии, с точки зрения безопасности это вряд ли лучше, чем использование ssh-ключа без пароля. Если необходимо использовать этот подход, важно убедиться, что для expect
скрипта, содержащего фразу-пароль, установлены соответствующие разрешения, что делает его читаемым, доступным для записи и запуска только владельцем ключа.