Keychain/ru

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

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

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

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

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

Теперь у Вас должен быть закрытый ключ в и открытый ключ в. Мы готовы скопировать открытый ключ на удаленный компьютер.

Подготовка сервера
Мы скопируем файл на сервер, на котором запущен sshd. Мы также добавим его в файл, который принадлежит соединяющемуся пользователю на этом сервере. Здесь приведен пример того, как это сделать если Вы уже обладаете доступом к серверу по ssh:

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

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

Надеемся, у Вас была запрошена парольная фраза для id_dsa, и Вы смогли получить доступ к серверу по ssh как server_user. Если это не так, войдите как server_user, и проверьте содержимое для того чтобы убедиться, кто каждая запись находится на отдельной строке. Вы также можете проверить конфигурацию sshd для того, чтобы убедиться что предпочитается использование авторизации с открытым ключом, когда это доступно.

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

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

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

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

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

Было бы неплохо узнать как закрыть ssh-agent, в случае если вам это потребуется, правда?

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

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

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

Обеспечение доступа к keychain в .bash_profile

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

Использование keychain с KDE
If you are a KDE user, instead of using, you can let KDE manage ssh-agent for you. In order to do so, you will have to edit, which is read during KDE's startup, and  , which is executed during KDE's shutdown. Here is how you could edit those files:

Editing /etc/kde/startup/agent-startup.sh

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

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

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

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

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


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

Благодарности
Мы хотели бы поблагодарить следующих авторов и редакторов за их вклад в это руководство:


 * Eric Brown
 * Marcelo Goes
 * nightmorph