Я прочитал о настройке ключей 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/отличается от того, что возвращает эта команда. Как это может быть?
решение1
Вы путаете аутентификацию сервера на клиентской машине и аутентификацию пользователя на серверной машине.
Аутентификация сервера
Одно из первых действий, которое происходит при установке SSH-соединения, заключается в том, что сервер отправляет свой открытый ключ клиенту и подтверждает (благодарякриптография с открытым ключом) клиенту, что он знает связанный с ним закрытый ключ. Это аутентифицирует сервер: если эта часть протокола успешна, клиент знает, что сервер — тот, за кого себя выдает.
Клиент может проверить, что сервер известен, а не какой-то мошеннический сервер, пытающийся выдать себя за правильный. SSH предоставляет только простой механизм для проверки легитимности сервера: он запоминает серверы, к которым вы уже подключались, в файле ~/.ssh/known_hostsна клиентской машине (есть также общесистемный файл /etc/ssh/known_hosts). Когда вы подключаетесь к серверу в первый раз, вам нужно проверить другими способами, что открытый ключ, представленный сервером, действительно является открытым ключом сервера, к которому вы хотите подключиться. Если у вас есть открытый ключ сервера, к которому вы собираетесь подключиться, вы можете добавить его ~/.ssh/known_hostsна клиенте вручную.
Аутентификация сервера должна быть выполнена до отправки на него любых конфиденциальных данных. В частности, если аутентификация пользователя включает пароль, пароль не должен быть отправлен на неаутентифицированный сервер.
Аутентификация пользователя
Сервер позволяет удаленному пользователю войти в систему только в том случае, если этот пользователь может доказать, что у него есть право доступа к этой учетной записи. В зависимости от конфигурации сервера и выбора пользователя, пользователь может предоставить одну из нескольких форм учетных данных (список ниже не является исчерпывающим).
- Пользователь может ввести пароль для учетной записи, в которую он пытается войти; затем сервер проверяет правильность пароля.
- Пользователь может предоставить открытый ключ и доказать, что он владеет закрытым ключом, связанным с этим открытым ключом. Это точно такой же метод, который используется для аутентификации сервера, но теперь пользователь пытается доказать свою личность, а сервер проверяет его. Попытка входа принимается, если пользователь доказывает, что он знает закрытый ключ, а открытый ключ находится в списке авторизации учетной записи (
~/.ssh/authorized_keysна сервере). - Другой тип метода предполагает делегирование части работы по аутентификации пользователя клиентской машине. Это происходит в контролируемых средах, таких как предприятия, когда многие машины используют одни и те же учетные записи. Сервер аутентифицирует клиентскую машину тем же механизмом, который используется наоборот, а затем полагается на клиента для аутентификации пользователя.
решение2
Мои друзья дали мне ответ. По умолчанию key идентифицирует машину, а не пользователя. Поэтому ключи хранятся в /etc/ssh/. Вот почему я получил другой ключ, нежели тот, что хранится в /root/.ssh