Это кажется слишком простым, и мне кажется, что я упустил что-то очевидное, но что на самом деле происходит, когда вы используете SSH без генерации пары ключей?
Вариант этого вопроса был заданздесьи как и в ответе, я всегда понимал, что без пары ключей SSH возвращается к аутентификации по паролю.
ОднакоСтатья в Википедииописывает только два способа его использования. Оба, похоже, используют пары ключей, один сгенерированный вручную, а другой автоматически.
Существует несколько способов использования SSH. Один из них — использовать автоматически сгенерированные пары открытого и закрытого ключей для простого шифрования сетевого соединения, а затем использовать аутентификацию по паролю для входа в систему.
Другой способ — использовать вручную сгенерированную пару открытого и закрытого ключей для выполнения аутентификации, что позволяет пользователям или программам входить в систему без указания пароля.
Когда я создаю SSH-подключение к незащищенному серверу без пары ключей, мне предлагается ввести имя пользователя и пароль, после чего я получаю доступ к оболочке.
Является ли резервный пароль деталью реализации и поэтому не представлен в вики? Была ли автоматически сгенерирована пара ключей, как предполагалось (если да, то как открытый ключ попал на сервер)? Или это происходит только с паролем.
Если используется только комбинация пароля и имени пользователя, шифруются ли данные вообще? Если да, то как они шифруются?
решение1
Статья в Википедии путает разные уровни SSHv2. (Возможно, это былов некотором роде(Правильно для SSHv1 десятилетней давности, но это определенно упрощено до уровня бессмыслицы.)
Пары ключей SSHv2, как ваши, так и сервера, используются дляаутентификациятолько, и настройка шифрования всегда выполняется с использованием временно сгенерированных пар ключей DH для каждого соединения. Пара ключей SSH сервера толькознакиданные настройки шифрования (для подтверждения подлинности сервера), в то время как пара ключей SSH клиента для этого процесса вообще не используется.
В SSHv2 при подключении к серверу (после того, как обе стороны обменяются списками поддерживаемых алгоритмов) первым шагом являетсяобмен ключами, который каким-то образом генерирует симметричный ключ, используемый для шифрования всего соединения. (Сервер также аутентифицируется как побочный эффект этого процесса.)
Большую часть времениД–ХилиECDHдля этого будет использоваться, что означает:
Клиент генерирует пару ключей DH (используется только для этого соединения) и отправляет свой открытый ключ DH.
Сервер также генерирует новую пару ключей DH. Он также загружает свою пару ключей SSH "host key" с диска.
Затем этознакиоткрытый ключ DH с закрытым ключом SSH и отправляет оба открытых ключа (а также подпись) клиенту.
Клиент проверяет подпись и удостоверяется, что открытый ключ SSH сервера находится в known_hosts.
Затем он использует обаДХключи (личный клиентский + публичный серверный) для генерации общего ключа шифрования и выбрасывает свою пару ключей DH.
Сервер также использует оба ключа DH (личный ключ сервера и публичный ключ клиента) для генерации одного и того же общего ключа шифрования, а также выбрасывает свою пару ключей DH.
Обе стороны включают шифрование.
(Существуют и другие методы обмена ключами, но они используются редко.)
Следующий шаг —аутентификация клиента. Обратите внимание, что на этом этапе соединение уже зашифровано, хотя SSH-ключ клиента еще не использовался!
Клиент отправляет «запрос на обслуживание» для аутентификации клиента.
Сервер предлагает несколько механизмов – «пароль», «открытый ключ», возможно, другие.
Если у вас есть пара ключей SSH, клиент выбирает «открытый ключ», отправляет ваши открытые ключи SSH и использует ваш закрытый ключ SSH для подписи некоторых случайных данных, предоставленных сервером, чтобы подтвердить право собственности на ключ.
Если у вас нет пары ключей SSH, клиент выбирает «пароль» и отправляет ваш пароль напрямую, однако все еще внутри зашифрованного туннеля.