Keychain/ru

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

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

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

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

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

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

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

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

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

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

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

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

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

When running ssh-agent</tt>, it should output the PID of the running ssh-agent, and also set a few environment variables, namely  and. It should also automatically add to it's collection and ask the user for the corresponding passphrase. If other private keys exist which need to be added to the running ssh-agent, use the ssh-add</tt> command:

Now for the magic. With the decrypted private key ready, ssh into a (public key configured) server without entering any passwords:

In order to shut down ssh-agent (and as such require entry of the passphrase again later):

To get even more convenience from ssh-agent, proceed to the next section on using keychain. Be sure to kill the running ssh-agent as keychain will handle the ssh-agent</tt> sessions itself.

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

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

Now test it. First make sure the ssh-agent processes from the previous section are killed, then start up a new shell, usually by just logging in, or spawning a new terminal. It should prompt for the password for each key specified on the command line. All shells opened after that point should reuse the ssh-agent, allowing to use passwordless ssh connections over and over.

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

Now, all that has to be done is launch a terminal of choice, like Konsole, and load the right set of keys to use. For example:

The keys will be remembered until the end of the KDE session (or until the ssh-agent process is killed manually).

Соображения безопасности
Of course, the use of ssh-agent may add a bit of insecurity to the system. If another user would gain access to a running shell, he could login to all of the servers without passwords. As a result, it is a risk to the servers, and users should be sure to consult the local security policy (if any). Be sure to take the appropriate measures to ensure the security of all sessions.

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


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

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

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