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

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

(Различия между версиями)
Перейти к: навигация, поиск
м
Строка 23: Строка 23:
Технологию доступа по ключу можно аллегорически представить как если бы секретный ключ был таким маленьким красивым фигурным ключиком с затейливой бороздкой, а публичный - это замочек со скважина точно под этот ключ, которую можно устанавливать на разные сервера. Замочки можно распределять между серверами и пользователями на сервере и ко всем будет подходить этот затейливый ключик. Также можно вешать несколько разных замочков на одну и ту же точку доступа, не раздавая свой секретный ключик.
Технологию доступа по ключу можно аллегорически представить как если бы секретный ключ был таким маленьким красивым фигурным ключиком с затейливой бороздкой, а публичный - это замочек со скважина точно под этот ключ, которую можно устанавливать на разные сервера. Замочки можно распределять между серверами и пользователями на сервере и ко всем будет подходить этот затейливый ключик. Также можно вешать несколько разных замочков на одну и ту же точку доступа, не раздавая свой секретный ключик.
 +
 +
Основной проблемой использования доступа по ключу мы считаем "невидимость". Всего лишь один раз воспользовавшись незакрытым пользователем окном ssh-client злоумышленник может внедрить свой публичный ключ (в дополнение к уже имеющемуся). И пользователь объективно вряд ли это скоро заметит.
Конечно, при использования доступа по ключу тоже происходит запрос пароля для разблокирования секретного ключа при каждом соединении. Но зато это один пароль для одного ключа, который подходит ко многим системам. И когда есть необходимость поменять ключ, требуется запомнить только один пароль.  
Конечно, при использования доступа по ключу тоже происходит запрос пароля для разблокирования секретного ключа при каждом соединении. Но зато это один пароль для одного ключа, который подходит ко многим системам. И когда есть необходимость поменять ключ, требуется запомнить только один пароль.  
-
Но у нас и тут хорошая новость - протокол [[SSH]] даёт возможность использовать специальный [[SSH-AGENT|агент доступа]].
+
Но у нас и тут хорошая новость - протокол [[SSH]] предусматривает возможность использования специального [[SSH-AGENT|агента аутентификации SSH]].
-
Доступ по ключу без использования защиты паролем секретного ключа можно использовать в скриптах автоматизации, использующих [[SSH]]. На наш взгляд бессмысленно защищать ключ паролем и тут же всё равно прописывать его всяческими хитрыми способами в открытом виде в скрипте.
+
Доступ же по ключу без использования защиты паролем секретного ключа можно использовать в скриптах автоматизации, использующих [[SSH]]. На наш взгляд бессмысленно защищать ключ паролем и тут же всё равно прописывать его всяческими хитрыми способами в открытом виде в скрипте.
-
 
+
-
Основной проблемой использования доступа по ключу мы считаем "невидимость". Всего лишь один раз воспользовавшись незакрытым пользователем окном ssh-client злоумышленник может внедрить свой публичный ключ (в дополнение к уже имеющемуся). И пользователь объективно вряд ли это скоро заметит.
+

Версия 15:46, 13 октября 2010

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

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

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

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

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

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

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

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

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

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

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

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

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

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