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

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

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

Из этой серии статей вы узнаете, как действует RSA и DSA-аутентификация и как правильно настроить беспарольную аутентификацию. В первой статье цикла Дэниел Робинс уделяет внимание представлению протоколов аутентификации RSA и DSA и демонстрирует, как применять их для работы в сети.

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

Что такое RSA/DSA-аутентификация?

SSH, и в особенности OpenSSH (свободно распространяемая версия SSH) – просто невероятная утилита. Так же, как и в telnet или rsh, ssh-клиент может быть использован для входа на удаленную машину. Все, что требуется от этой удаленной машины – использовать sshd, серверный процесс ssh. Но в отличие от telnet, протокол ssh является безопасным. Он использует специальные алгоритмы для шифрования потоков данных, обеспечивая неприкосновенность и целостность потока данных, и выполняет аутентификацию надежным и безопасным способом.

Хотя ssh действительно замечательная программа, среди функций ssh существует определенная компонента, часто обделяемая вниманием и катастрофически неиспользуемая, или просто недопонятая. Эта компонента – система ключей аутентификации RSA/DSA для OpenSSH, являющаяся альтернативой стандартной системе аутентификации безопасных паролей, которая в OpenSSH используется по умолчанию.

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

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

Как работают ключи RSA/DSA.

Вот общий обзор принципов работы ключей RSA/DSA. Начнем с гипотетического сценария, в котором мы хотим использовать RSA-аутентификацию, дабы позволить локальной рабочей станции под Linux (назовем ее localbox) открыть shell на удаленной машине remotebox нашего поставшика интернет услуг (ISP). И теперь, при попытке установить соединение с remotebox используя клиент ssh, мы получаем следующее уведомление:


% ssh drobbins@remotebox
drobbins@remotebox's password:

Вот пример того, как ssh по умолчанию управляет аутентификацией. А именно, она запрашивает пароль учетной записи drobbins на remotebox. Если мы наберем пароль для remotebox, ssh задействует собственный безопасный протокол аутентификации паролей, который передаст наш пароль дальше на remotebox для подтверждения. Однако в отличие от того, как это происходит в telnet, здесь наш пароль зашифрован, таким образом тому, кто прослушивает наше соединение, не удастся его перехватить. Далее remotebox произведет аутентификацию поступившего от нас пароля с собственной базой данных паролей, и в случае успешного отождествления нам будет позволено войти и shell машины remotebox выдаст сообщение с приветствием. И хотя метод аутентификации осуществляемый ssh по умолчанию вполне надежен, все же RSA/DSA-аутентификация раскрывает кое-какие дополнительные возможности.

Однако, в отличие от осуществляемой ssh надежной «парольной» аутентификации, RSA-аутентификация требует некоторой первоначальной настройки. Нам нужно только один раз выполнить пункты этой первоначальной настройки. После этого RSA-аутентификация между localbox и remotebox станет абсолютно беспроблемной процедурой. Чтобы настроить RSA-аутентификацию, нам прежде всего потребуется генерировать пару ключей. Один личный и один публичный. Эти два ключа обладают весьма интересными особенностями. Публичный ключ можно использовать для шифрования сообщений и только владелец личного ключа сможет это сообщение дешифровать. Публичный ключ используется только для шифрования, а личный ключ используется только для расшифровки сообщений, закодированных при помощи соответствующего публичного ключа. Протоколы RSA- (и DSA-) аутентификации используют специфические особенности парных ключей для осуществления безопасной аутентификации, где нет необходимости пересылать конфиденциальную информацию через сеть.

