Аутентификация на основе ключей SSH: известные_хосты против авторизованных

Я прочитал о настройке ключей SSH в Linux и у меня есть несколько вопросов. Поправьте меня если я ошибаюсь…

Допустим, хост tr-lgto хочет подключиться к хосту tr-mdm с помощью ssh. Если мы хотим быть уверены, что это настоящий tr-mdm, мы генерируем пару ключей в tr-mdm и добавляем открытый ключ в known_hoststr-lgto. Если tr-mdm хочет проверить, что это настоящий tr-lgto, то tr-lgto должен сгенерировать пару ключей и добавить открытый ключ в authorized_keystr-mdm.

Вопрос 1 : В файле known_hosts нет поля пользователя , только IP-адреса и имена хостов. У tr-mdm может быть много пользователей, каждый со своей .sshпапкой. Должны ли мы добавить открытый ключ к каждому из known_hostsфайлов?

Вопрос 2 : Я обнаружил, что ssh-keyscan -t rsa tr-mdmверну открытый ключ tr-mdm. Как узнать, к какому пользователю принадлежит этот ключ? Более того, открытый ключ /root/.ssh/отличается от того, что возвращает эта команда. Как это может быть?

ssh security openssh key-authentication damluar
источник

Аналогичный вопрос по информационной безопасности : в чем разница между файл author_key и known_host для SSH?

Жиль "ТАК - перестать быть злым"

Я добавил некоторый фоновый контекст для 'ssh' в ответ "О безопасных файлах, содержащих открытые ключи" на вопрос, упомянутый @Gilles: < security.stackexchange.com/questions/20706/… >

IAM_AL_X

Вы смешиваете аутентификацию сервера с клиентским компьютером и аутентификацию пользователя с сервером.

Проверка подлинности сервера

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

Клиент может проверить, что сервер известен, а не какой-то мошеннический сервер, пытающийся выдать себя за правильный. SSH предоставляет только простой механизм проверки легитимности сервера: он запоминает серверы, к которым вы уже подключены, в ~/.ssh/known_hostsфайле на клиентском компьютере (есть также файл всей системы /etc/ssh/known_hosts). При первом подключении к серверу необходимо проверить каким-либо другим способом, что открытый ключ, представленный сервером, действительно является открытым ключом сервера, к которому вы хотите подключиться. Если у вас есть открытый ключ сервера, к которому вы собираетесь подключиться, вы можете добавить его ~/.ssh/known_hostsна клиенте вручную.

Аутентификация сервера должна быть выполнена до того, как вы отправите на него какие-либо конфиденциальные данные. В частности, если аутентификация пользователя включает в себя пароль, пароль не должен отправляться на неаутентифицированный сервер.

Аутентификация пользователя

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

Пользователь может предоставить пароль для учетной записи, в которую он пытается войти; Затем сервер проверяет, что пароль правильный.
Пользователь может представить открытый ключ и доказать, что он обладает закрытым ключом, связанным с этим открытым ключом. Это точно такой же метод, который используется для аутентификации сервера, но теперь пользователь пытается подтвердить свою личность, а сервер проверяет их. Попытка входа в систему принимается, если пользователь подтверждает, что знает закрытый ключ, а открытый ключ находится в списке авторизации учетной записи ( ~/.ssh/authorized_keysна сервере).
Другой тип метода включает делегирование части работы аутентификации пользователя клиентскому компьютеру. Это происходит в контролируемых средах, таких как предприятия, когда многие машины используют одни и те же учетные записи. Сервер аутентифицирует клиентский компьютер с помощью того же механизма, который используется наоборот, а затем полагается на клиента для аутентификации пользователя.

Жиль "ТАК - перестань быть злым"
источник

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

Алекс

@spartacus Я думаю, вы имели в виду «и докажите, что у него есть связанный закрытый ключ», верно? Идея состоит в том, что клиент отправляет случайно сгенерированное значение ( запрос ) на сервер, а сервер выполняет некоторые вычисления на основе закрытого ключа, который зависит от запроса (поэтому сервер не может выполнить вычисление, пока не получит это вызов), и это может быть сделано только с знанием частного ключа.

Жиль "ТАК - перестань быть злым"

Я думаю, что Алекс имеет в виду первый раз, когда клиент подключается к серверу. Я думаю, что клиент будет доверять серверу в первый раз. Затем сервер отправит свой открытый ключ, и клиент сможет аутентифицировать сервер для следующих подключений.

Синак

@Synack Ах, в первый раз? Скорее всего, клиент принимает решение от пользователя («Вы уверены, что хотите продолжить соединение (да / нет)?»). Сервер ничего не доказывает в этот момент.

Жиль "ТАК - перестань быть злым"

Вы правы, это пользователь, который принимает решение.

Синак

Аутентификация на основе ключей SSH: известные_хосты против авторизованных_ключей

Ответы:

Проверка подлинности сервера

Аутентификация пользователя