Linux.yaroslavl.ru

Автор: Инга Захарова, 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 ‘ом информация в действительности представляет собой серию команд bash; если эти команды будут выполнены, то они установят две переменные среды: SSH_AUTH_SOCK и SSH_AGENT_PID. Благодаря включенным в перечень командам экспорта доступ к этим переменным среды могут получить любые дополнительные команды, запущенные позднее. В общем, все будет происходить именно так в том случае, если shell действительно вычислит данные в строках, но в данном случае они просто выведены в stdout. Чтобы исправить ситуацию мы можем вызвать 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-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 выполним необходимые настройки в

Как вы могли заметить, для 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 . Затем установите его нижеследующим образом:

Теперь когда keychain находится в вашей директории /usr/bin/, добавьте его в ваш файл

/.bash_profile, указывая в качестве аргументов путь к вашим личным ключам. Вот неплохой образец

/.bash_profile с действующим keychain (keychain-enabled

/.bash_profile с действующим keychain

Keychain в действии.

Теперь вы настроили

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

/.ssh-agent, а затем пригласит вас ввести ключевые фразы для каждого личного ключа, указанного в командной строке keychain в файле

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

После того как вы введете ваши ключевые фразы, ваши личные ключи будут кэшированы и keychain сам свернется. Затем будет задействован

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

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 или 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 и знать, как их использовать удобным и в то же время безопасным способом. Также не забудьте просмотреть нижеприведенные материалы.