Управление ключами SSH с помощью агента
Материал из Xgu.ru
 |
| Данная страница находится в разработке. Эта страница ещё не закончена. Информация, представленная здесь, может оказаться неполной или неверной. |
Если вы считаете, что её стоило бы доработать как можно быстрее, пожалуйста, скажите об этом.
Автор: Игорь Чубин
Короткий URL: ssh-agent
На этой странице описывается что такое ssh-agent, зачем он нужен и как правильно его использовать.
Вводить парольную фразу каждый раз, когда используется ssh не очень удобно. Было бы намного проще ввести ее один раз при входе в систему, сохранить где-нибудь, а затем все время пользоваться. Такую задачу позволяет решить специальная программа — ssh-agent.
ssh-agent хранит секретные ключи и, когда нужно, пользуется ими. Программа (например, ssh), когда ей понадобится воспользоваться секретным ключом, не делает этого сама, а обращается к ssh-agent ‘у, который в свою очередь уже сам пользуется известными только ему данными о секретных ключах. Таким образом, секретные ключи не разглашаются никому, даже программам принадлежащим самому пользователю.
Программу ssh-agent можно использовать двумя разными способами:
В обоих случаях ssh-agent создает файл-сокет с именем /tmp/ssh-XXXXXXXX/agent.ppid, через который осуществляется взаимодействие с агентом. Всем дочерним процессам агент при помощи переменных окружения SSH_AUTH_SOCK (в которой хранится имя файла-сокета) и SSH_AGENT_PID (в которой хранится идентификатор процесс агента) сообщает информацию о том, как с ним можно связаться.
В первом случае агент выдает информацию в виде, удобном для использования командным интерпретатором.
При указании ключа -c агент использует синтаксис C Shell. По умолчанию (и при явном указании ключа -s) используется синтаксис Bourne Shell. Эти переменные следует установить в текущем командном интерпретаторе, поэтому обычно вызов ssh-agent комбинируется с командой eval.
Во втором случае агент экспортирует значения переменных в среду окружения и порождает дочерний процесс, выполняя в нем команду. Достигается аналогичный результат, только при этом порождается дополнительный процесс.
Для того чтобы использовать ssh-agent в системе X Window, нужно добавить строку
eval `ssh-agent -s`; ssh-add %$ ssh-add options file
При вызове без параметров ssh-add сообщает агенту информацию о ключах из файлов identity, id_dsa и id_rsa. При этом программа спрашивает парольную фразу для каждого из ключей (или, если фразы совпадают, всего один раз). Ключ, для которого правильно была введена парольная фраза передается агенту.
Если в качестве аргумента командной строки указан файл, программа сообщает агенту информацию только о том ключе, который находится в файле.
Список известных агенту секретных ключей можно посмотреть той же командой ssh-add с ключом командной строки -l. Команда сообщит и отпечаток для каждого ключа.
Опции командной строки программы ssh-add
- -l — Показать список отпечатков известных агенту ключей
- -L — Показать информацию обо всех открытых ключах, соответствующих секретным ключам, известным ssh-add
- -d — Удалить ключ у агента
- -D — Удалить все ключи у агента
- -x — Заблокировать агента паролем
- -X — Разблокировать агента
Источник
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 и знать, как их использовать удобным и в то же время безопасным способом. Также не забудьте просмотреть нижеприведенные материалы.
Источник
