Управление ключами в OpenSSH, Часть 2

Автор: Инга Захарова, arlantine@lnx.ru
Опубликовано: 11.6.2002

Перевод статьи Дэниэла Робинса (Daniel Robbins) OpenSSH key management, Part 2

Многие разработчики используют замечательную программу OpenSSH в качестве защищенной шифрованной замены архаичных команд telnet и rsh. Одной из самых захватывающих особенностей OpenSSH является ее способность аутентифицировать пользователей посредством протоколов аутентификации RSA и DSA, в основе которых лежит пара комплементарных числовых «ключей». Одной из самых притягательных сторон RSA- и DSA-аутентификации является их потенциальная способность устанавливать соединения с удаленными системами без указания пароля. В этой второй статье Дэниел представляет вашему вниманию ssh-agent (кэш личного ключа) и keychain – специальный скрипт bash, разработанный для того, чтобы сделать основанную на ключах аутентификацию исключительно удобной и маневренной.

Знакомство с ssh-agent.

Включенный в дистрибутив OpenSSH ssh-agent – специальная программа, разработанная для того, чтобы сделать работу с ключами RSA и DSA приятной и безопасной (смотрите Первую часть этого выпуска для ознакомления с RSA- и DSA-аутентификацией). В отличие от ssh, ssh-agent – это постоянно работающий демон, созданный исключительно для кэширования ваших дешифрованных личных ключей.

В ssh включены встроенные средства поддержки, позволяющие ему общаться с ssh-agent'ом, а ssh-agent'у – получать ваши дешифрованные личные ключи не приглашая вас вводить пароль при установлении каждого нового соединения. При работе с ssh-agent'ом вы просто используете ssh-add, чтобы добавить ваш личный ключ в кэш ssh-agent'а. Это делается один раз; после использования ssh-add, ssh будет извлекать ваш личный ключ из ssh-agent'а, вместо того чтобы выдавать вам приглашение ввести ключевую фразу.

Использование ssh-agent.

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

% ssh-agent
SSH_AUTH_SOCK=/tmp/ssh-XX4LkMJS/agent.26916; export SSH_AUTH_SOCK;
SSH_AGENT_PID=26917; export SSH_AGENT_PID;
echo Agent pid 26917;

Как вы видите, выводимая ssh-agent'ом информация в действительности представляет собой серию команд bash; если эти команды будут выполнены, то они установят две переменные среды: SSH_AUTH_SOCK и SSH_AGENT_PID. Благодаря включенным в перечень командам экспорта доступ к этим переменным среды могут получить любые дополнительные команды, запущенные позднее. В общем, все будет происходить именно так в том случае, если shell действительно вычислит данные в строках, но в данном случае они просто выведены в stdout. Чтобы исправить ситуацию мы можем вызвать ssh-agent нижеприведенным способом:

eval `ssh-agent`

Эта команда указывает bash запустить ssh-agent и вычислить выведенные им данные. Вызванные таким образом (с back-quotes, а не обычными едиными квотами) переменные SSH_AGENT_PID и SSH_AUTH_SOCK будут установлены и экспортированы вашей shell, что сделает эти переменные доступными для любых новых процессов, которые вы, возможно, запустите в процессе работы.

Лучший способ запустить ssh-agent – добавить строку в самый верх вашего файла ~/.bash_profile. В этом случае все программы, запускаемые в вашем login shell, будут видеть переменные среды, смогут определить местонахождение ssh-agent'а и, если понадобится, запросить у него ключи. Исключительно важной переменной среды является SSH_AUTH_SOCK. SSH_AUTH_SOCK содержит маршрут к UNIX domain socket, который ssh и scp могут использовать для установления диалога с ssh-agent'ом.

Использование ssh-add.

Но, конечно же, при запуске ssh-agent'а его кэш не содержит дешифрованных личных ключей. Прежде, чем мы сможем реально использовать ssh-agent, нам необходимо добавить наш личный ключ(и) в кэш ssh-agent'а при помощи команды ssh-add. В нижеприведенном примере я использую команду ssh-add чтобы добавить мой личный RSA-ключ ~/.ssh/identity в кэш ssh-agent.

# ssh-add ~/.ssh/identity
Need passphrase for /home/drobbins/.ssh/identity
Enter passphrase for /home/drobbins/.ssh/identity
(введите ключевую фразу)

Как вы видите, ssh-add запросила у меня ключевую фразу для того чтобы расшифровать личный ключ, который после этого будет готов к использованию и будет храниться в кэше ssh-agent. Теперь, когда вы использовали команду ssh-add чтобы добавить ваш личный ключ (или ключи) в кэш ssh-agent, а в вашей текущей shell определена переменная SSH_AUTH_SOCK (а она должна быть определена, если вы запускали ssh-agent из ~/.bash_profile), вы можете использовать scp и ssh для установления соединений с удаленными системами без указания вашей ключевой фразы.

