Keychain

В этом документе описано использование общих ключей SSH вместе с программой keychain. Предполагается базовое знание криптографии с открытым ключом.

Основы

Рассматриваемая проблема

Необходимость вводить логин и пароль для каждого в каждой системе неудобна, особенно если под управлением находится множество систем. У некоторых администраторов, возможно, даже имеется скрипт или cron-задача, которые упрощают использование ssh соединения. Так или иначе, у этой проблемы есть решение, и оно начинается с аутентификации с открытым ключом.

Как работает аутентификация с открытым ключом?

Предположим, что клиент хочет соединиться с демоном ssh на сервере. Клиент сначала генерирует пару ключей и пересылает открытый ключ на сервер. Затем, каждый раз, когда клиент попытается подключиться к серверу, тот отправит запрос зашифрованный этим открытым ключом. Только обладатель соответствующего закрытого ключа (то есть клиент) способен его расшифровать, так что правильный ответ приведёт к успешной аутентификации.

Как использовать аутентификацию с открытым ключом

Генерация ключевой пары

Сперва необходимо создать ключевую пару. Для этого воспользуйтесь командой ssh-keygen:

user $ssh-keygen

Оставьте все значения по умолчанию и удостоверьтесь, что ввели надежную ключевую фразу.

Предупреждение
Убедитесь, что выбрали надежную ключевую фразу, особенно если этот ключ используется для входа в качестве пользователя root!

После завершения генерации закрытый ключ будет находиться в ~/.ssh/id_rsa, а открытый ключ — в ~/.ssh/id_rsa.pub. Открытый ключ готов для копирования на удаленный хост.

Подготовка сервера

Файл ~/.ssh/id_rsa.pub необходимо скопировать на сервер, на котором запущен sshd. Он должен быть добавлен в файл ~/.ssh/authorized_keys, который принадлежит соединяющемуся пользователю на удаленном сервере. После предоставления персоналом инфраструктуры ssh доступа к серверу, следующие шаги могут быть использованы для настройки автоматического входа с использованием открытого ключа на удаленный сервер:

user $ssh-copy-id server_user@server -i ~/.ssh/id_rsa.pub

ssh-copy-id это скрипт-обвертка для этих шагов. Если он недоступен, то можно воспользоваться следующими командами:

user $scp ~/.ssh/id_rsa.pub server_user@server:~/myhost.pub

user $ssh server_user@server "cat ~/myhost.pub >> ~/.ssh/authorized_keys"

user $ssh server_user@server "cat ~/.ssh/authorized_keys"

Вывод команды из последней строки должен отобразить содержимое файла ~/.ssh/authorized_keys. Убедитесь, что этот вывод выглядит корректно.

Тестирование настройки

В теории, если всё прошло успешно, а ssh-демон на сервере это позволяет (как это может быть настроено), подключение по ssh к серверу без ввода пароля должно быть уже возможно. Закрытый ключ клиента всё равно будет необходимо дешифровать ключевой фразой, указанной ранее, однако не следует её путать с паролем учетной записи пользователя на сервере.

user $ssh <server_user>@<server>

Будет запрошена ключевая фраза для id_rsa, после чего будет предоставлен доступ к серверу по ssh для пользователя <server_user>. Если этого не произошло, подключитесь под пользователем <server_user> и проверьте, что в ~/.ssh/authorized_keys каждая запись (открытый ключ) находится на отдельной строке. Также неплохо будет проверить конфигурацию sshd и убедиться, что он позволяет использование авторизации с открытым ключом, если тот доступен.

К этому моменту читатель, возможно, подумает: «А в чём смысл, я же просто заменил один пароль на другой?!» Не переживайте, в следующем разделе мы покажем, как можно вводить ключевую фразу всего один раз, а затем повторно использовать (расшифрованный) ключ для многократных подключений.

Как сделать аутентификацию с открытым ключом удобной

Обычное управление ключами с помощью ssh-agent

Далее необходимо расшифровать закрытый ключ(и) один раз и получить возможность свободно соединяться по ssh, без каких-либо паролей. Именно для этого и предназначена программа ssh-agent.

ssh-agent обычно запускается вначале X-сессии или из скрипта, который стартует при запуске оболочки (например, ~/.bash_profile). Она работает путем создания Unix-сокета и регистрации подходящих переменных среды, чтобы все последующие приложения могли воспользоваться её услугами, подсоединяясь к этому сокету. Очевидно, имеет смысл запускать её в родительском процессе X-сессии, чтобы набор расшифрованных закрытых ключей стал доступным для всех последующих X-приложений.

user $eval `ssh-agent`

Заметка
Этот экземпляр ssh-agent будет хранить ключи расшифрованными до тех пор, пока он работает. Чтобы установить время существования ключей, используйте параметр -t, как описано в man ssh-agent.

При запуске ssh-agent должен сообщить PID запущенного экземпляра, а также установить несколько переменных среды, а именно SSH_AUTH_SOCK и SSH_AGENT_PID. Он также должен автоматически добавить ~/.ssh/id_rsa к своему набору и запросить у пользователя соответствующую ключевую фразу. Если есть другие закрытые ключи, которые необходимо добавить к запущенному ssh-agent, воспользуйтесь командой ssh-add:

user $ssh-add somekeyfile

А теперь начинается магия. С готовым расшифрованным закрытым ключом можно получить ssh-доступ к серверу (у которого настроен открытый ключ) без ввода какого-либо пароля:

user $ssh server

Следующая команда останавливает ssh-agent (после чего при подключении понадобится вводить ключевую фразу):

user $ssh-agent -k

Заметка
Возможно, в системе ещё осталось несколько запущенных процессов ssh-agent (особенно, если всё делалось впервые). Эти процессы, как и другие, можно завершить командой killall ssh-agent.

Чтобы с ssh-agent было еще более удобней работать, продолжайте читать следующую главу, которая описывает использование keychain. Убедитесь, что завершили запущенный ssh-agent, так как keychain обрабатывает сессии ssh-agent самостоятельно.

Выжимание последней капли удобства из ssh-agent

Keychain позволит использовать ssh-agent заново между входами в систему, а также запрашивать ключевую фразу при каждом входе пользователя в систему. Давайте сначала установим его:

root #emerge --ask net-misc/keychain

После успешной установки keychain готов к использованию. Добавьте следующие строки в файл ~/.bash_profile для того, чтобы включить его:

Код Включение keychain в .bash_profile

keychain ~/.ssh/id_rsa
. ~/.keychain/$HOSTNAME-sh
. ~/.keychain/$HOSTNAME-sh-gpg

Заметка
По желанию можно добавить ещё несколько закрытых ключей. Если необходимо, чтобы ключевая фраза запрашивалась каждый раз при запуске командной оболочки, добавьте параметр --clear.

Заметка
Если bash не используется, обратитесь к разделу EXAMPLES из man keychain, чтобы посмотреть примеры использования в других оболочках. Основной идеей является запуск этих команд каждый раз, когда используется оболочка.

Теперь протестируем это. Сперва убедитесь, что ssh-agent из предыдущего раздела завершён, а затем откройте новую оболочку — обычный вход в систему или открытие нового терминала. Должен появиться запрос пароля на каждый ключ, указанный в командной строке. Все открытые после этого оболочки будут повторно использовать ssh-agent, что позволит создавать ssh-подключения без ввода пароля снова и снова.

Использование keychain с Plasma 5

Пользователи Plasma 5 вместо использования ~/.bash_profile могут позволить Plasma управлять программой ssh-agent. Для этого необходимо отредактировать файлы /etc/plasma/startup/agent-startup.sh (который читается при запуске Plasma) и /etc/plasma/shutdown/10-agent-shutdown.sh (который читается при остановке). Ниже показано, как они могут выглядеть:

Код Редактирование /etc/plasma/startup/10-agent-startup.sh

SSH_AGENT=true

Код Редактирование /etc/plasma/shutdown/10-agent-shutdown.sh

if [ -n "${SSH_AGENT_PID}" ]; then
  eval "$(ssh-agent -k)"
fi

Теперь всё, что необходимо сделать, — это запустить любимый эмулятор терминала, например kde-apps/konsole, и загрузить нужную связку ключей для использования. Например:

user $keychain ~/.ssh/id_rsa

Ключи будут запомнены до окончания сеанса Plasma (или пока процесс ssh-agent не будет завершён вручную).

Использование keychain с Plasma 4

Единственным отличием от Plasma 5 является другое расположение файлов: вместо /etc/plasma следует использовать /etc/kde.

Завершающие примечания

Соображения безопасности

Конечно же, использование ssh-agent может немного ухудшить безопасность системы. Если другой пользователь сможет получить доступ к запущенной командной оболочке, он сможет подключиться ко всем серверам без использования пароля. В итоге это является угрозой для серверов, поэтому пользователям следует свериться с местной политикой безопасности. Удостоверьтесь, что приняли все необходимые меры для того, чтобы обеспечить достаточную безопасность для всех сессий.

Устранение проблем

Большинство из описанного должно работать без особых проблем, но если все-таки столкнулись с проблемами, то следующие пункты могут помочь их решить.

• Если подключение без ssh-agent не работает, попробуйте добавить к команде ssh параметр -vvv, чтобы выяснить, что происходит. Иногда бывает, сервер не настроен на использование аутентификации с открытым ключом, иногда он может запрашивать локальный пароль в любом случае! В таком случае попробуйте запустить ssh с параметром -o или измените конфигурационный файл sshd_config на сервере.
• Если подключение с ssh-agent или keychain не работает, то причина может быть в том, что используемая командная оболочка не понимает используемые команды. Сверьтесь с man-страницами программ ssh-agent и keychain для поиска подробностей по работе с другими оболочками.

Внешние ресурсы

• Официальная страница проекта Keychain на Funtoo.org
• Серия статей IBM developerWorks описывающая концепции, стоящие за Keychain.

---

This page is based on a document formerly found on our main website gentoo.org.
The following people contributed to the original document: Eric Brown, Marcelo Goes, nightmorph
They are listed here because wiki history does not allow for any external attribution. If you edit the wiki article, please do not add yourself here; your contributions are recorded on each article's associated history page.