The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Аутентификация на SSH сервере с использованием ключей (ssh auth pam)


<< Предыдущая ИНДЕКС Правка src / Печать Следующая >>
Ключевые слова: ssh, auth, pam,  (найти похожие документы)
From: Михаил Сгибнев <mixa(@).dreamcatcher.ru> Date: 2006-09-13 16:35:46 Subject: Аутентификация на SSH сервере с использованием ключей
by Brian Hatch

Перевод: Сгибнев Михаил

OpenSSH кроме паролей поддерживает еще несколько методов аутентификации. Он может быть сконфигурирован на использование методов PAM (Pluggable authentication modules), протокола Challenge/Response, Kerberos, аутентификации по доверенным хостам и такая экзотика как ключи X509. Но самым популярным является метод Identity/Pubkey.

Целью использования идентификации Identity/Pubkey является исключение использования статических паролей. Вместо того, чтобы каждый раз набирать пароли, которые могут быть перехвачены кейлоггером или просто подсмотрены, у нас на диске имеется пара ключей, которые и используются для проверки подлинности. Ваша учетная запись на сервере SSH имеет список Identities/Pubkeys, которому можно доверять и если Вы сможете доказать, что у вас есть и публичный и приватный ключ, то доступ будет предоставлен без запроса пароля.

Вот некоторые из положительных моментов этого типа аутентификации: В этой статье мы рассмотрим методу создания ключей и конфигурирование учетной записи.

Создание Identity/Pubkey

В оригинальной реализации SSHv1 Вы могли создать Identity, которое было парой RSA публичного и приватного ключей. В SSHv2 формат этих ключей был изменен, стали поддерживаться ключи RSA и DSA, и эта аутентификация была переименована в Pubkey. В контексте данной статьи эти обозначения будут использоваться взаимозаменяемо, так как реализуют идентичные функции.

С помощью утилиты ssh-keygen создадим необходимые ключи: Обратите внимание, что 'ssh-rsa...xahria@mydesktop' это одна строка, а не несколько.

Как Вы могли убедиться, ssh-keygen создал два файла: id_rsa и id_rsa.pub. В первом файле хранится приватный ключ, защищенный кодовой фразой, введенной Вами при создании, НИКОМУ не давайте копаться в этом файле. Второй файл - Ваш публичный ключ, он не содержит никаких тайн и может быть доступен любому встречному-поперечному. В случае утраты он может быть восстановлен из приватного ключа.

Типы ключей SSH

При создании ключей Вы указывали опцию -t rsa. Этим параметром мы указываем тип создаваемых ключей. Также возможно создать ключи rsa1, rsa или dsa. Рассмотрим их отличия:

Тип
Аргумент
Имя по умолчанию
Протокол
Пример заголовка
RSA1
-t rsa1
identity
SSH 1 protocol only
1024 35 118118225938285...
RSA
-t rsa
id_rsa
SSH 2 protocol only
ssh-dss AAAAB3nzaC1kc3M...
DSA
-t dsa
id_dsa
SSH 2 protocol only
ssh-rsa AAAAB3NzaC1yc2E...


Вы можете изменить имя файла с помощью опции -f filename. Если Вы не определили имя файла, то ключи будут записаны в каталог $HOME/.ssh/ с именем, принятым по умолчанию для данного типа ключа.

Разрешение Identity/Pubkey аутентификации на сервере

После того, как мы создали ключи, необходимо разрешить данный тип аутентификации на сервере SSH. Сначала определим тип аутентификации - Pubkey или Identity, установив следующие настройки в sshd_config: Приведенные выше значения разрешают аутентификацию Identity/Pubkey для протокола SSH версии 1 и 2, и проверяют наличие публичных ключей в файле $HOME/.ssh/authorized_keys.

Проверьте наличие этих строк в файле конфигурации sshd_config (обычно он находится в каталоге /etc/ssh/), при необходимости добавьте и перезапустите сервис.

Содержимое файла authorized_keys

Файл authorized_keys просто содержит список ключей, по одному в строке. В него мы и пропишем ключ, сгенерированный нами на своей машине. Прядок действий следующий: копируем публичный ключ RSA на сервер, используя scp или любой другой способ. Создаем файл authorized_keys, если каталога .ssh не существует - создаем. Добавляем публичный ключ RSA в файл authorized_keys. Проверяем, устанавливаем права доступа и выходим.