Ограничения ssh-agent.

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

В одном случае, связанном с eval `ssh-agent` в ~/.bash_profile, для каждой сессии запускается новая копия ssh-agent, и это означает не только создание дополнительных тэгов, но и то, что вам придется использовать ssh-add для добавления личного ключа в каждой новой копии ssh-agent. Не велика проблема, если вы открываете единичный терминал или консоль в вашей системе, но большинство из нас открывает сразу несколько терминалов и вынуждены вводить ключевую фразу каждый раз при открытии новой консоли. Формально нет причины, по которой мы непременно должны так поступать, в то время как однократного подобного действия в ssh-agent должно быть вполне достаточно.

Другая проблема, связанная с настройками ssh-agent по умолчанию, состоит в том, что он не совместим с cron jobs. После того как cron jobs запускаются процессом cron, они не наследуют из своей среды переменную SSH_AUTH_SOCK, и поэтому не знают ни того, что процесс ssh-agent запущен, ни как с ним связаться. Как оказалось, эта проблема тоже решаема.

Ввод keychain.

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

Вот краткий обзор принципов работы keychain. Когда он запускается из файла ~/.bash_profile, он прежде всего проверит, запустился или нет ssh-agent. Если нет, то он запустит ssh-agent и запишет немаловажные переменные SSH_AUTH_SOCK и SSH_AGENT_PID в файл ~/.ssh-agent для сохранности и возможности дальнейшего использования. Здесь приведен лучший способ запуска keychain; как при использовании доброго старого ssh-agent выполним необходимые настройки в ~/.bash_profile:

#!/bin/bash
#example ~/.bash_profile file
/usr/bin/keychain ~/.ssh/id_rsa
#redirect ~/.ssh-agent output to /dev/null to zap the annoying
#"Agent PID" message
source ~/.ssh-agent > /dev/null

Как вы могли заметить, для keychain мы используем в качестве исходного файл source the ~/.ssh-agent, вместо того чтобы вычислять выведенные данные, как при непосредственном использовании ssh-agent. Хотя результат такой же: чрезвычайно важная переменная SSH_AUTH_SOCK определена, ssh-agent запущен и готов к работе. А поскольку SSH_AUTH_SOCK записана в файл ~/.ssh-agent, то скрипты нашего собственного shell и cron jobs могут без труда связаться с ssh-agent просто используя информацию из файла ~/.ssh-agent. Сам keychain также использует преимущества этого файла. Вспомните, что при запуске keychain проверяет, запущен ли ssh-agent. Если запущен, то тогда keychain воспользуется файлом ~/.ssh-agent чтобы запросить точные установочные параметры переменной SSH_AUTH_SOCK, это позволит ей использовать уже действующую agent, а не открывать новую. keychain запустит новый процесс ssh-agent только в том случае, если файл ~/.ssh-agent является устаревшим (ссылается на уже не существующий ssh-agent) или если сам этот файл не существует.

Установка keychain.

Установить keychain просто. Сначала отправьтесь на keychain project page и скачайте из архива самую свежую версию keychain. Затем установите его нижеследующим образом:

# tar xzvf keychain-1.0.tar.gz
# cd keychain-1.0
# install -m0755 keychain /usr/bin

Теперь когда keychain находится в вашей директории /usr/bin/, добавьте его в ваш файл ~/.bash_profile, указывая в качестве аргументов путь к вашим личным ключам. Вот неплохой образец ~/.bash_profile с действующим keychain (keychain-enabled ~/.bash_profile):
Пример ~/.bash_profile с действующим keychain

#!/bin/bash
# в этой следующей стороке мы запускаем keychain
# и указываем ему те личные ключи, которые он должен будет кэшировать
/usr/bin/keychain ~/.ssh/id_rsa ~/.ssh/id_dsa
source ~/.ssh-agent > /dev/null
#sourcing ~/.bashrc is a good thing
source ~/.bashrc

Keychain в действии.

Теперь вы настроили ~/.bash_profile вызывать keychain при каждом входе в систему, выходе из нее и возвращении. Когда это будет происходить, keychain будет запускать ssh-agent и записывать установочные характеристики переменной среды agent'а в файл ~/.ssh-agent, а затем пригласит вас ввести ключевые фразы для каждого личного ключа, указанного в командной строке keychain в файле ~/.bash_profile:

 keychain-1

Keychain запускается в первый раз.

После того как вы введете ваши ключевые фразы, ваши личные ключи будут кэшированы и keychain сам свернется. Затем будет задействован ~/.ssh-agent, который инициализирует вашу сессию с ssh-agent. Теперь, если вы выйдете из системы и войдете вновь, то увидите, что keychain обнаружит уже действующий процесс ssh-agent (он не завершается при вашем выходе из системы). В дополнение ко всему keychain подтвердит наличие в кэш ssh-agent'а уже указанных вами личных ключей. В противном случае вы получите приглашение вести соответствующие ключевые фразы, хотя если все будет в порядке, то действующий ssh-agent должен по-прежнему содержать добавленные ранее личные ключи (это означает, что вас не попросят ввести пароль):

 keychain-2

