Может кто то максимально детально объяснить как работает ssh авторизация по ключам

Ман асинхронное шифрование. Асили и Боб расскажут тебе, каково отправлять сундуки по почте.

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

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

1. да

2. по умолчанию, но можно явно указать клиенту SSH, какой файл использовать

3. наличие открытого ключа в authorized_keys сервера - указание давать доступ тому клиенту, у которого есть соответствующий приватный ключ. Логика подсказывает, что можно сгенерировать разные публичные ключи по одному приватному, но зачем - хз.

4. вопрос непонятен. Если интересует точная последовательность действий - запусти какое-нибудь ssh-соединение с ключом -v

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

6. я глупое поне и могу врать в любом из пунктов.

Всё с точностью до наоборот. Пара ключей генерируется на клиенте, затем публичный ключ закидывается на сервер. Сервер шифрует челлендж с помощью публичного ключа, таком образом клиент может его расшифровать. А не наоборот. Для каждого юзера генерируется своя пара ключей. Все публичные от них точно так же закидываются на сервер.

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

Посылаемые данные шифруются с публичным ключом. Расшифровать их можно лишь с помощью приватного ключа. Не наоборот, блин. Толку от шифрования, если любой обладатель публичного ключа мог бы расшифровать данные, лол?

Хзлол, я думал, сервер шлёт клиенту рандом, клиент подписывает его приватным ключиком, сервер проверяет подпись с помощью публичного.

как-то так

асимметричное

ftfy

Логика подсказывает, что можно сгенерировать разные публичные ключи по одному приватному, но зачем - хз.

В RSA, например, приватный ключ это числа n и d, а публичный n и e. Здесь, вроде, нельзя иметь больше одного публичного ключа, из-за требования взаимной простоты.

SO говорит, что с точки зрения безопасности так делать нельзя, с точки зрения математики - можно. В любом случае, я проверил - openssl генерирует одинаковый публичный ключ при разных прогонах, так что практическое применение этого знания весьма сомнительно.

1. Да, пароль нужен чтобы не спёрли твой приватный ключ.
2. Это настраивается
3. В authorized_keys ты заранее кладёшь публичные ключи пользователей, которые будут логиниться в этот аккаунт.
4. При подключении ты указываешь какой приватный ключ использовать для того публичного который ты ранее закинул в authorized_keys. Если он зашифрован, то вводишь от него пароль (или используешь ssh-agent который закеширует пароль).
5. Ничего никуда не отправляется. Удалённый комп использует ранее закинутый публичный ключ из authorized_keys. Если он не подойдёт к закрытому ключу (не получится расшифровать), то будет облом.
6. Есть возможность после логина пробросить свой приватный ключ, чтобы с удалённого аккаунта логиниться дальше. Например чтобы коммитить с удалённого сервака в гит.

Можно ссылку? Я нашёл эту, но здесь наоборот множество приватных ключей.

idk lol

http://bog.pp.ru/work/ssh.html

Храню это в закладках. Нифига не помню, но раз лежит, значит очень помогло когда настраивал себе.