Keychain/ru

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

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

Как работает аутентификация с открытым ключом?
Assume that a client wants to connect to the ssh daemon on a server. The client first generates a key pair and gives the public key to the server. Afterwards, whenever the client attempts to connect, the server sends a challenge that is encrypted with that public key. Only the holder of the corresponding private key (the client) is able to decrypt it, so the correct response leads to successful authentication.

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

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

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

Подготовка сервера
The file needs to be copied over to the server running sshd. It has to be added to the file that belongs the connecting user on the remote server. After ssh access to the server has been granted by infrastructure personnel, the following steps can be used to setup automatic login using a public key on the remote server:

The output from that last line should show the contents of the file. Make sure the output looks correct.

Тестирование установки
Theoretically, if all went well, and the sshd daemon on the server allows it (as this can be configured), ssh 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.

It should have asked for a passphrase for, and then grant access via ssh as the user  on the server. If not, login as, and verify that the contents of  has each entry (which is a public key) on a single line. It is also a good idea to check the sshd configuration to make sure that it allows to use public key authorization when available.

At this point, readers might be thinking, "What's the point, I just replaced one password with another?!" Relax, the next section will show exactly how we can use this to only enter the passphrase once and re-use the (decrypted) key for multiple logins.

Обычное управление ключами с помощью ssh-agent
The next step is to decrypt the private key(s) once, and gain the ability to ssh freely, without any passwords. That is exactly what the program ssh-agent is for.

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 will allow to reuse an ssh-agent between logins, and optionally prompt for passphrases each time the user logs in. Let's emerge it first:

Assuming that was successful, keychain</tt> can now be used. Add the following to the file to enable it:

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.

Устранение проблем
Most of this should work pretty well, but if problems do come up, then the following items might be of assistance.


 * If connecting without ssh-agent</tt> does not seem to work, consider using ssh with the  options 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, try using the   option with ssh</tt>, or change the server's.
 * If connecting with ssh-agent</tt> or keychain</tt> does not seem to work, then it may be that the current shell does not understand the commands used. Consult the man pages for ssh-agent and keychain for details on working with other shells.

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

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