Для того чтобы RSA- или DSA-аутентификация заработала, выполняем один единственный пункт настройки. Копируем наш публичный ключ через сеть на remotebox. «Публичным» этот ключ назван не без оснований. Поскольку он может быть использован только для шифрования наших сообщений, не стоит особенно беспокоиться, если он попадет в чужие руки. Теперь, когда публичный ключ скопирован через сеть на remotebox и помещен в специальный файл (~/.ssh/authorized_keys), sshd remotebox'а сможет его обнаружить, и мы готовы использовать RSA-аутентификацию для входа на remotebox. Чтобы это сделать, мы просто как всегда набираем ssh drobbins@remotebox на консоли localbox. Однако теперь ssh сообщает sshd remotebox'а, что она хочет использовать протокол аутентификации RSA. А дальше происходит совсем интересное. sshd remotebox'а генерирует случайное число и зашифровывает его при помощи публичного ключа, скопированного нами ранее. Затем он отправляет это случайное число в зашифрованном виде обратно к ssh на localbox'е. В свою очередь ssh нашей машины использует свой личный ключ для расшифровки этого случайного числа, которое затем отправляет обратно на remotebox в качестве утверждения: «Видишь, у меня на самом деле есть соответствующий личный ключ. Я смогла успешно расшифровать твое сообщение!» В итоге sshd делает вывод, что нам можно позволить войти, поскольку у нас есть соответствующий личный ключ. Таким образом наличие у нас соответствующего личного ключа обеспечивает нам доступ к remotebox.

Два нюанса.

Существует два немаловажных нюанса, касающихся RSA/DSA-аутентификации. Первое – то, что нам в действительности понадобится генерировать всего лишь пару ключей. Далее мы можем скопировать публичный ключ на удаленные машины, к которым хотим получить доступ, и все они будут успешно аутентифицировать нас по нашему личному ключу. Другими словами, нам не понадобится своя пара ключей для каждой системы, к которой мы хотим получить доступ. Будет достаточно одной единственной пары.

Второй нюанс заключается в том, что ваш личный ключ не должен попасть в чужие руки. Личный ключ – единственная вещь, открывающая доступ к вашим удаленным системам, и любому использующему ваш личный ключ обеспечиваются точно такие же как у вас права. Мы не собираемся давать незнакомцам ключи от нашего дома, и точно так же нужно защитить свой личный ключ от несанкционированного использования. В мире битов и байтов это означает, что никто не должен иметь возможности прочесть или скопировать ваш личный ключ.

Конечно, разработчики ssh осознают важность личного ключа, и в ssh и генераторе ключей ssh-keygen предпринят ряд мер безопасности для того чтобы не нарушался режим использования личного ключа. Во-первых, ssh настроен таким образом, чтобы выводить большое предупредительное сообщение, если кто-либо кроме вас имеет доступ «чтение» к файлу личного ключа. Во-вторых, когда вы при помощи ssh-keygen создаете вашу пару ключей личный/публичный, ssh-keygen попросит вас ввести ключевую фразу. Если вы это делаете, то ваш личный ключ будет зашифрован с использованием этой ключевой фразы, таким образом даже если ключ будет похищен, он будет абсолютно бесполезен в руках того, кто этой фразы не знает. Вооруженные этим знанием, давайте посмотрим как настроить ssh на использование протоколов RSA- и DSA-аутентификации.

ssh-keygen при «ближайшем рассмотрении».

Первый шаг настройки RSA-аутентификации начинается с генерирования пары ключей публичный/личный. RSA-аутентификация – оригинальная версия ключевой аутентификации ssh, поэтому RSA будет работать с любой версией OpenSSH, кроме того я рекомендую вам установить самую свежую доступную версию (на момент, когда была написана эта статья, это openssh-2.9_p2). Генерируйте пару ключей RSA как показано ниже:


% ssh-keygen
Generating public/private rsa1 key pair
Enter file in which to save the key (/home/drobbins/.ssh/identity): (нажмите ввод)
Enter passphrase (empty for no passphrase): (введите ключевую фразу)
Enter same passphrase again: (введите фразу еще раз)
Your identification has been saved in /home/drobbins/.ssh/identity.
Your public key has been saved in /home/drobbins/.ssh/identity.pub.
The key fingerprint is:
a4:e7:f2:39:a7:eb:fd:f8:39:f1:f1:7b:fe:48:a1:09 drobbins@localbox

