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

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

(Различия между версиями)
Перейти к: навигация, поиск
Строка 20: Строка 20:
=== Доступ по ключу ===
=== Доступ по ключу ===
-
Но у нас есть хорошая новость - [[SSH]] поддерживает [[Authentication|аутентификацию]] по [[Cryptography|открытому ключу]]. Пользователь создает пару ключей - секретный и публичный, и устанавливает открытый ключ в файле $HOME/.ssh/authorized_keys на целевом сервере (верно для современных версий OpenSSH). Публичный ключ - открытая информация, которую можно не охранять. А секретный ключ защищен на пользовательском компьютере, (мы надеемся), сильным паролем, или вообще находится на сменном хорошо защищённом носителе, например на флэшке.  
+
Но у нас есть хорошая новость - [[SSH]] поддерживает [[Authentication|аутентификацию]] по [[Cryptography|открытому ключу]]. Пользователь создает пару ключей - секретный и публичный, и устанавливает открытый ключ в файле $HOME/.ssh/authorized_keys на целевом сервере (верно для современных версий OpenSSH). Публичный ключ - открытая информация, которую можно не охранять. А секретный ключ защищен на пользовательском компьютере (мы надеемся) сильным паролем, или вообще находится на сменном хорошо защищённом носителе, например на флэшке.  
Технологию доступа по ключу можно аллегорически представить как если бы секретный ключ был таким маленьким красивым фигурным ключиком с затейливой бороздкой, а публичный - это замочек со скважина точно под этот ключ, которую можно устанавливать на разные сервера. Замочки можно распределять между серверами и пользователями на сервере и ко всем будет подходить этот затейливый ключик. Также можно вешать несколько разных замочков на одну и ту же точку доступа, не раздавая свой секретный ключик.
Технологию доступа по ключу можно аллегорически представить как если бы секретный ключ был таким маленьким красивым фигурным ключиком с затейливой бороздкой, а публичный - это замочек со скважина точно под этот ключ, которую можно устанавливать на разные сервера. Замочки можно распределять между серверами и пользователями на сервере и ко всем будет подходить этот затейливый ключик. Также можно вешать несколько разных замочков на одну и ту же точку доступа, не раздавая свой секретный ключик.
Строка 31: Строка 31:
# Сервер проверяет, соответствует ли секретный ключ клиента публичному ключу, находящемуся на сервере, при помощи присланной информации. Если ключи соответствуют друг другу, сервер предоставляет регламентированный доступ.
# Сервер проверяет, соответствует ли секретный ключ клиента публичному ключу, находящемуся на сервере, при помощи присланной информации. Если ключи соответствуют друг другу, сервер предоставляет регламентированный доступ.
-
Основной проблемой использования доступа по ключу мы считаем "невидимость". Всего лишь один раз воспользовавшись незакрытым пользователем окном ssh-client злоумышленник может внедрить свой публичный ключ (в дополнение к уже имеющемуся). И пользователь объективно вряд ли это скоро заметит.
+
Основной проблемой использования доступа по ключу мы считаем "невидимость". Всего лишь один раз воспользовавшись незакрытым пользователем окном ssh-клиента злоумышленник может внедрить свой публичный ключ (в дополнение к уже имеющемуся). И пользователь объективно вряд ли это скоро заметит.
Конечно, при использования доступа по ключу тоже происходит запрос пароля для разблокирования секретного ключа при каждом соединении. Но зато это один пароль для одного ключа, который подходит ко многим системам. И когда есть необходимость поменять ключ, требуется запомнить только один пароль.  
Конечно, при использования доступа по ключу тоже происходит запрос пароля для разблокирования секретного ключа при каждом соединении. Но зато это один пароль для одного ключа, который подходит ко многим системам. И когда есть необходимость поменять ключ, требуется запомнить только один пароль.  

Версия 16:04, 13 октября 2010

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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