SSH аутентификация при помощи открытого ключа

Материал из DiPHOST.Ru wiki system

Перейти к: навигация, поиск

SSH широко используется для безопасного доступа к удалённым системам. Большинство использующих SSH знакомы с обычной аутентификацией при помощи пароля. Это самый лёгкий, доступный по умолчанию, способ аутентификации пользователя. Но у него есть ряд недостатков, включающих проблемы безопасности, простоту и удобство использования. В протоколе SSH существует несколько удобных возможностей, позволяющих решить эти проблемы.

Содержание

Доступ по паролю

SSH обеспечивает обычный доступ с использованием логина и пароля.

Для примера рассмотрим подключение с домашнего компьютера пользователя HOME к серверу SERVER:

  1. Пользователь при помощи клиента SSH (программы, реализующей клиентскую часть SSH) , например PuTTY, устанавливает соединение с сервером. Происходит проверка и аутентификация сервера - сервер передаёт свой публичный ключ, устанавливается защищённое соединение. Обычно клиент SSH просит запомнить публичный ключ сервера и при каждом последующем подключении отслеживает соответствие сохранённого ключа переданному для проверки подлинности сервера.
  2. Клиент SSH передаёт по установленному защищённому соединению имя пользователя серверу. В отличии от Telnet, в SSH передача имени пользователя входит в состав протокола.Клиент SSH или уже настроен с определённым именем пользователя или предлагает ввести его перед соединением.
  3. В ответ на имя пользователя сервер посылает обратно запрос пароля.
  4. Клиент SSH предлагает пользователю ввести пароль и после ввода отсылает его на сервер по установленному ранее защищённому каналу.
  5. Сервер сравнивает присланный пароль с имеющимся у него в базе пользователей, и при совпалении предоставляет пользователю регламентированный доступ.

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

Доступ по ключу

Но у нас есть хорошая новость - SSH поддерживает аутентификацию по открытому ключу. Пользователь создает пару ключей - секретный и публичный, и устанавливает открытый ключ в файле $HOME/.ssh/authorized_keys на целевом сервере (верно для современных версий OpenSSH). Публичный ключ - открытая информация, которую можно не охранять. А секретный ключ защищен на пользовательском компьютере (мы надеемся) сильным паролем, или вообще находится на сменном хорошо защищённом носителе, например на флэшке.

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

Для примера рассмотрим подключение с домашнего компьютера пользователя HOME к серверу SERVER:

  1. Клиент SSH устанавливает соединение с сервером и передаёт по установленному защищённому соединению имя пользователя вместе с публичным ключом пользователя, взятым из указанного клиенту SSH секретного ключа.
  2. Сервер проверяет, имеется ли в файле $HOME/.ssh/authorized_keys заявленного пользователя публичный ключ тождественный присланному. Если такой ключ есть, сервер возвращает клиенту положительный ответ.
  3. При получении положительного ответа клиент SSH предлагает пользователю ввести пароль секретного ключа.
  4. Если пароль введён правильно и секретный ключ разблокирован, клиент SSH отсылает серверу зашифрованное при помощи секретного ключа специальное сообщение. Хотим обратить внимание на то, что сам секретный ключ не передаётся и не может быть перехвачен.
  5. Сервер расшифровывает присланное клиентом сообщение при помощи выбранного ранее публичного ключа и, если расшифровка проходит удачно, предоставляет регламентированный доступ. Технология проверки основывается на том, что информацию зашифрованную секретным ключом можно расшифровать только публичным ключом, но нельзя публичным ключом зашифровать обратно (подробнее об асимметричном шифровании).

Основной проблемой использования доступа по ключу мы считаем "невидимость". Всего лишь один раз воспользовавшись незакрытым пользователем окном ssh-клиента злоумышленник может внедрить свой публичный ключ (в дополнение к уже имеющемуся). И пользователь объективно вряд ли это скоро заметит.

Конечно, при использования доступа по ключу тоже происходит запрос пароля для разблокирования секретного ключа при каждом соединении. Но зато это один пароль для одного ключа, который подходит ко многим системам. И когда есть необходимость поменять ключ, требуется запомнить только один пароль.

Доступ по ключу без использования защиты паролем секретного ключа можно использовать в скриптах автоматизации, использующих SSH. На наш взгляд бессмысленно защищать ключ паролем и тут же всё равно прописывать его всяческими хитрыми способами в открытом виде в скрипте.

Управление ключами при помощи агента SSH

Но у нас есть ещё хорошая новость - популярные клиенты SSH предусматривает возможность использования специального агента управления ключами SSH.

Агент является постоянно находящейся в памяти программой, цель которой - хранить раскодированные секретные ключи. Раскодированные ключи хранятся в памяти компьютера в закодированном известном только агенту формате. После запуска агента требуется указать ему секретные ключи. Если секретный ключ защищён паролем, агент предложит ввести этот пароль. Это избавляет от необходимости вводить пароль при каждом соединении с использованием секретного ключа. Агент является дополнением к клиенту SSH, который автоматически видит присутствие агента и запрашивает секретные ключи у него, поэтому никаких дополнительных настроек не требуется.

Перенаправление агента SSH

Очень часто встречаются ситуации, когда есть несколько серверов, к которым имеется доступ SSH по ключам и требуется установить соединение с одного сервера на другой. Например, чтобы передать файл. Обычно аутентификация по ключам не настроена между серверами, а пароль очень сложен или вообще отсутствует (например, мы практически не пользуемся паролями). В таких ситуациях есть два очевидных выхода:

  1. настроить аутентификацию между пользователями на серверах по ключам;
  2. использовать машину пользователя в качестве посредника при передаче файлов.

И очередная хорошая новость - в протоколе SSH предусмотрена реализация перенаправления агента SSH. Суть его проста - клиент SSH после успешной аутентификации открывает специальный канал внутри соединения. В свою очередь, клиент SSH запущенный на сервере в данной терминальной сессии как бы видит запущенный агент SSH. И всё происходит как и в простой работе с агентом SSH с той разницей, что агент запущен на машине пользователя. Т.е. клиент SSH на сервере обращается за секретным ключом через специально созданный канал к агенту SSH на машине пользователя.

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

Но с перенаправлениями агента SSH надо быть осторожными. Администратор сервера имеет доступ ко всем файлам сервера, в том числе и служебным, открытым для реализации перенаправления. Поэтому, теоретически, администратор удалённого сервера имеет доступ ко ВСЕМ секретным ключам, обслуживаемым агентом SSH на машине пользователя. В том числе и к тем, которые не используются в данном соединении.

Примеры настроек

Источник — «https://wiki.diphost.ru/SSH-AUTH-KEYS»
Личные инструменты
© 2006 — ООО «Дремучий лес»
Служба техподдержки: support@diphost.ru
Тексты этого сайта являются полностью оригинальными
или оригинальными компиляциями ООО «Дремучий Лес».
Распространяются по лицензии WTFPL
Отзывы о хостинге diphost.ru Отзывы на hostobzor.ru