Keychain обнаруживает действующий ssh-agent

Мои поздравления: вы только что вошли в систему и теперь сможете использовать ssh и scp для удаленных систем. Вам не придется сразу же после входа применять ssh-add и ни ssh ни scp не попросят вас ввести ключевую фразу. Фактически, пока работает ваш исходный процесс ssh-agent'а, вы сможете входить в систему и устанавливать соединения ssh без введения пароля. И вполне вероятно, что процесс ssh-agent'а будет продолжать работать до перезагрузки машины. Учитывая тот факт, что вы вероятнее всего установили эти программы в системе Linux, то, возможно, пароль вам не понадобится в течение нескольких месяцев! Добро пожаловать в мир защищенных беспарольных соединений, использующих RSA- и DSA-аутентификацию.

Продолжайте в том же духе и создайте несколько новых сессий и вы заметите, что keychain каждый раз будет делать «привязку» к одному и тому же процессу ssh-agent. Не забудьте, что вы можете так же «привязать» к уже запущенному процессу ssh-agent свои скрипты и cron jobs. Чтобы пользоваться командами ssh и scp из скриптов shell и cron jobs, для начала просто убедитесь, что они используют в качестве источника информации в первую очередь ваш файл ~/.ssh-agent:

source ~/.ssh-agent

Тогда любые последующие команды ssh или scp смогут обнаружить уже работающий ssh-agent и установить защищенное беспарольное соединение так же, как вы делаете это из shell.

Опции keychain.

После того как вы настроили и запустили keychain потрудитесь вызвать keychain --help дабы ознакомиться со всеми опциями командной строки keychain. Мы сейчас рассмотрим одну особенную: опцию --clear.

Если вы помните, в Части 1 я объяснял, что использование незашифрованных личных ключей чревато, поскольку дает возможность кому-нибудь украсть ваш личный ключ и использовать его для доступа к вашим удаленным учетным записям из любой системы безо всякого пароля. Ну, хотя keychain и не является уязвимой с этой точки зрения (поскольку вы используете зашифрованные личные ключи), все-таки в ее работе есть слабое место, непосредственно связанное с тем, что keychain позволяет так легко «делать привязку#187; к постоянно работающему процессу ssh-agent. Я думал, что произойдет, если какой-нибудь взломщик сможет каким-то образом вычислить мой пароль или ключевую фразу и войдет в мою локальную систему? Если он сможет каким-либо образом войти под моим именем, keychain тут же откроет ему доступ к моим дешифрованным личным ключам, что позволит взломщику без труда получить доступ ко всем остальным моим учетным записям.

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

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

Несмотря на это использование keychain с опцией --clear все же имеет преимущества перед использованием просто ssh-agent. Помните, что когда вы используете keychain --clear, ваши скрипты и cron jobs могут устанавливать беспарольные соединения, поскольку ваши личные ключи сбрасываются при входе в систему, а не при выходе из нее. А поскольку выход из системы не создает потенциальных брешей в безопасности, то у keychain нет причин реагировать на него сбросом ключей из ssh-agent. Таким образом опция --clear является идеальным выбором для нечасто посещаемых серверов на которых от случая к случаю необходимо выполнить защищенное копирование (такие как серверы для резервных копий, firewall'ы и router'ы).

Мы закончили!

Теперь когда выпуск по управлению ключами в OpenSSH завершен, вы должны быть хорошо знакомы с ключами RSA и DSA и знать, как их использовать удобным и в то же время безопасным способом. Также не забудьте просмотреть нижеприведенные материалы.

Источники

Об авторе

Проживающий в Альбукерке, Нью-Мексико (Albuquerque, New Mexico) Дэниел Робинс является Президентом/Главным Администратором компании Gentoo Technologies, Inc., создателем Gentoo Linux – продвинутой версии Linux для PC и системы Portage – системы портов нового поколения для Linux. Он так же в качестве автора выпустил книги Caldera OpenLinux Unleashed, SuSE Linux Unleashed, and Samba Unleashed в сотрудничестве с издательством Macmillan books. Достаточно регулярно Дэниел стал общаться с компьютером на втором курсе, когда впервые занялся исследованием языка программирования Logo на предмет определения потенциально опасной дозы Pac Man. Возможно, это объясняет тот факт, что с тех самых пор он является ведущим художником-графиком в компании SONY Electronic Publishing/Psygnosis. Свободное время Дэниел проводит со своей женой Мэри (Mary) и маленькой дочерью Надассой (Hadassah). Вы можете связаться с ним по e-mail: drobbins(at)gentoo.org.


(часть 3)




Наш баннер
Вы можете установить наш баннер на своем сайте или блоге, скопировав этот код:
RSS новости