Keychain/ru

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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