Это типичный пример компромисса между безопасностью и удобством. К счастью, есть несколько вариантов. Наиболее подходящее решение зависит от сценария использования и желаемого уровня безопасности.
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скрипта, содержащего фразу-пароль, установлены соответствующие разрешения, что делает его читаемым, доступным для записи и запуска только владельцем ключа.