Разница между входом в систему с использованием открытых / закрытых ключей и сертификатами в ssh
Я пытаюсь установить разницу между двумя процедурами, которые я использую для установления ssh-соединений.
В первой последовательности команд, которые я выполняю:
ssh-keygen -t rsa
ssh-copy-id user@ip
ssh user@ip
Я считаю, что это соответствует аутентификации с открытым / закрытым ключом на сервере. Я думаю, что это уязвимо для атак типа "злоумышленник посередине".
Остальные последовательности выглядят следующим образом:
ssh-keygen -t rsa
cat /home/login_server/.ssh/id_rsa.pub >> /home/login_server/.ssh/authorized_keys
ssh -i ~/.ssh/id_rsa user@ip -o VisualHostKey=yes
Я думаю, что вторая команда - это то, что, по сути, делает команда ssh-copy-id. Однако опция -i сообщает, где найти закрытый ключ, чего я раньше не делал. Могу ли я предположить, что это сертифицированная версия вышеперечисленного?
I believe this corresponds to a public/private key authentication with the server.
Выполняется одна аутентификация по паролю и одна аутентификация по открытому ключу.
I think this is vulnerable to man-in-the-middle attacks.
Если правильно проверить ключ хоста, он не будет уязвим для MitM.
I think the second command is what essentially the command ssh-copy-id does.
Да, но ssh-copy-idтакже выполняет другие проверки, чтобы убедиться, что разрешения и контексты selinux верны. Также он делает это по сети и использует аутентификацию password.
The option -i tells however where to find a private key which I didn't do before.
Да. Но /home/login_server/.ssh/id_rsaпо умолчанию.
Can I assume that this is a certified version of the above?
Нет. Это просто копирование файлов. Если домашний каталог монтируется каким-либо другим методом (NFS, Samba или опять же sshfs), вы полагаетесь на безопасность этих протоколов. Сертификаты — это нечто другое, как описано, например, здесь:
Оба подхода, которые вы используете, похожи и используют одни и те же механизмы аутентификации. Конкретные различия:
ssh-copy-id user@ipскопирует все локальные ключи, которые еще не авторизованы наuser@ip, в целевую систему, тогда как ваша командаcatскопирует только ключ, который вы только что создали;ssh user@ipпопытается использовать все доступные ключи аутентификации, тогда какssh -i...будет использовать только указанный ключ.
Проблемы с MITM связаны с ключами хоста, а не с вашими собственными ключами. Вот где VisualHostKeyпомогает, так как легче сравнивать (для нас, людей ). Но это не имеет ничего общего с различными механизмами аутентификации.
Обратите внимание, что SSH теперь также поддерживает сертификаты, но они принципиально другие :: вместо перечисления всех авторизованных ключей на каждом сервере вы настраиваете серверы так, чтобы они принимали ключи, подписанные данным центром сертификации.