Пришла пора проверить. что мы наваяли: Ваш SSH клиент будет сначала пробовать пройти аутентификацию по Pubkey/Identity, в случае неудачи - идентификацию по паролю. Он будет искать три имени файлов, заданных по умолчанию, если Вы не указали айл ключа явно и передаст его серверу.

Рассмотрим процесс подключения по разделениям: Все это проходит незаметно для пользователя. Если Вы хотите наблюдать за фазами соединения, то используйте ключ -v: Для наглядности, в этом примере мы вводим неправильное кодовое слово для дешифровки приватного ключа. Также Вы можете заметить, что были найдены файлы identity и id_rsa, хотя они могут использоваться только с SSHv2.

Выбор ключей

Если Вы имеете один ключ для каждого типа, то вы можете использовать стандартные имена файлов и ssh-клиент самостоятельно найдет их и использует, но может так случиться, что Вы используете для аутентификации разные файлы: Определить используемый ключ можно с помощью опции -i private_key_file: Следущая опция создаст в Вашем ~/.ssh/config указание на отображение еспользуемого ключа: Обратите внимание, что переменная config всегда равна IdentityFile, независимо от того, используется Pubkey или Identity.

Безопасность кодовой фразы

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

authorized_keys2

Старые версии OpenSSH использовали два различных публичных ключа для доступа к серверу - authorized_keys для Identities (SSHv1) и authorized_keys2 для Pubkeys (SSHv2). Позже было решено, что это глупо и теперь используется один файл для ключей всех типов, но при отсутствии подходящего ключа будет проверен и authorized_keys2. Более поздние версии OpenSSH могут вполне прекратить поддерживать authorized_keys2 вовсе.

Чтобы не думать об этом ограничении, создадим жесткую ссылку authorized_keys2 на файл authorized_keys. Так мы удовлетворим потребности любой версии OpenSSH.

<< Предыдущая ИНДЕКС Правка src / Печать Следующая >>

