Keychain/ru

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

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

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

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

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

После завершения генерации закрытый ключ должен быть в и открытый ключ в. Открытый ключ теперь готов для копирования на удаленный хост.

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

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

Тестирование настройки
Theoretically, if all went well, and the daemon on the server allows it (as this can be configured),  access without entering a password should now be possible on the server. The private key on the client will still need to be decrypted with the passphrase used previously, but this should not be confused with the password of the user account on the server.

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

В этом месте, читающий возможно подумает: "Какая разница, я просто заменил один пароль на другой?!" Успокойтесь, в следующем разделе будет продемонстрировано, как мы можем использовать это, чтобы вводить фразу-пароль только один раз и повторно использовать (расшифрованный) ключ для многократного входа.

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

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

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

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

Для того, чтобы выключить SSH-агент (после чего снова потребуется вводить фразу-пароль позже):

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

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

Если предположить, что установка прошла успешно, то уже можно использовать. Добавьте следующее в файл, для того, чтобы включить его:

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

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

Теперь, все, что необходимо сделать, это запустить эмулятор терминала по вкусу, например Konsole, и загрузить нужную связку ключей для использования. Например:

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

Использование keychain с Plasma 5
As above for KDE 4 except replace with.

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

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


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

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

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