Что именно посылает ssh при согласовании ключей?

При явном указании файла идентификации в ssh:

ssh -i ./id_rsa ...

У меня есть эти строки в трассировке отладки ssh:

debug1: Offering public key: ./id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply

Означает ли это, что ssh-генерируется также id_rsaсодержит публичный показатель RSA? id_rsaФормат выглядит довольно явным, поскольку он содержит закрытый ключ со своим блоком «BEGIN PRIVATE KEY», поэтому «предложение открытого ключа» должно означать нечто иное, чем «отправка открытого ключа на сервер».

РЕДАКТИРОВАТЬ:

Чтобы уточнить, я хочу знать, что именно происходит за линией «предоставления открытого ключа». Если клиент имеет несколько ключей, все они будут предложены серверу один за другим.

ssh

— Алекс Б
источник

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

— Гопой

Ответы:

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

это делается путем копирования открытого ключа для вашего секретного ключа на сервер, и добавить его в ~/ssh/authorized_keysлибо копировать / вставить, копирование id_rsa.pubна ~/.ssh/authorized_keysна сервере или cat id_rsa.pub >> ~/.ssh/authorized_keys, добавив его в список.

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

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

НЕТ ТОЧКИ в обмене - ваш личный ключ или личный ключ хоста, которым вы обменивались или открывались друг другу. Ваш открытый ключ хранится на сервере, но именно поэтому он является ПУБЛИЧНЫМ ключом.

— cpbills
источник

Да, это все хорошо, но все это происходит до того, как сервер идентифицирует открытый ключ, с помощью которого можно зашифровать запрос. У меня есть несколько ключей, и все они «предлагаются» серверу один за другим. Что именно это влечет за собой? И да, я понимаю, что закрытый ключ на самом деле не отправлен, я, вероятно, должен удалить эту строку из вопроса в целом. : P

— Алекс Б

когда вы указываете, ssh -i keynameвы точно указываете своему клиенту ssh, какой ключ вы планируете использовать для подключения к серверу. если у вас есть дюжина ключей в ~/.ssh/вашем клиенте, НЕ будет перебирать каждый ключ. он будет искать ~/.ssh/id_rsa, ~/.ssh/id_dsaвозможно, несколько других имен файлов, которые закодированы в клиенте, или какой ключ указан для этого хоста в ~/.ssh/config... длинной истории; ваш клиент не / не предлагает / какие-либо ключи к серверу.

— cpbills

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

— cpbills

о, я перечитал ваш комментарий; хост: шифрует запрос с помощью ключа хоста, клиент: расшифровывает запрос с помощью ключа публикации хоста, клиент: шифрует запрос с помощью личного ключа, хост: пытается расшифровать вызов с помощью всех перечисленных открытых ключей в ~/.ssh/authorized_keysхосте, знает, что это за вызов, и что он ищет потому что, как только открытый ключ разблокирует его, он знает, как использовать этот ключ.

— cpbills

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

— Алекс Б

Криптография с открытым / закрытым ключом основана на очень простой системе:

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

Таким образом, ответ на ваш вопрос: «Ваш открытый ключ».

— Satanicpuppy
источник

Да, спасибо, я знаю подробно, как работает криптография с открытым ключом, но я хочу знать специфику протокола SSH и формат ключа. Мне интересно знать, хранит ли он открытый показатель степени в файле закрытого ключа или нет? Насколько я знаю, «предложение открытого ключа» также может означать подписание одноразового номера с вашим закрытым ключом, чтобы сервер мог найти соответствующий открытый ключ.

— Алекс Б

Да. он делает ssh-keygen -y даст вам открытый ключ закрытого ключа, обратное не работает

— Mâtt Frëëman

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

Я полагаю, что он говорит, Offering public key: ./id_rsaпотому что он использует закрытый ключ (хранящийся в ./id_rsa) для выполнения шифрования открытого текста, который известен серверу, а затем сервер будет использовать открытый ключ для дешифрования этого зашифрованного текста и подтверждения его соответствия открытому тексту. Файл открытого ключа ./id_rsa.pubникогда не должен понадобиться клиенту после первоначальной генерации ключа. Это используется только сервером для расшифровки.

— Трей Ханнер
источник

Я подозревал, что что-то подобное происходит, но я хотел кое-что конкретное (т.е. фактический протокол согласования ключей SSH). Не уверен, почему ты получил отрицательный голос.

— Алекс Б

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

— Трей Ханнер