Обсуждение [ Линейный режим | Показать все | RSS ]
  • 1.1, gentoid (?), 15:45, 30/05/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Просто и понятно.
     
  • 1.2, debianid (?), 14:50, 10/01/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Спасибо!
     
  • 1.3, sorron (?), 22:37, 17/05/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    В первой таблице неправильно проставлены два последних примера заголовка
     
  • 1.4, betep (?), 12:55, 10/03/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    nice
     
  • 1.5, антон (??), 13:51, 29/08/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    статья очень полезная
    спасибо
     
  • 1.6, Андрей (??), 18:25, 19/09/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    доступно, просто и понятно
    +1
     
  • 1.7, ЮКЕЙЯЮМДП (?), 14:36, 03/04/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    ЛМЕ ОПХЬЕК РЕЙЯР  invalid command                    ВРН ЩРН РЮЙНЕ Х ЙЮЙ ЛМЕ ХЯОПЮБХРЭ ЩРН
     
  • 1.8, ilsid (??), 15:52, 19/09/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Вопрос касательно пункта
    "Если расшифровка удалась, то сервер пускает клиента без запроса пароля Unix".

    Каким образом сервер "понимает", что расшифровка удалась? Клиент отсылает ему дешифрованную проверочную строку в открытом виде? Ведь у сервера нет же закрытого ключа для дешифрации.

    Спасибо

     
     
  • 2.13, Вася (??), 22:17, 12/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >Ведь у сервера нет же закрытого
    > ключа для дешифрации.

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

    > Вопрос касательно пункта
    > "Если расшифровка удалась, то сервер пускает клиента без запроса пароля Unix".
    > Каким образом сервер "понимает", что расшифровка удалась? Клиент отсылает ему
    > дешифрованную проверочную строку в открытом виде?

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

     
     
  • 3.24, Васькович (ok), 14:17, 23/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Убить тебя мало! Публичный ключ, потому и публичный, что им можно только шифровать! Дешифровать можно только приватным!
     
     
  • 4.25, Lanched (?), 15:04, 23/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Убить тебя мало! Публичный ключ, потому и публичный, что им можно только
    > шифровать! Дешифровать можно только приватным!

    эм... вообще-то то, что зашифровано публичным, можно расшифровать только приватным. а то, что зашифровано приватным - можно расшифровать только публичным.

     
     
  • 5.26, Васькович (ok), 17:20, 23/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > эм... вообще-то то, что зашифровано публичным, можно расшифровать только приватным. а то,
    > что зашифровано приватным - можно расшифровать только публичным.

    Прекрасно! Шифруйте приватным, чтобы все прочитали. Смысл сего действа?

     
     
  • 6.27, Васькович (ok), 19:03, 23/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    опровергну сам себя - сертификаты.

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

     
  • 6.28, Lanched (?), 19:04, 23/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    >> эм... вообще-то то, что зашифровано публичным, можно расшифровать только приватным. а то,
    >> что зашифровано приватным - можно расшифровать только публичным.
    > Прекрасно! Шифруйте приватным, чтобы все прочитали. Смысл сего действа?

    1. удостовериться в отправителе.
    2. шифруется обычно своим закрытым ключем и открытым ключем партнера. чтобы никто не послал ему сообщение, представляясь не тем, кем он является.

     
     
  • 7.29, Васькович (ok), 20:56, 23/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    вы говорите про подписывание - это отдельный частный случай сертификации. и прошу не путать открытый/закрытый и частный/публичный. частный/публичный относятся строго к стандартной форме обмена: частный дешифрует и держится закрыто, публичный шифрует и дается в свободный доступ между партнерами.
     

  • 1.9, alecs (??), 23:26, 12/12/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Клиент расшифровывает посланную последовательность для подтверждения правильности публичного и приватного ключей

    Так как всё-таки проверяется подлинность private key ?

     
     
  • 2.12, Вася (??), 21:38, 12/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Общая идея такая:
    твой комп зашифровывает некоторую строку своим приватным ключом (который лежит у тебя на компе и ты его никогда никому не показываешь) и результат отправляет компу, с которым ты пытаешься начать ssh-сессию.
    На том компе уже есть (ты сам его туда положил) твой паблик-ключ.Тот комп берет этот ключ и расшифровывает им твое сообщение. Если расшифровалось - значит, твоя идентичность подтверждена: фокус в том, что пара ключей приват и паблик устроена так, что зашифрованное с помощью приват можно расшифровать с помощью соответствующего паблик - но при этом по паблику восстановить сам приват-кей очень и очень сложно.
    В общем, на том компе - ТОЛЬКО паблик-ключ. И твой приват-ключ он проверяет, не зная вообще, какое конкретное значение у привата: если твоим пабликом расшифровалось то, что ты зашифровал приватом - значит, твой приват и тот паблик, что ты закинул на удаленный комп - это "половинки" одного ключа, то есть, твой приват-ключ верный и с тобой можно начинать ssh
     

  • 1.10, zloyded (?), 08:46, 21/01/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    а если много серверов, как бы так заставить их все разом доверять хосту?
    у меня порядка 300 серверов, сразу их не заставили, а теперь это переодически не обходимо. например для одной короткой операци мне приходтся 300 раз вводить пароль...
     
     
  • 2.11, id_rsa (?), 06:18, 31/01/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > а если много серверов, как бы так заставить их все разом доверять
    > хосту?
    > у меня порядка 300 серверов, сразу их не заставили, а теперь это
    > переодически необходимо. например, для одной короткой операци мне приходтся 300
    > раз вводить пароль...

    while read server; do cat $HOME/.ssh/id_rsa.pub | ssh username@${server} \'cat >> ~/.ssh/authorized_keys\' ; done < server_list
    как-то так, по-моему. Уж придется последний раз напрячься и ввести 300 паролей, лол.

     
  • 2.14, Lanched (?), 11:16, 24/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    ssh-copy-id вам в руки :) один раз ввести пароли.. а если пароль везде одинаковый - то в связке с sshpass. тогда его вообще один раз ввести - и всё.
     

  • 1.15, Дмитрий (??), 13:50, 20/10/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    у меня при каждом входе по ssh просит  Enter passphrase for key
    можно ли как-то этого избежать, поскольку не удобно постоянно его вводить
     
     
  • 2.16, Lanched (?), 13:53, 20/10/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > у меня при каждом входе по ssh просит  Enter passphrase for
    > key
    > можно ли как-то этого избежать, поскольку не удобно постоянно его вводить

    можно. пересохрани ключ без использования пасс-фразы.

     
  • 2.22, Pilat (ok), 11:08, 06/04/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Использовать ssh-add.
    PS
    Я знаю, Что это старое сообщение.
     
  • 2.31, jzyken (?), 14:49, 04/01/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Чтобы не спрашивал каждый раз, нужно ваш ключ показать ssh агенту:
    ssh-add ~/.ssh/id_rsa
     

  • 1.17, Дмитрий (??), 14:15, 20/10/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Спасибо за быстрый ответ.
    пересохранить это ssh-keygen -t rsa
    только уже без passphrase?
    Но тогда мне понадобиться переписать ключ и в  authorized_keys на клиенте?
     
  • 1.18, Дмитрий (??), 14:58, 20/10/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    ssh-keygen -p -P old_passphrase -N “” -f .ssh/id_rs
    попытался сделать так, но passphrase все равно просит, только теперь не подходит старая фраза,и  без неё тоже не коннектится  
     
  • 1.19, Дмитрий (??), 15:06, 20/10/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    ой, извиняюсь, в предыдущей строке была ошибка с кавычками
    ssh-keygen -p -P old_passphrase -N "" -f .ssh/id_rs
    вот так работает, может кому полезно будет, избавиться от passphrase
     
  • 1.20, Сергей (??), 17:22, 19/08/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А есть ли сроки у этого ключа? В течении какого промежутка времени он будет действовать?
     
  • 1.21, Андрей (??), 10:38, 24/08/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Вопрос от чайника.Захожу на сайт он мне даёт rsa key.Как я могу им воспользоватса?
     
  • 1.23, имя (?), 23:57, 17/05/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Авторизацию для root настроил. А вот для пользователя bitrix сделал тоже самое, но пароль запрашивается. Может что-то надо иначе делать?
     
  • 1.30, Васькович (ok), 21:01, 23/09/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    В статье криво описан метод подсоединения. Вот как он выглядит правильно:

    клиент (ssh) соединяется с сервером (sshd) на порт сервера (22/SSH).

    сервер отвечает версией поддерживаемого протокола, по которой отвечает клиент.

    сервер отсылает клиенту свой публичный ключ открыто(1), либо посылает подписанный сертификат(2)

    клиент либо (1) проверяет присланный публичный ключ сервера, либо (2) контактирует 3тю сторону подписавшую сертификат, получает от неё публичный ключ для дешифровки сертификата, дешифрует сертификат - получая публичный ключ сервера и служебную информацию (хэш подпись публичного ключа сервера, также зашифрованную частным ключем 3й стороны) - и сверяет последние, чтобы убедится в аутентичности присланного публичного ключа.

    используя полученный публичный ключ сервера, клиент и сервер с помощью алгоримта Diffie-Hellman получают общий сессионый ключ, на котором строится дальнейший обмен. сессионный ключ и шифрование канала ничего общего с ассиметричными ключами не имеют.

    если сессия наладилась, то клиент шифрует и отсылает логин учетки и ID пары ключей, которые он хочет использовать.

    сервер декодирует присланное сообщение своим частным ключем сервера и проверяет файл authorized_keys на ID указанной учетки.

    если запись присутствует, сервер шифрует произвольное число (ПЧ, rnd) указанным там публичным ключем клиента и отсылает это клиенту.

    клиент дешифрует сообщение используя свой частный ключ, получая ПЧ у себя.

    клиент комбинирует ПЧ с сессионным ключем и просчитывает с них (md5 или подобные разрешенные хэш функции) хэш.

    клиент отсылает полученный хэш на сервер.

    сервер проделывает то же самое - но у себя, и сравнивает свой хэш с полученным хэшем от клиента.

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

     

     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:




    Спонсоры:
    Слёрм
    Inferno Solutions
    Hosting by Ihor
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2019 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру