Keychain

From Gentoo Wiki
Jump to:navigation Jump to:search
This page is a translated version of the page Keychain and the translation is 92% complete.

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

Keychain is a frontend to ssh-agent and ssh-add, allowing long running sessions and letting the user enter passphases just once. It can also be used to allow scripts access to SSH connections.

Основы

Рассматриваемая проблема

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

Как работает аутентификация с открытым ключом?

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

Как использовать аутентификацию с открытым ключом

Генерация ключевой пары

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

user $ssh-keygen

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

Предупреждение
Убедитесь, что выбрали надежную ключевую фразу, особенно если этот ключ используется для входа в качестве пользователя root!

После завершения генерации закрытый ключ будет находиться в ~/.ssh/id_rsa, а открытый ключ — в ~/.ssh/id_rsa.pub. Открытый ключ готов для копирования на удаленный хост.

Adding or changing a passphrase for the private key can be done as follows:

user $ssh-keygen -p -f ~/.ssh/id_rsa

Подготовка сервера

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

user $ssh-copy-id -i ~/.ssh/id_rsa.pub server_user@server

ssh-copy-id это скрипт-обвертка для этих шагов. Если он недоступен, то можно воспользоваться следующими командами:

user $scp ~/.ssh/id_rsa.pub server_user@server:~/myhost.pub
user $ssh server_user@server "cat ~/myhost.pub >> ~/.ssh/authorized_keys"
user $ssh server_user@server "cat ~/.ssh/authorized_keys"

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

Тестирование настройки

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

user $ssh <server_user>@<server>

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

К этому моменту читатель, возможно, подумает: «А в чём смысл, я же просто заменил один пароль на другой?!» Не переживайте, в следующем разделе мы покажем, как можно вводить ключевую фразу всего один раз, а затем повторно использовать (расшифрованный) ключ для многократных подключений.

Как сделать аутентификацию с открытым ключом удобной

Обычное управление ключами с помощью ssh-agent

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

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

user $eval `ssh-agent`
Заметка
Этот экземпляр ssh-agent будет хранить ключи расшифрованными до тех пор, пока он работает. Чтобы установить время существования ключей, используйте параметр -t, как описано в man ssh-agent.

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

user $ssh-add somekeyfile

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

user $ssh server

Следующая команда останавливает ssh-agent (после чего при подключении понадобится вводить ключевую фразу):

user $ssh-agent -k
Заметка
Возможно, в системе ещё осталось несколько запущенных процессов ssh-agent (особенно, если всё делалось впервые). Эти процессы, как и другие, можно завершить командой killall ssh-agent.

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

Выжимание последней капли удобства из ssh-agent

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

root #emerge --ask net-misc/keychain

После успешной установки keychain готов к использованию.

Add the following to the shell initialization file (~/.bash_profile, ~/.zshrc, or similar) to enable it:

ФАЙЛ ~/.bash_profileВключение Keychain в Bash
keychain ~/.ssh/id_rsa
. ~/.keychain/${HOSTNAME}-sh
. ~/.keychain/${HOSTNAME}-sh-gpg
ФАЙЛ ~/.zshrcВключение Keychain в zsh
keychain ~/.ssh/id_rsa
. ~/.keychain/${HOST}-sh
. ~/.keychain/${HOST}-sh-gpg
Совет
По желанию можно добавить ещё несколько ключей. Если необходимо, чтобы ключевая фраза запрашивалась каждый раз при запуске командной оболочки, добавьте параметр --clear.
Заметка
Если bash или zsh не используется, обратитесь к разделу EXAMPLES из man keychain, чтобы посмотреть примеры использования в других оболочках. Основной идеей является запуск этих команд каждый раз, когда используется оболочка.

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

Все открытые после этого оболочки будут повторно использовать ssh-agent, что позволит создавать SSH-подключения без ввода пароля снова и снова.

Использование keychain с Plasma 5

Пользователи Plasma 5 вместо использования ~/.bash_profile могут позволить Plasma управлять программой ssh-agent. Для этого необходимо отредактировать файлы /etc/xdg/plasma-workspace/env/10-agent-startup.sh (который читается при запуске Plasma) и /etc/xdg/plasma-workspace/shutdown/10-agent-shutdown.sh (который читается при остановке).

Ниже показано, как они могут выглядеть:

ФАЙЛ /etc/xdg/plasma-workspace/env/10-agent-startup.shРедактирование для Plasma 5
SSH_AGENT=true
ФАЙЛ /etc/xdg/plasma-workspace/shutdown/10-agent-shutdown.shРедактирование для Plasma 5
if [ -n "${SSH_AGENT_PID}" ]; then
  eval "$(ssh-agent -k)"
fi

Теперь всё, что необходимо сделать, — это запустить любимый эмулятор терминала, например kde-apps/konsole, и загрузить нужную связку ключей для использования. Например:

user $keychain ~/.ssh/id_rsa

Ключи будут запомнены до окончания сеанса Plasma (или пока процесс ssh-agent не будет завершён вручную).

Alternatively use KWallet with kde-plasma/ksshaskpass under Plasma 5

You can also have Plasma automatically ask you for your passphrase upon desktop login. Emerge kde-plasma/ksshaskpass, which will set up an environment variable to use the ksshaskpass application whenever ssh-add is run outside of a terminal. Then create a script as follows, and install it via the Plasma -> System Settings -> Startup and Shutdown -> Autostart.

ФАЙЛ ~/ssh.shСоздание сценария ssh.sh
#!/bin/sh
ssh-add < /dev/null
Заметка
Recent versions of plasma seem to require autostart scripts to have user-only permissions. You may need to chmod 700 ssh.sh before adding the script via the Autostart GUI

Завершающие примечания

Соображения безопасности

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

Устранение проблем

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

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

Смотрите также

  • SSH — the ubiquitous tool for logging into and working on remote machines securely.

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



This page is based on a document formerly found on our main website gentoo.org.
The following people contributed to the original document: Eric Brown, Marcelo Goes,
They are listed here because wiki history does not allow for any external attribution. If you edit the wiki article, please do not add yourself here; your contributions are recorded on each article's associated history page.