Генерация пары закрытый+открытый ключ для SSH: разница между ssh-keygen и openssl?

Генерация пары закрытый+открытый ключ для SSH: разница между ssh-keygen и openssl?

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

Я не могу понять разницу между этим:

openssl genrsa -out MyPrivateKey 4096
openssl rsa -in MyPrivateKey -pubout -out MyPublicKey

который сначала создает закрытый ключ RSA, а затем извлекает из него открытый ключ, или:

ssh-keygen -b 4096 -t rsa -f MyFancyKey

который создает закрытый ключ RSA в файле «MyFancyKey» и соответствующий открытый ключ в «MyFancyKey.pub».

Структура закрытых ключей кажется несколько похожей, хотя тот, который создан, opensslначинается с:
-----BEGIN RSA PRIVATE KEY-----

А тот, что ssh-keygenначинается с:
-----BEGIN OPENSSH PRIVATE KEY-----

Есть ли принципиальная разница между этими двумя видами ключей?


Затем соответствующие открытые ключи, один из которых opensslсодержит:

-----BEGIN PUBLIC KEY-----
  ...base64 encoded...
-----BEGIN PUBLIC KEY-----

В то время как тот, что из ssh-keygenсодержит всего одну строку:
ssh-rsa XXXXXX...base64 encoded...XXXXX [email protected]

Это по сути один и тот же тип данных, но отформатированный по-разному? Или они действительно несовместимы?

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

решение1

Закрытые ключи

Есть ли принципиальная разница между этими двумя видами ключей?

Нет, по сути это одни и те же данные.

  • BEGIN RSA PRIVATE KEYуказывает на формат ключа "PKCS#1" или "PEM", который представляет собой кодировку Base64 сериализованной структуры ASN.1 DER. Это базовая последовательность ASN.1, содержащая параметры RSA (н,е,г,п,д, и т. д).

    Этот формат возник в результате усилий по обеспечению безопасности электронной почты PEM, который позже стал называться S/MIME (отсюда и использование ASN.1 DER) и широко использовался для SSL/TLS, а также для различных общих протоколов RSA.

    Долгое время он также был форматом первичного ключа OpenSSH (поскольку OpenSSH уже использует криптографический код OpenSSL, поэтому функции «загрузить ключ» и «записать ключ» также были удобно доступны). Это означает, что вы можете использовать ssh-keygen -m PEMдля генерации или преобразования таких ключей.

  • BEGIN PRIVATE KEYуказывает на формат ключа «PKCS#8» (незашифрованный); его содержимое очень похоже на формат PEM, с теми же параметрами RSA, вложенными в другую структуру, что указывает на то, что это действительно ключ RSA.

    PKCS#8 специально задуман как более современная замена формата PEM. По сравнению с PEM, формат PKCS#8 более четко отделяет «полезную нагрузку» (алгоритм ключа, шифрование) от внешней оболочки Base64 – все метаданные теперь находятся внутри структуры, поэтому их легче обновлять для новых типов ключей. Новый формат также поддерживает лучшие шифры и KDF для зашифрованных ключей.

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

  • BEGIN OPENSSH PRIVATE KEY— формат, изобретенный OpenSSH для OpenSSH, и в отличие от форматов PEM/PKCS, он использует сериализацию пакетов SSHv2 для своих структур данных (больше никаких DER или ASN.1).

    Одна из причин, по которой OpenSSH теперь использует этот формат, заключается в том, что он может полностью избежать зависимости от OpenSSL и/или может добавлять новые алгоритмы ключей, не дожидаясь, пока OpenSSL реализует загрузку/сохранение этих ключей, что также означает ожидание, пока PKIX стандартизирует ASN.1 OID и структуру для каждого нового алгоритма (который в противном случае не имеет абсолютно никакого отношения к SSH).

    Например, OpenSSL потребовалось некоторое время, чтобы получить полную поддержку Ed25519, в течение которого OpenSSH не мог ни использовать libcrypto OpenSSL для реальных математических вычислений, ни для загрузки/сохранения файлов ключей Ed25519 — именно это и побудило создать этот формат.

    Еще одним преимуществом формата OpenSSH является то, что ключи, зашифрованные с помощью парольной фразы, используют bcrypt для получения ключа шифрования; в то время формат PEM был ограничен очень слабым (т. е. легко поддающимся перебору) KDF, и даже PKCS#8 поддерживает только немного худший PKBDF2.

  • PuTTY имеет собственный .ppkформат, который в основном текстовый.

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

    Вы можете использовать /usr/bin/puttygenдля конвертации между всеми этими форматами.

  • Программное обеспечение Java может использовать формат PKCS#12 (PFX), поскольку он является собственным форматом «хранилища ключей Java», а некоторое программное обеспечение может даже использовать предполагаемый стандартный формат SSH.COM.

Смотрите также:Формат файла открытого ключа OpenSSH?

Открытые ключи

По сути, это один и тот же тип данных, но отформатированный по-разному?

Да, по сути это одни и те же данные.

  • BEGIN PUBLIC KEYя полагаю, что это также PKCS#8 – поэтому внутри Base64 есть DER-сериализованная структура ASN.1, которая идентифицирует ее как ключ RSA, за которым следуют ключевые параметры (н,е).

  • Однострочный формат частично специфичен для OpenSSH, хотя центральные данные, закодированные Base64, находятся в том же формате, что и используемые в самом протоколе SSHv2 («на проводе»). Как вы могли догадаться, закодированные данные используют сериализацию пакетов SSHv2, но они по-прежнему содержат тот же RSAниеценности.

Смотрите также:Формат файла открытого ключа OpenSSH?

Например, почему мое имя пользователя, имя моего компьютера и имя моей локальной сети находятся в этом ключе?

Это комментарий.чтобы помочь вам отличить этот открытый ключ от других открытых ключей, когда у вас длинный authorized_keysфайл.

Связанный контент