Когда ssh-keygen запрашивает местонахождение ключа по умолчанию, нажимаем ввод в знак принятия указанного по умолчанию /home/drobbins/.ssh/identity. ssh-keygen будет хранить личный ключ под приведенным выше паролем, а публичный ключ будет храниться рядом с ним в файле с именем identity.pub.

Обратите внимание, что ssh-keygen советовал вам ввести ключевую фразу. Следуя совету вы ввели хорошую фразу (состоящую из семи или более труднопредсказуемых символов). После этого ssh-keygen зашифровал ваш личный ключ (~/.ssh/identity) используя эту фразу, таким образом ваш личный ключ будет бесполезен для того, кто этой фразы не знает.

Быстрый компромисс.

Если вы задаете ключевую фразу, это позволяет ssh-keygen защитить ваш личный ключ от злоумышленного использования, но также создает и некоторое неудобство. Теперь, каждый раз, когда вы пытаетесь, используя ssh установить соединение с учетной записью drobbins@remotebox, ssh просит вас ввести ключевую фразу, чтобы расшифровать ваш личный ключ и использовать его для RSA-аутентификации. Еще раз напоминаю, что мы не будем вводить пароль для учетной записи drobbins на remotebox, мы наберем ключевую фразу, необходимую для расшифровки личного ключа на локальной машине. Поскольку наш личный ключ зашифрован, ssh-клиент позаботится обо всем остальном. Хотя механизмы использования пароля для удаленного доступа и ключевой фразы в RSA абсолютно различны, на практике нас по-прежнему приглашают набрать в ssh «условную фразу».


# ssh drobbins@remotebox
Enter passphrase for key '/home/drobbins/.ssh/identity': (введите ключевую фразу)
Last login: Thu Jun 28 20:28:47 2001 from localbox.gentoo.org
Welcome to remotebox!
%

И вот именно здесь люди вступают на опасный путь «быстрого компромисса». В большинстве случаев люди создают незашифрованные личные ключи, поэтому им не приходится вводить пароль. Таким образом они просто вводят команду ssh, сразу же аутентифицируются посредством RSA (или DSA) и входят в систему.


# ssh drobbins@remotebox
Last login: Thu Jun 28 20:28:47 2001 from localbox.gentoo.org
Welcome to remotebox!
%

Несмотря на то, что так удобнее, вы не должны использовать подобный подход, не отдавая себе отчета какой удар по безопасности он наносит. При использовании незашифрованного личного ключа, если кто-нибудь когда-либо взломает ваш localbox, он автоматически получит доступ к remotebox и всем другим системам, которые были настроены с помощью публичного ключа.

Знаю, о чем вы подумали. Беспарольная аутентификация, несмотря на несколько повышенную степень риска, все же кажется воистину привлекательной. Я полностью с этим согласен. Но существует лучший выход! Оставайтесь со мной, и я покажу вам, как получить все преимущества беспарольной аутентификации, не подвергая риску безопасность вашего личного ключа. В своей следующей статье я покажу вам, как мастерски использовать ssh-agent (ту самую штуку, которая в первую очередь делает возможной безопасную беспарольную аутентификацию). А сейчас давайте приготовимся использовать ssh-agent для настройки RSA- и DSA-аутентификации. Вот вам пошаговые указания на этот счет.

Генерирование пары RSA-ключей.

Для того, чтобы настроить RSA-аутентификацию понадобится один раз выполнить действие по созданию пары ключей личный/публичный. Делаем это, набирая:


% ssh-keygen

Подтвердите месторасположение ключа по умолчанию (как правило, для публичного ключа это ~/.ssh/identity and ~/.ssh/identity.pub) в строке предложения и снабдите ssh-keygen надежной ключевой фразой. Когда ssh-keygen завершит процесс, у вас в наличии будет публичный ключ, а также зашифрованных с помощью ключевой фразы личный ключ.

Установка публичного ключа RSA.

Далее нам необходимо настроить удаленные системы, в которых работает sshd, чтобы использовать для аутентификации наш публичный RSA-ключ. Как правило, это осуществляется копированием публичного ключа в удаленную систему следующим образом:


