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
Если Вы являетесь пользователем KDE, вместо использования, Вы можете позволить KDE управлять программой ssh-agent за Вас. Для того, чтобы это сделать, Вам необходимо отредактировать файл, который читается во время запуска KDE, и  , который запускается во время закрытия KDE. Здесь показано, как Вы можете отредактировать эти файлы:

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

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

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

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

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

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


 * If you are unable to connect without ssh-agent, consider using ssh with the arguments -vvv to find out what's happening. Sometimes the server is not configured to use public key authentication, sometimes it is configured to ask for local passwords anyway! If that is the case, you may want to also use the -o option with ssh, or change the server sshd_config.
 * If you are having problems with ssh-agent or keychain, it may be that you are not using a shell that understands the commands they use. Consult the man pages for ssh-agent and keychain for details on working with other shells.
 * You may also want to visit the keychain homepage for more usage tips.

Acknowledgements
We would like to thank the following authors and editors for their contributions to this guide:


 * Eric Brown
 * Marcelo Goes
 * nightmorph