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

Ссылка на текст статьи: http://www.opennet.me/base/sec/ssh_pubkey_auth.txt.html

• Аутентификация на SSH сервере с использованием ключей (ssh auth pam),gentoid, 15:45 , 30-Май-09
• Аутентификация на SSH сервере с использованием ключей (ssh a...,debianid, 14:50 , 10-Янв-10
• Аутентификация на SSH сервере с использованием ключей (ssh auth pam),sorron, 22:37 , 17-Май-10
• Аутентификация на SSH сервере с использованием ключей (ssh auth pam),betep, 12:55 , 10-Мрт-11
• Аутентификация на SSH сервере с использованием ключей (ssh a...,антон, 13:51 , 29-Авг-11
• Аутентификация на SSH сервере с использованием ключей (ssh auth pam),Андрей, 18:25 , 19-Сен-11
• юСРЕМРХТХЙЮЖХЪ МЮ SSH ЯЕПБЕПЕ Я ХЯОНКЭГНБЮМХЕЛ ЙКЧВЕИ (ssh auth pam),ЮКЕЙЯЮМДП, 14:36 , 03-Апр-12
• Аутентификация на SSH сервере с использованием ключей (ssh auth pam),ilsid, 15:52 , 19-Сен-12
  • Аутентификация на SSH сервере с использованием ключей (ssh a...,Вася, 22:17 , 12-Мрт-13
    • Аутентификация на SSH сервере с использованием ключей (ssh a...,Васькович, 14:17 , 23-Сен-16
      • Аутентификация на SSH сервере с использованием ключей (ssh a...,Lanched, 15:04 , 23-Сен-16
        • Аутентификация на SSH сервере с использованием ключей (ssh a...,Васькович, 17:20 , 23-Сен-16
          • Аутентификация на SSH сервере с использованием ключей (ssh a...,Васькович, 19:03 , 23-Сен-16
          • Аутентификация на SSH сервере с использованием ключей (ssh a...,Lanched, 19:04 , 23-Сен-16
            • Аутентификация на SSH сервере с использованием ключей (ssh a...,Васькович, 20:56 , 23-Сен-16
• Аутентификация на SSH сервере с использованием ключей (ssh auth pam),alecs, 23:26 , 12-Дек-12
  • Аутентификация на SSH сервере с использованием ключей (ssh a...,Вася, 21:38 , 12-Мрт-13
• Аутентификация на SSH сервере с использованием ключей (ssh auth pam),zloyded, 08:46 , 21-Янв-13
  • Аутентификация на SSH сервере с использованием ключей (ssh a...,id_rsa, 06:18 , 31-Янв-13
  • Аутентификация на SSH сервере с использованием ключей (ssh a...,Lanched, 11:16 , 24-Янв-14
• Аутентификация на SSH сервере с использованием ключей (ssh auth pam),Дмитрий, 13:50 , 20-Окт-14
  • Аутентификация на SSH сервере с использованием ключей (ssh a...,Lanched, 13:53 , 20-Окт-14
  • Аутентификация на SSH сервере с использованием ключей (ssh a...,Pilat, 11:08 , 06-Апр-16
  • Аутентификация на SSH серh a..вере с использованием ключей (ss.,jzyken, 14:49 , 04-Янв-17
• Аутентификация на SSH сервере с использованием ключей (ssh auth pam),Дмитрий, 14:15 , 20-Окт-14
• Аутентификация на SSH сервере с использованием ключей (ssh a...,Дмитрий, 14:58 , 20-Окт-14
• Аутентификация на SSH сервере с использованием ключей (ssh auth pam),Дмитрий, 15:06 , 20-Окт-14
• Аутентификация на SSH сервере с использованием ключей (ssh auth pam),Сергей, 17:22 , 19-Авг-15
• Аутентификация на SSH сервере с использованием ключей (ssh auth pam),Андрей, 10:38 , 24-Авг-15
• Аутентификация на SSH сервере с использованием ключей (ssh auth pam),имя, 23:57 , 17-Май-16
• процесс аутентификации,Васькович, 21:01 , 23-Сен-16

Просто и понятно.

Спасибо!

В первой таблице неправильно проставлены два последних примера заголовка

nice

статья очень полезная
спасибо

доступно, просто и понятно
+1

ЛМЕ ОПХЬЕК РЕЙЯР  invalid command                    ВРН ЩРН РЮЙНЕ Х ЙЮЙ ЛМЕ ХЯОПЮБХРЭ ЩРН

Вопрос касательно пункта
"Если расшифровка удалась, то сервер пускает клиента без запроса пароля Unix".

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

Спасибо

>Ведь у сервера нет же закрытого
> ключа для дешифрации.

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

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

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

Убить тебя мало! Публичный ключ, потому и публичный, что им можно только шифровать! Дешифровать можно только приватным!

> Убить тебя мало! Публичный ключ, потому и публичный, что им можно только
> шифровать! Дешифровать можно только приватным!

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

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

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

опровергну сам себя - сертификаты.

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

>> эм... вообще-то то, что зашифровано публичным, можно расшифровать только приватным. а то,
>> что зашифровано приватным - можно расшифровать только публичным.
> Прекрасно! Шифруйте приватным, чтобы все прочитали. Смысл сего действа?

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

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

Клиент расшифровывает посланную последовательность для подтверждения правильности публичного и приватного ключей

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

Общая идея такая:
твой комп зашифровывает некоторую строку своим приватным ключом (который лежит у тебя на компе и ты его никогда никому не показываешь) и результат отправляет компу, с которым ты пытаешься начать ssh-сессию.
На том компе уже есть (ты сам его туда положил) твой паблик-ключ.Тот комп берет этот ключ и расшифровывает им твое сообщение. Если расшифровалось - значит, твоя идентичность подтверждена: фокус в том, что пара ключей приват и паблик устроена так, что зашифрованное с помощью приват можно расшифровать с помощью соответствующего паблик - но при этом по паблику восстановить сам приват-кей очень и очень сложно.
В общем, на том компе - ТОЛЬКО паблик-ключ. И твой приват-ключ он проверяет, не зная вообще, какое конкретное значение у привата: если твоим пабликом расшифровалось то, что ты зашифровал приватом - значит, твой приват и тот паблик, что ты закинул на удаленный комп - это "половинки" одного ключа, то есть, твой приват-ключ верный и с тобой можно начинать ssh

а если много серверов, как бы так заставить их все разом доверять хосту?
у меня порядка 300 серверов, сразу их не заставили, а теперь это переодически не обходимо. например для одной короткой операци мне приходтся 300 раз вводить пароль...

> а если много серверов, как бы так заставить их все разом доверять
> хосту?
> у меня порядка 300 серверов, сразу их не заставили, а теперь это
> переодически необходимо. например, для одной короткой операци мне приходтся 300
> раз вводить пароль...

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

ssh-copy-id вам в руки :) один раз ввести пароли.. а если пароль везде одинаковый - то в связке с sshpass. тогда его вообще один раз ввести - и всё.

у меня при каждом входе по ssh просит  Enter passphrase for key
можно ли как-то этого избежать, поскольку не удобно постоянно его вводить

> у меня при каждом входе по ssh просит  Enter passphrase for
> key
> можно ли как-то этого избежать, поскольку не удобно постоянно его вводить

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

Использовать ssh-add.
PS
Я знаю, Что это старое сообщение.

Чтобы не спрашивал каждый раз, нужно ваш ключ показать ssh агенту:
ssh-add ~/.ssh/id_rsa

Спасибо за быстрый ответ.
пересохранить это ssh-keygen -t rsa
только уже без passphrase?
Но тогда мне понадобиться переписать ключ и в  authorized_keys на клиенте?

ssh-keygen -p -P old_passphrase -N “” -f .ssh/id_rs
попытался сделать так, но passphrase все равно просит, только теперь не подходит старая фраза,и  без неё тоже не коннектится  

ой, извиняюсь, в предыдущей строке была ошибка с кавычками
ssh-keygen -p -P old_passphrase -N "" -f .ssh/id_rs
вот так работает, может кому полезно будет, избавиться от passphrase

А есть ли сроки у этого ключа? В течении какого промежутка времени он будет действовать?

Вопрос от чайника.Захожу на сайт он мне даёт rsa key.Как я могу им воспользоватса?

Авторизацию для root настроил. А вот для пользователя bitrix сделал тоже самое, но пароль запрашивается. Может что-то надо иначе делать?

В статье криво описан метод подсоединения. Вот как он выглядит правильно:

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

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

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

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

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

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

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

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

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

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

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

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

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