ВНИМАНИЕ -> Будьте внимательны при чтении этого описания проблемы. Когда я писал этот вопрос, у меня были некоторые предположения, которые были неверными. Убедитесь, что вы прочитали мой ответ, объясняющий, в чем я ошибся!
У меня есть хост A в AWS в качестве экземпляра EC2.
Я - закрытый ключ, встроенный в файл .PEM, который я могу использовать для хоста A с ключом SSH Z. Это работает, если я передаю его команде ssh с помощью -l аргумент, И если я отключу строгую проверку хоста с помощью -o StrictHostKeyChecking=no.
Я бы очень предпочел оставить строгую проверку хоста, даже если я «знаю», что это правильный хост, потому что я взаимодействую с интерфейсом AWS, получаю от них ip / dns, и я нахожусь в своем собственном маленьком мире VPC. .
Похоже, что единственный способ предоставить отображение отпечатка пальца -> хост - это указать его в known_hosts файл.
Это правильно?
Если это верно, как я могу взять закрытый ключ, встроенный в файл .PEM, который у меня есть, из AWS, и создать правильную запись для одного отпечатка пальца -> сопоставление хоста для временного known_hosts файл, который я могу прочитать при входе в экземпляр EC2?
ssh-keyscan. Все это слепо принимает отпечаток пальца удаленного клиента, не проверяя, соответствует ли он ключу. Думаю?StrictHostKeyChecking. Я хочу внедрить передовой опыт как можно раньше, и мне нужно знать, как это сделать сейчас, потому что мне нужно будет знать, как это делать в целом. (По this Я имею в виду, как использовать отпечатки пальцев SSH для проверки подлинности хоста, к которому я подключаюсь, на основе ключа, который у меня есть.)ssh-add. Я хочу записать это в файл, к которому легко заблокировать доступ, а не помещать его в запущенный процесс.РЕДАКТИРОВАТЬ: как ни странно, когда я пытаюсь извлечь отпечаток пальца из файла pem, он не соответствует отпечатку пальца, который я вижу при подключении, и он запрашивает меня.
Удаление отпечатков пальцев из PEM
bash-4.2$ ssh-keygen -l -E md5 -f ./blah.PEM
2048 MD5:be:b1:d7:e1:f0:0f:ce:41:60:fa:97:dc:b8:2c:ed:08 no comment (RSA)
bash-4.2$ ssh-keygen -l -E sha1 -f ./blah.PEM
2048 SHA1:g2PDmIcw19Z/v7HTco6xRWxQ88c no comment (RSA)
ОТОБРАЖЕНИЕ ОТПЕЧАТКА ПАЛЬЦА ВО ВРЕМЯ ЗАПРОСЫ SSH
bash-4.2$ ssh -i ./blah.PEM ubuntu@ip-172-31-6-91.us-east-2.compute.internal
The authenticity of host 'ip-172-31-6-91.us-east-2.compute.internal (172.31.6.91)' can't be established.
ECDSA key fingerprint is SHA256:ibwhkrF5oMapJla4cKuXgePT5lHmg08L7yMp6auCpgo.
ECDSA key fingerprint is MD5:ba:82:53:ee:89:22:26:63:26:11:21:93:63:1f:1d:d1.
Как отпечатки пальцев могут отличаться, но ключ все равно позволяет мне подключиться?
У вас есть две пары ключей:
У демона ssh на сервере есть набор закрытых ключей, созданных и хранящихся в /etc/ssh/ папка
Отпечаток RSA, который вы получаете с сервера, исходит из открытого ключа, соответствующего /etc/ssh/ssh_host_rsa_key закрытый ключ
Это ваша пара ключей. Закрытый ключ должен надежно храниться на вашем компьютере и использоваться для аутентификации на сервере. Открытый ключ находится на сервере в файле authorized_keys вашего профиля: ~/.ssh/authorized_keys
Таким образом, существует 2 разных открытых ключа, и их отпечатки не будут совпадать, если вы не используете тот же закрытый ключ, что и на сервере, что маловероятно.
Чтобы избавиться от предупреждения, сделайте так, как его просили: поместите отпечаток сервера в /var/lib/jenkins/.ssh/known_hosts файл.
Если я правильно вас понял, файл закрытого ключа находится в вашем распоряжении, и вы хотите получить его отпечаток, чтобы добавить его в свой known_hosts файл. Если это так, то вот что вы делаете:
$ ssh-keygen -yf /path_to_private_key/key_file_name
Это выведет что-то вроде:
ssh-rsa AAAAB3NzaC....
Наконец, добавьте к нему префикс IP-адреса, к которому вы используете SSH, чтобы у вас было следующее:
10.200.25.5 ssh-rsa AAAAB3NzaC....
и вы можете добавить это как строку в свой known_hosts файл.
Мое замешательство заключалось в том, что я думал, что у меня точно такая же пара закрытого и открытого ключей, что и на сервере. Вместо этого происходит следующее: когда я создаю пару ключей и назначаю ее новому экземпляру EC2, экземпляр EC2 получает открытый ключ этой пары, помещенный в его authorized_keys, что позволяет мне подключиться к нему с помощью закрытого ключа, который я загружаю при создании пара в AWS.
Я могу использовать команду fingerprinting, поставляемую с AWS, но это хорошо только для проверки того, что мой закрытый ключ совпадает с открытым ключом, который они сохранили, и помещает его в authorized_keys.
Каждый раз, когда появляется новый экземпляр EC2, он генерирует набор собственных закрытых / открытых ключей для различных алгоритмов, таких как RSA и DSA. Теперь я должен очистить журналы, чтобы получить отпечатки этих ключей, чтобы я мог проверить, соответствуют ли они хосту, к которому я подключаюсь.
Итак, шаги такие.
Имейте в виду, что жизненно важная проблема здесь заключается в том, что вы не можете быть уверены, что хост, к которому вы подключаетесь, не находится в центре атаки. Если вы вслепую примете ключ, не подтвердив его отпечаток пальца на шаге 4, возможно, вы не подключаетесь к серверу, на котором рассчитываете. Проверяя на шаге 4, вы знаете, что ваше соединение безопасно (из-за криптографии SSH), но, что очень важно, вы также знаете, к кому вы подключены, потому что только один человек будет иметь отпечаток пары ключей, соответствующий тому, который вы ожидаете.
РЕДАКТИРОВАТЬ: команда get-console-output не надежна для автоматизации. Он предназначен ТОЛЬКО для специального поиска и устранения неисправностей. Основная проблема заключается в том, что AWS будет произвольно вырезать части выхода из системы и / или буферизовать его таким образом, что вам придется долго ждать, чтобы увидеть полную запись.
Вместо этого я пытаюсь загрузить ключи в сценарий пользовательских данных, выключить систему, очистить сценарий пользовательских данных, чтобы он был недоступен (потому что в нем есть закрытый ключ), а затем снова запустить экземпляр. Мне все равно нужно перезагрузить его, потому что для обновленных пакетов может потребоваться перезагрузка, поэтому я могу убить двух зайцев здесь.