% scp ~/.ssh/identity.pub drobbins@remotebox:

До тех пор, пока RSA-аутентификация не будет полностью настроена, строка приглашения будет требовать от нас ввести пароль для доступа к remotebox. Сделайте это. Теперь войдите в систему remotebox и добавьте публичный ключ в файл ~/.ssh/authorized_keys вот таким образом:


% ssh drobbins@remotebox
drobbins@remotebox's password: (введите пароль)
Last login: Thu Jun 28 20:28:47 2001 from localbox.gentoo.org

Welcome to remotebox!
% cat identity.pub >> ~/.ssh/authorized_keys
% exit

Теперь, когда RSA-аутентификация настроена, при попытке установить соединение с remotebox посредством ssh, в строке приглашения вас попросят ввести ключевую фразу RSA (вместо пароля).


% ssh drobbins@remotebox
Enter passphrase for key '/home/drobbins/.ssh/identity':

Ура, настройка RSA-аутентификации завершена! Если вы не получили приглашения ввести ключевую фразу, вам следует кое-что проверить. Прежде всего попытайтесь войти в систему, набирая ssh -1 drobbins@remotebox. Таким образом вы укажете ssh использовать только версию 1 ssh-протокола, вам может это потребоваться, если по какой-либо причине удаленная система по умолчанию настроена использовать DSA-аутентификацию. Если это не работает, убедитесь, что у вас нет строки, которая считывает запрет RSA-аутентификации из вашего файла /etc/ssh/ssh_config. Если такая есть, отметьте ее, поставив в начале «#». В противном случае попытайтесь связаться с администратором системы remotebox и удостоверьтесь, что RSA-аутентификация разрешена к использованию на выходе и соответствующие настройки имеются в файле /etc/ssh/sshd_config.

Генерирование DSA-ключей.

Если RSA-ключи используются протоколом ssh версии 1, то DSA-ключи используются для 2-го уровня и обновленной версии протокола. Любая из современных версий OpenSSH должна поддерживать работу как RSA так и DSA ключей. Генерирование DSA-ключей посредством ssh-keygen для OpenSSH можно осуществить аналогично той же процедуре в RSA следующим образом:


% ssh-keygen -t dsa

И опять мы получим приглашение ввести ключевую фразу. Введите какую-нибудь понадежнее. Мы также получим приглашение указать место, куда будут сохранены наши DSA-ключи. Обычно предлагаемый по умолчанию файл ~/.ssh/id_dsa and ~/.ssh/id_dsa.pub вполне подойдет. Генерирование ключей DSA завершено, и теперь самое время установить публичный DSA-ключ в удаленной системе.

Установка публичного DSA-ключа.

И снова мы сталкиваемся с тем, что установка публичного DSA-ключа практически идентична такой же процедуре в RSA. Для DSA мы скопируем наш файл ~/.ssh/id_dsa.pub в удаленную систему remotebox и добавим его в файл ~/.ssh/authorized_keys2 в этой системе. Обратите внимание, что этот файл имеет иное имя, чем файл authorized_keys в RSA. По окончании настройки мы должны получить возможность входить в систему remotebox, набирая ключевую фразу для личного DSA-ключа, вместо того чтобы вводить текущий пароль для входа в remotebox.

В следующий раз.

Теперь у вас имеется работающая RSA- или DSA-аутентификация, но вам все еще приходится вводить ключевую фразу для каждого нового соединения. В моей следующей статье вы увидите, как использовать ssh-agent – действительно классную систему, позволяющую устанавливать соединения без предоставления пароля, но при этом также позволяющую хранить наши личные ключи зашифрованными на диске. Я также представлю вашему вниманию keychain – весьма полезного клиента ssh-agent'а, который делает ssh-agent еще более надежным, удобным и прикольным. А пока ознакомьтесь с полезными источниками, приведенными ниже, дабы войти в курс дела.

Источники

Об авторе

Проживающий в Альбукерке, Нью-Мексико (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.


(часть 2)




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