RSA-шифрование. Описание и реализация алгоритма RSA
RSA-шифрование представляет собой одну из первых практических криптосистем с открытым ключом, которая широко используется для безопасной передачи данных. Ее основное отличие от подобных сервисов в том, что ключ шифрования является открытым и отличается от ключа дешифрования, который держится в секрете. В технологии RSA эта асимметрия основана на практической сложности факторингового воспроизведения двух больших простых чисел (проблема факторинга).
История создания
Название RSA состоит из начальных букв фамилий Ривест, Шамир и Адлеман, — ученых, которые впервые публично описали подобные алгоритмы шифрования в 1977 году. Клиффорд Кокс, английский математик, работавший на спецслужбы Великобритании, впервые разработал эквивалентную систему в 1973 году, но она не была рассекречена до 1997 г.
Пользователь RSA создает и затем публикует открытый ключ, основанный на двух больших простых числах вместе со вспомогательным значением. Простые числа должны храниться в тайне. Любой человек может использовать открытый ключ для шифрования сообщения, но если он достаточно большой, то только кто-либо со знанием простых чисел может декодировать сообщение. Раскрытие RSA шифрования известно как основная проблема: сегодня остается открытой дискуссия о том, насколько это надежный механизм.
RSA является относительно медленным алгоритмом, по причине чего он не так широко используется для непосредственного шифрования данных пользователя. Чаще всего этот метод используют для передачи в зашифрованном виде общих ключей для симметричного ключа шифрования, который, в свою очередь, может выполнять операции массового шифрования и дешифрования на гораздо более высокой скорости.
Когда появилась криптосистема в современном виде?
Идея асимметричного ключа криптосистемы приписывается Диффи и Хеллману, которые опубликовали концепцию в 1976 году, представив цифровые подписи и попытавшись применить теорию чисел. Их формулировка использует общий секретный ключ, созданный из экспоненциации некоторого числа по модулю простого числа. Тем не менее, они оставили открытой проблему реализации этой функции, поскольку принципы факторинга не были хорошо изучены в то время.
Ривест, Ади Шамир и Адлеман в Массачусетском технологическом институте предприняли несколько попыток в течение года, чтобы создать однонаправленную функцию, которую трудно раскодировать. Ривест и Шамир (как компьютерные ученые) предложили множество потенциальных функций, в то время как Адлеманом (как математиком) осуществлялся поиск «слабых мест» алгоритма. Они использовали много подходов и в конечном итоге в апреле 1977 года разработали окончательно систему, сегодня известную как RSA.
ЭЦП и открытый ключ
Электронная цифровая подпись, или ЭЦП, представляет собой составную часть документов электронного типа. Она образуется при определенном криптографическом изменении данных. С помощью этого атрибута возможно провести проверку целостности документа, его конфиденциальности, а также установить, кто является его владельцем. По сути, это альтернатива обыкновенной стандартной подписи.
Данная криптосистема (RSA-шифрование) предлагает открытый ключ, чем отличается от симметричных. Принцип ее функционирования в том, что применяют два разных ключа – закрытый (зашифрованный), а также открытый. Первый применяют для того, чтобы сгенерировать ЭЦП и впоследствии получить возможность расшифровки текста. Второй – для собственно шифрования и проверки ЭЦП.
Использование подписи позволяет лучше понять шифрование RSA, пример которого можно привести как обычный засекреченный «закрытый от посторонних глаз» документ.
В чем суть алгоритма?
Алгоритм RSA состоит из четырех этапов: генерации ключей, их распределения, шифрования и дешифрования. Как уже было указано, RSA-шифрование включает в себя открытый ключ и закрытый ключ. Открытый может быть известен всем и используется для шифрования сообщений. Суть его состоит в том, что сообщения, зашифрованные с помощью открытого ключа, могут быть расшифрованы только в определенный промежуток времени с использованием секретного ключа.
В целях безопасности целые числа должны быть выбраны случайным образом и быть одинаковыми по величине, но при этом различаться по длине на несколько цифр, чтобы сделать факторинг сложнее. Одинаковые же числа могут быть эффективно найдены с помощью теста на их простоту, поэтому шифрование информации должно обязательно усложняться.
Открытый ключ состоит из модуля и публичной экспоненты. Закрытый состоит из модуля и приватного показателя, который должен храниться в тайне.
Шифрование файлов RSA и слабые места
Однако существует целый ряд механизмов по взлому простого RSA. При шифровании с низкими показателями и малыми значениями чисел шифр может быть легко раскрыт, если подобрать корень шифротекста над целыми числами.
Поскольку RSA-шифрование является детерминированным алгоритмом (т.е. не имеет случайной составляющей), злоумышленник может успешно запустить выбранный открытый текст атаки против криптосистемы путем шифрования вероятных открытых текстов под открытым ключом и проверками на предмет того, равны ли они шифротексту. Криптосистема называется семантически безопасной в том случае, если злоумышленник не сможет отличить две шифровки друг от друга, даже если он знает соответствующие тексты в раскрытом виде. Как было описано выше, RSA без дополнения другими сервисами не является семантически безопасной.
Дополнительные алгоритмы шифрования и защиты
Чтобы избежать вышеуказанных проблем, при практической реализации RSA обычно встраивают некоторую форму структурированного, рандомизированного заполнения перед шифрованием. Это гарантирует, что содержание не попадает в диапазон небезопасных открытых текстов и что данное сообщение не сможет быть раскрыто путем случайного подбора.
Безопасность криптосистемы RSA и шифрование информации основаны на двух математических задачах: проблемы разложения на множители больших чисел и собственно проблемы RSA. Полное раскрытие шифротекста и ЭЦП в RSA считается недопустимым на том предположении, что обе эти проблемы невозможно разрешить в совокупности.
Однако благодаря возможности восстановления простых множителей, злоумышленник может вычислить секретный показатель из открытого ключа, а затем расшифровать текст с помощью стандартной процедуры. Несмотря на то что сегодня ни один существующий метод для факторизации больших чисел на классическом компьютере не найден, не было доказано, что он не существует.
Автоматизация
Инструмент, называемый Yafu, может быть использован для оптимизации этого процесса. Автоматизация в YAFU представляет собой современную функцию, сочетающую алгоритмы факторизации в интеллектуальной и адаптивной методологии, которая сводит к минимуму время, чтобы найти факторы произвольных входных чисел. Большинство реализаций алгоритма многопоточные, что позволяет Yafu в полной мере использовать мульти- или много многоядерные процессоры (в том числе SNFS, SIQS и ECM). Прежде всего, это управляемый инструмент командной строки. Время, затраченное на поиск фактора шифрования с использованием Yafu на обычном компьютере, может быть уменьшено до 103.1746 секунд. Инструмент производит обработку бинарных файлов емкостью 320 бит или больше. Это очень сложное программное обеспечение, которое требует определенного количества технических навыков для установки и настройки. Таким образом, RSA-шифрование C может оказаться уязвимым.
Попытки взлома в новейшее время
В 2009 году Бенджамин Муди с помощью битового ключа RSA-512 работал над расшифровкой криптотекста в течение 73 дней, используя только общеизвестное программное обеспечение (GGNFS) и среднестатистический настольный компьютер (двухъядерный Athlon64 при 1900 МГц). Как показал данный опыт, потребовалось чуть менее 5 гигабайт диска и около 2,5 гигабайт оперативной памяти для процесса «просеивания».
По состоянию на 2010 год, самый большой факторизованный номер RSA был 768 бит длиной (232 десятичные цифры, или RSA-768). Его раскрытие длилось два года на нескольких сотнях компьютеров одновременно.
На практике же ключи RSA имеют большую длину — как правило, от 1024 до 4096 бит. Некоторые эксперты считают, что 1024-битные ключи могут стать ненадежными в ближайшем будущем или даже уже могут быть взломаны достаточно хорошо финансируемым атакующим. Однако, мало кто станет утверждать, что 4096-битные ключи могут быть также раскрыты в обозримом будущем.
Перспективы
Поэтому, как правило, предполагается, что RSA является безопасным, если числа достаточно велики. Если же основное число 300 бит или короче, шифротекст и ЭЦП может быть разложен в течение нескольких часов на персональном компьютере с использованием программного обеспечения, имеющегося уже в свободном доступе. Ключи длиной 512 бит, как было доказано, могли быть вскрыты уже в 1999 году с использованием нескольких сотен компьютеров. В наши дни это возможно в течение нескольких недель с использованием общедоступного аппаратного обеспечения. Таким образом, вполне возможно, что в будущембудет легко раскрываться RSA-шифрование на пальцах, и система станет безнадежно устаревшей.
Официально в 2003 году была поставлена под сомнение безопасность 1024-битных ключей. В настоящее время рекомендуется иметь длину не менее 2048 бит.
fb.ru
Не стоит паниковать по поводу слабых RSA ключей — просто заботьтесь о своих P и Q / Habr
Вы возможно уже видели препринт опубликованный сегодня Ленстрой и др (обсуждение на хабре) о проблемах с энтропией в криптографических системах с открытыми ключами. Закир Дурумерик, Ерик Вустров, Алекс Халдерман, и Я (Надя Хенингер) ждали, чтобы раскрыть похожие результаты. Мы опубликуем полную статью после того, как все задействованные производители будут оповещены. А между тем мы хотим предоставить более полное объяснение того, что же реально происходит.Мы смогли удалено скомпрометировать около 0.4 % от всех открытых ключей, используемых веб сайтами для SSL. Все скомпрометированные ключи были неправильно сгенерированы, с использованием предсказуемых «рандомных» чисел, которые к тому же ещё и иногда повторялись. Всего мы можем выделить два типа проблем: ключи, сгенерированные с предсказуемой рандомностью, и подмножество этих ключей, для которых нехватка рандомности позволяет атакующему быстро факторизовать открытый ключ и получить секретный ключ. Имея секретный ключ, атакующий сможет выдать себя за вебсайт и возможно сможет расшифровывать зашифрованный трафик направленый на этот сайт. Мы разработали программу которая за пару часов может факторизовать открытые ключи и выдавать секретные ключи для всех хостов уязвимых к этой атаке.
Тем не менее, не стоит паниковать, так как в основном проблема влияет на встраиваемые системы, такие как маршрутизаторы и VPN, и не касается полномасштабных серверов. (Во всяком случае это точно не причина терять доверенность к электронной коммерции, как это предполагает New York Times). К сожалению, мы нашли устройства с этой проблемой практически у каждого производителя и мы подозреваем, что около 200.000 устройств, представляющих 4.1% от всех ключей в наших данных, использовали плохую энтропию для генерации ключей. Любой найденный слабый ключ сгенерированный устройством предполагает, что весь класс этих устройств уязвим для атаки при должном анализе.
Мы не будем предоставлять полный список уязвимых устройств до того как мы свяжемся со всеми производителями, но используя уже опубликованные материалы можно довольно легко воспроизвести атаку. Поэтому мы сейчас работаем над веб сайтом, который позволит определить уязвимо ли ваше устройство.
Не волнуйтесь, ключ вашего банка скорее всего в безопасности.
SSL используется каждым большим сайтом в Интернете, но как показывает наш анализ, эти ключи не подвержены проблемам описанным в этом посте.
Так какие же системы в опасности? Почти все уязвимые ключи были сгенерированы и использовались во встраиваемых системах, таких как, маршрутизаторы и брандмауэры, и не использовались на вебсайтах для банков или e-mail. Только один из уязвимых SSL ключей был подписан центром сертификации и он уже истек. Также мы нашли несколько подписанных сертификатов использующих повторяющиеся ключи; некоторые из которых были сгенерированы уязвимыми устройствами, другие были поданы на подпись владельцами сайтов как заведомо слабые и для некоторых мы не можем придумать хорошее объяснение.
Всем известно что во встраиваемых системах есть проблемы с энтропией. Однако, до текущего времени не было понятно насколько эти проблемы были распространены в реальных устройствах, подключенных к интернету.
Генерация Ключей
Веб сайты и сетевые компьютеры используют криптосистемы с открытыми ключами для идентификации. Дальше мы будем говорить о типе идентификации, когда сервер предоставляет клиенту сертификат для того, чтобы удостоверить клиента что он именно тот к кому клиент хочет подключиться. Если атакующий знает секретный ключ, он может выдать себя за реальную систему или в большинстве случаев расшифровать трафик между клиентом и сервером.
Важной частью для безопасности ключа является наличие рандомных входных данных на стадии генерации ключа. Если в этих входных данных недостаточно энтропии, тогда атакующий сможет их угадать, и таким образом получить секретный ключ, без мучительной факторизации числа N.
На современных компьютерах и серверах, программы для генерации ключей используют рандомные входные данные полученные из множества физических источников (чаще всего при помощи операционной системы): движения мышки, клавиатуры, жесткого диска, сетевых событий и других не предсказуемых источников. Однако, если источников мало то будет не хватать энтропии, и ключ может оказаться уязвим для атаки. Собирание сильной энтропии и проверка её силы является очень сложной проблемой, которая породила много уязвимостей на протяжении многих лет.
Две версии проблемы
Для исследования насколько распространена эта проблема, мы просканировали все IPv4 адреса и собрали копии каждого SSL сертификата и ключа SSH. Собирание ключей и сертификатов заняло у нас меньше дня: сначала мы использовали стандартный nmap, чтобы найти хостов с соответствующими открытыми портами, а потом мы использовали свою оптимизированную программу для опроса этих хостов. Всего мы собрали 5,8 миллиона SSL сертификатов и 10 миллионов SSH ключей.
Повторяющиеся открытые ключи.
Около 1% всех RSA ключей встречались повторно, скорее всего из за проблем с энтропией. Если у двух устройств одинаковый открытый ключ, то у них также одинаковый секретный ключ. В действительности все устройства с одинаковым ключом находятся в одинаковом положении — атакующий может скомпрометировать слабейшие из этих устройств и получить ключи ко всем остальным. Уже давно было известно об этой проблеме, но до нынешнего момента, никто не документировал в открытой литературе насколько она распространена.Мы вручную проверили, что 59.000 ключей были повторены из за проблем с энтропией, которые представляют около 1% всех сертификатов, или 2,6% все самостоятельно подписанных сертификатов. Мы также нашли что 4.6% всех устройств (585,000 сертификатов) использовали сертификаты установленные по умолчанию. И хотя эти устройства не использовали ключи сгенерированые с плохой энтропией, они подвержены такой же атаке, так как их секретные ключи одинаковы на всех моделях. Мы вручную проверили все эти ключи, потому что большое количество сайтов использует повторяющиеся ключи в правильных условиях и поэтому не предоставляет опасности для пользователя.
Факторизуемые открытые ключи.
Что более удивительно, мы обнаружили, что проблемы с энтропией могут позволить удаленному атакующему, без специального доступа, факторизовать значительную часть всех RSA ключей, используемых в Интернете. Мы смогли факторизовать 0,4% всех RSA ключей в SSL сертификатах. Для этого мы посчитали наибольший общий делитель (gcd) для всех пар модулей из открытых ключей RSA в Интернете.Мы определили 1724 общих делителей, что позволило нам факторизовать 24.816 SSL ключей и 301 общих делителей для факторизации 2422 SSH ключей. Это значит, что мы смогли посчитать секретные ключи для почти 0.5% RSA ключей, используемых для SSL. Дальше мы объясним как наш расчет работает.
Конкретные уязвимые устройства
Встраиваемые системы часто генерируют криптографические ключи при первой загрузке, когда все их состояние может быть предопределено на заводе. Что может привести к таким проблемам с энтропией, как описано в этом исследовании.
Мы смогли использовать информацию из SSL сертификата для идентификации типа устройств которые склонны к генерации слабых ключей. Наверное также существует множество других устройств, ключи которых мы не смогли факторизовать, но которые все равно склонны к произведению слабых ключей и которые могут быть скомпрометированы упорным атакующим. Полный список уязвимых устройств которые мы смогли идентифицировать состоит из больше чем 30 производителей, включая почти всех больших производителей в индустрии. Типы устройств с проблемой включают брандмауэры, маршрутизаторы, VPN устройства, устройства для удалённой администрации серверов, принтеры, проекторы, и VOIP телефоны.
Мы не будем перечислять имена устройств до того как мы оповестим, но ниже можно увидеть несколько примеров:
Брандмауэр Х:
52.055 хостов в наших SSL данных
6.730 с одинаковыми ключами
12.880 с факторизуемыми ключами
Маршрутизатор Y пользовательского уровня:
9.345 с одинаковыми ключами
4.792 с факторизуемыми ключами
Решение для удаленого доступа Z, для предприятий:
1.648 хостов в наших SSL данных
24 с одинаковыми ключами
0 с факторизуемыми ключами
Как это могло произойти?
Это не совсем очевидно, как проблемы с энтропией могут привести к проблемам с ключами которые легко факторизовать. Сейчас мы объясним почему так происходит для наших более любознательных читателей.
Вот как программист может сгенерировать модуль для RSA:prgn.seed(seed)
p = prgn.generate_random_prime()
q = generate_random_prime()
N = p*q
Если зерно для генератора псевдослучайных чисел имеет предсказуемое значение, тогда несколько различных устройств могут иметь одинаковый модуль
Однако, некоторые реализации также добавляют дополнительною рандомность между генерацией простых чисел p и q, с идеей повышения безопасности:prgn.seed(seed)
p = prgn.generate_random_prime()
prgn.add_randomness(bits)
q = generate_random_prime()
N = p*q
Если первое зерно было сгенерировано с плохой энтропией, это может привести к тому, что у нескольких устройств будут разные модули, состоящие из одинаковых факторов
Генерация ключей RSA в OpenSSL работает следующим образом: после каждого использования рандомных битов из пула энтропии для генерации простых чисел p и q, текущее время в секундах добавляется в пул. Многие, но не все, уязвимые ключи были сгенерированы с использованием OpenSSL и OpenSSH, который использует OpenSSL для генерации RSA ключей.
Вычисление GCD для всех пар ключей
Если любая пара RSA модулей N1 и N2 имеет один одинаковый фактор, то можно просто факторизовать оба модуля используя gcd. На моем настольном компьютерe операция вычисления gcd для двух 1024 RSA модулей занимает около 17 микро секунд.
Простой подход к факторизации ключей включает в себя вычисление gcd для каждой пары RSA модулей. Но если оценить сколько времени эти вычисления займут то мы получим около 24 лет на моем настольном компьютерe.
Вместо этого, мы используем идею Дена Берстейна, опубликованную в Journal of Algorithms в 2005 году, которая позволяет факторизовать группу целых чисел во взаимно простые числа и которая позволит нам произвести наши вычисления всего за пару часов, с реализацией занимающей всего несколько строк в Python. Алгоритм не является большой тайной: большое количество опубликованных работ работало над улучшением алгоритма.
Главное математическое обозрение в этой проблеме это то, что мы можем вычислить gcd для модуля N1 вместе со всеми другими модулями используя следующее уравнение:gcd(N1, N2 ... Nm) = gcd(N1, (N1 * N2 * ... Nm mod N1^2)/N1)
Большая проблема в том как заставить просчёт этого уравнения производиться быстро — заметьте что первым шагом этого вычисления является нахождение произведения всех ключей, числа состоящего из 729 миллионов цифр. Мы смогли добиться факторизации всех SSL данных за 18 часов на одноядерном процессоре и факторизации SSH данных за 4 часа на четырех ядерном процессоре.
Заключение
Это конечно проблема, но не та о которой стоит волноваться обычному пользователю. Однако, много работы предстоит производителям встраиваемых систем, и некоторые системные администраторы должны быть обеспокоены. Это должно послужить пробуждающим звонком для людей в области безопасности, и напоминанием нам всем о том, как уязвимости иногда прячутся на виду у всех.
habr.com
Использовать закрытый ключ RSA для генерации открытого ключа? — openssl
Мой ответ ниже немного длинный, но, надеюсь, он содержит некоторые детали, которые отсутствуют в предыдущих ответах. Я начну с некоторых связанных утверждений и, наконец, отвечу на начальный вопрос.
Чтобы зашифровать что-либо с помощью алгоритма RSA, вам нужна параграф экспоненциального модуля и шифрования (public) (n, e). Это ваш открытый ключ. Чтобы расшифровать что-либо с помощью алгоритма RSA, вам нужна пара с показателем модуляции и дешифрования (private) (n, d). Это ваш закрытый ключ.
Чтобы зашифровать что-либо с помощью открытого ключа RSA, вы обрабатываете свой открытый текст как число и поднимите его на мощность модуля e n:
ciphertext = ( plaintext^e ) mod n
Чтобы расшифровать что-либо с помощью секретного ключа RSA, вы обрабатываете свой зашифрованный текст как число и поднимите его на мощность модуля d n:
plaintext = ( ciphertext^d ) mod n
Чтобы сгенерировать закрытый ключ (d, n) с помощью openssl, вы можете использовать следующую команду:
openssl genrsa -out private.pem 1024
Чтобы сгенерировать открытый ключ (e, n) из закрытого ключа с помощью openssl, вы можете использовать следующую команду:
openssl rsa -in private.pem -out public.pem -pubout
Чтобы проанализировать содержимое частного ключа RSA private.pem, сгенерированного командой openssl выше, выполните следующее (вывод здесь усечен на метки):
openssl rsa -in private.pem -text -noout | less
modulus - n
privateExponent - d
publicExponent - e
prime1 - p
prime2 - q
exponent1 - d mod (p-1)
exponent2 - d mod (q-1)
coefficient - (q^-1) mod p
Должен ли закрытый ключ состоять только из (n, d)? Почему есть 6 дополнительных компонентов? Он содержит e (публичный показатель), так что открытый ключ RSA может быть сгенерирован/извлечен/получен из частного ключа RSA private.pem. Остальные 5 компонентов должны ускорить процесс дешифрования. Оказывается, что, предварительно вычисляя и сохраняя эти 5 значений, можно ускорить расшифровку RSA с коэффициентом 4. Расшифровка будет работать без этих 5 компонентов, но это можно сделать быстрее, если вы им удобны. Алгоритм ускорения основан на Китайской теореме останова.
Да, private.pem закрытый ключ RSA фактически содержит все эти 8 значений; ни один из них не генерируется «на лету» при выполнении предыдущей команды. Попробуйте выполнить следующие команды и сравнить выходные данные:
# Convert the key from PEM to DER (binary) format
openssl rsa -in private.pem -outform der -out private.der
# Print private.der private key contents as binary stream
xxd -p private.der
# Now compare the output of the above command with output
# of the earlier openssl command that outputs private key
# components. If you stare at both outputs long enough
# you should be able to confirm that all components are
# indeed lurking somewhere in the binary stream
openssl rsa -in private.pem -text -noout | less
Эта структура закрытого ключа RSA рекомендуется PKCS # 1 v1.5 в качестве альтернативного (второго) представления. Стандарт PKCS # 1 v2.0 исключает показатели e и d из альтернативного представления вообще. PKCS # 1 v2.1 и v2.2 предлагать дальнейшие изменения в альтернативном представлении, необязательно включающие в себя больше компонентов, связанных с CRT.
Чтобы просмотреть содержимое общедоступного ключа RSA public.pem, выполните следующее (вывод здесь усечен на метки):
openssl rsa -in public.pem -text -pubin -noout
Modulus - n
Exponent (public) - e
Никаких сюрпризов здесь нет. Это просто (n, e) пара, как и было обещано.
Теперь, наконец, отвечая на начальный вопрос: Как было показано выше, частный ключ RSA, сгенерированный с помощью openssl, содержит компоненты как открытых, так и частных ключей и некоторых других. Когда вы генерируете/извлекаете/извлекаете открытый ключ из закрытого ключа, openssl копирует два из этих компонентов (e, n) в отдельный файл, который становится вашим открытым ключом.
qaru.site
Формат открытых ключей RSA — encryption
Вы не можете просто изменить разделители от ---- BEGIN SSh3 PUBLIC KEY ---- до -----BEGIN RSA PUBLIC KEY----- и ожидать, что этого будет достаточно для преобразования из одного формата в другой (это то, что вы сделали в своем примере).
В этой статье есть хорошее объяснение обоим форматам.
То, что вы получаете в RSA PUBLIC KEY, ближе к содержимому PUBLIC KEY, но вам необходимо компенсировать начало структуры ASN.1, чтобы отразить тот факт, что PUBLIC KEY также имеет индикатор, указывающий, какой тип ключа (см. RFC 3447). Вы можете увидеть это с помощью openssl asn1parse и -strparse 19, как описано в этом ответе.
EDIT: после редактирования вы можете получить информацию о своей структуре RSA PUBLIC KEY, используя grep -v -- ----- | tr -d '\n' | base64 -d | openssl asn1parse -inform DER:
0:d=0 hl=4 l= 266 cons: SEQUENCE
4:d=1 hl=4 l= 257 prim: INTEGER :FB1199FF0733F6E805A4FD3B36CA68E94D7B974621162169C71538A539372E27F3F51DF3B08B2E111C2D6BBF9F5887F13A8DB4F1EB6DFE386C92256875212DDD00468785C18A9C96A292B067DDC71DA0D564000B8BFD80FB14C1B56744A3B5C652E8CA0EF0B6FDA64ABA47E3A4E89423C0212C07E39A5703FD467540F874987B209513429A90B09B049703D54D9A1CFE3E207E0E69785969CA5BF547A36BA34D7C6AEFE79F314E07D9F9F2DD27B72983AC14F1466754CD41262516E4A15AB1CFB622E651D3E83FA095DA630BD6D93E97B0C822A5EB4212D428300278CE6BA0CC7490B854581F0FFB4BA3D4236534DE09459942EF115FAA231B15153D67837A63
265:d=1 hl=2 l= 3 prim: INTEGER :010001
Чтобы декодировать формат ключа SSH, вам необходимо использовать спецификацию формата данных в RFC 4251 в сочетании с RFC 4253:
The "ssh-rsa" key format has the following specific encoding: string "ssh-rsa" mpint e mpint n
Например, в начале вы получаете 00 00 00 07 73 73 68 2d 72 73 61. Первые четыре байта (00 00 00 07) дают вам длину. Остальное — сама строка: 73 = s, 68 = h,… → 73 73 68 2d 72 73 61= ssh-rsa, за которой следует показатель длины 1 (00 00 00 01 25) и модуль длины 256 (00 00 01 00 7f ...).
qaru.site
Как сохранить/получить открытый/закрытый ключ RSA — c#
Я хотел указать что-то в ответ на комментарий ala, спрашивающий:
Открытый ключ = модуль + экспонента
Это точно. Существует несколько способов хранения этого exponent + modulus. Первая попытка стандарта была в RFC 3447 (Стандарты криптографии с открытым ключом (PKCS) № 1: Спецификации шифрования RSA версии 2.1), которая определяет структуру открытого ключа под названием RSAPublicKey:
RSAPublicKey ::= SEQUENCE {
modulus INTEGER, -- n
publicExponent INTEGER -- e
}
В этом же RFC объявляется, что вы должны использовать DER аромат ASN.1 encoding для хранения открытый ключ. У меня есть образец открытого ключа:
- publicExponent: 65537 (условно, что все открытые ключи RSA используют 65537 в качестве экспонента)
- модуль:
0xDC 67 FA F4 9E F2 72 1D 45 2C B4 80 79 06 A0 94 27 50 8209 DD 67 CE 57 B8 6C 4A 4F 40 9F D2 D1 69 FB 995D 85 0C 07 A1 F9 47 1B 56 16 6E F6 7F B9 CF 2A 58 36 37 99 29 AA 4F A8 12 E8 4F C7 82 2B 9D 72 2A 9C DE 6F C2 EE 12 6D CF F0 F2 B8 C4 DD 7C 5C 1A C8 17 51 A9 AC DF 08 22 04 9D 2B D7 F9 4B 09 DE 9A EB 5C 51 1A D8 F8 F9 56 9E F8 FB 37 9B 3F D3 74 65 24 0D FF 34 75 57 A4 F5 BF 55
Кодирование DER ASN.1 этого открытого ключа:
30 81 89 ;SEQUENCE (0x89 bytes = 137 bytes)
| 02 81 81 ;INTEGER (0x81 bytes = 129 bytes)
| | 00 ;leading zero of INTEGER
| | DC 67 FA
| | F4 9E F2 72 1D 45 2C B4 80 79 06 A0 94 27 50 82
| | 09 DD 67 CE 57 B8 6C 4A 4F 40 9F D2 D1 69 FB 99
| | 5D 85 0C 07 A1 F9 47 1B 56 16 6E F6 7F B9 CF 2A
| | 58 36 37 99 29 AA 4F A8 12 E8 4F C7 82 2B 9D 72
| | 2A 9C DE 6F C2 EE 12 6D CF F0 F2 B8 C4 DD 7C 5C
| | 1A C8 17 51 A9 AC DF 08 22 04 9D 2B D7 F9 4B 09
| | DE 9A EB 5C 51 1A D8 F8 F9 56 9E F8 FB 37 9B 3F
| | D3 74 65 24 0D FF 34 75 57 A4 F5 BF 55
| 02 03 ;INTEGER (0x03 = 3 bytes)
| | 01 00 01 ;hex for 65537. see it?
Если вы берете все выше DER ASN.1, закодированное modulus + exponent:
30 81 89 02 81 81 00 DC 67 FA F4 9E F2 72 1D 45 2C B4 80 79 06 A0 94 27 50 82 09 DD 67 CE 57 B8 6C 4A 4F 40 9F D2 D1 69 FB 99 5D 85 0C 07 A1 F9 47 1B 56 16 6E F6 7F B9 CF 2A 58 36 37 99 29 AA 4F A8 12 E8 4F C7 82 2B 9D 72 2A 9C DE 6F C2 EE 12 6D CF F0 F2 B8 C4 DD 7C 5C 1A C8 17 51 A9 AC DF 08 22 04 9D 2B D7 F9 4B 09 DE 9A EB 5C 51 1A D8 F8 F9 56 9E F8 FB 37 9B 3F D3 74 65 24 0D FF 34 75 57 A4 F5 BF 55 02 03 01 00 01
и вы PEM закодируете его (то есть base64):
MIGJAoGBANxn+vSe8nIdRSy0gHkGoJQnUIIJ3WfOV7hsSk9An9LRafuZXY
UMB6H5RxtWFm72f7nPKlg2N5kpqk+oEuhPx4IrnXIqnN5vwu4Sbc/w8rjE
3XxcGsgXUams3wgiBJ0r1/lLCd6a61xRGtj4+Vae+Ps3mz/TdGUkDf80dV
ek9b9VAgMBAAE=
Это соглашение об обертывании данных, закодированных в base64, в:
-----BEGIN RSA PUBLIC KEY-----
MIGJAoGBANxn+vSe8nIdRSy0gHkGoJQnUIIJ3WfOV7hsSk9An9LRafuZXY
UMB6H5RxtWFm72f7nPKlg2N5kpqk+oEuhPx4IrnXIqnN5vwu4Sbc/w8rjE
3XxcGsgXUams3wgiBJ0r1/lLCd6a61xRGtj4+Vae+Ps3mz/TdGUkDf80dV
ek9b9VAgMBAAE=
-----END RSA PUBLIC KEY-----
И как вы получите PEM DER ASN.1 PKCS # 1 RSA Открытый ключ.
Следующий стандарт был RFC 4716 (формат файла открытого ключа Secure Shell (SSH)). Они включали идентификатор алгоритма (ssh-rsa) перед экспонентой и модулем:
string "ssh-rsa"
mpint e
mpint n
Они не хотели использовать кодировку DER ASN.1 (поскольку она ужасно сложна) и вместо этого предпочли префикс длины в 4 байта:
00000007 ;7 byte algorithm identifier
73 73 68 2d 72 73 61 ;"ssh-rsa"
00000003 ;3 byte exponent
01 00 01 ;hex for 65,537
00000080 ;128 byte modulus
DC 67 FA F4 9E F2 72 1D 45 2C B4 80 79 06 A0 94
27 50 82 09 DD 67 CE 57 B8 6C 4A 4F 40 9F D2 D1
69 FB 99 5D 85 0C 07 A1 F9 47 1B 56 16 6E F6 7F
B9 CF 2A 58 36 37 99 29 AA 4F A8 12 E8 4F C7 82
2B 9D 72 2A 9C DE 6F C2 EE 12 6D CF F0 F2 B8 C4
DD 7C 5C 1A C8 17 51 A9 AC DF 08 22 04 9D 2B D7
F9 4B 09 DE 9A EB 5C 51 1A D8 F8 F9 56 9E F8 FB
37 9B 3F D3 74 65 24 0D FF 34 75 57 A4 F5 BF 55
Возьмите всю приведенную выше последовательность байтов, а base-64 закодируйте ее:
AAAAB3NzaC1yc2EAAAADAQABAAAAgNxn+vSe8nIdRSy0gHkGoJQnUIIJ3WfOV7hs
Sk9An9LRafuZXYUMB6H5RxtWFm72f7nPKlg2N5kpqk+oEuhPx4IrnXIqnN5vwu4S
bc/w8rjE3XxcGsgXUams3wgiBJ0r1/lLCd6a61xRGtj4+Vae+Ps3mz/TdGUkDf80
dVek9b9V
И оберните его в заголовок и трейлер OpenSSH:
---- BEGIN SSh3 PUBLIC KEY ----
AAAAB3NzaC1yc2EAAAADAQABAAAAgNxn+vSe8nIdRSy0gHkGoJQnUIIJ3WfOV7hs
Sk9An9LRafuZXYUMB6H5RxtWFm72f7nPKlg2N5kpqk+oEuhPx4IrnXIqnN5vwu4S
bc/w8rjE3XxcGsgXUams3wgiBJ0r1/lLCd6a61xRGtj4+Vae+Ps3mz/TdGUkDf80
dVek9b9V
---- END SSh3 PUBLIC KEY ----
Примечание. Что OpenSSH использует четыре тире с пробелом (----), а не пять тире и пробел (-----).
Следующим стандартом был RFC 2459 (Internet X.509 Сертификат инфраструктуры открытого ключа и профиль CRL). Они взяли формат открытого ключа PKCS # 1:
RSAPublicKey ::= SEQUENCE {
modulus INTEGER, -- n
publicExponent INTEGER -- e
}
и расширил его, включив префикс идентификатора алгоритма (если вы хотите использовать алгоритм шифрования с открытым ключом другой, чем RSA):
SubjectPublicKeyInfo ::= SEQUENCE { algorithm AlgorithmIdentifier, subjectPublicKey RSAPublicKey }
«Идентификатор алгоритма» для RSA 1.2.840.113549.1.1.1, который исходит из:
-
1— ISO присвоены идентификаторы OID-
1.2— Корпус члена ISO-
1.2.840— США-
1.2.840.113549— RSADSI-
1.2.840.113549.1— PKCS-
1.2.840.113549.1.1— PKCS-1
-
-
-
-
-
X.509 — ужасный стандарт, который определяет ужасно сложный способ кодирования OID в hex, но в конце кодирование DER ASN.1 открытого ключа X.509 SubjectPublicKeyInfo RSA:
30 81 9F ;SEQUENCE (0x9f bytes = 159 bytes) | 30 0D ;SEQUENCE (0x0d bytes = 13 bytes) | | 06 09 ;OBJECT_IDENTIFIER (0x09 = 9 bytes) | | 2A 86 48 86 ;Hex encoding of 1.2.840.113549.1.1 | | F7 0D 01 01 01 | | 05 00 ;NULL (0 bytes) | 03 81 8D 00 ;BIT STRING (0x8d bytes = 141 bytes) | | 30 81 89 ;SEQUENCE (0x89 bytes = 137 bytes) | | | 02 81 81 ;INTEGER (0x81 bytes = 129 bytes) | | | 00 ;leading zero of INTEGER | | | DC 67 FA | | | F4 9E F2 72 1D 45 2C B4 80 79 06 A0 94 27 50 82 | | | 09 DD 67 CE 57 B8 6C 4A 4F 40 9F D2 D1 69 FB 99 | | | 5D 85 0C 07 A1 F9 47 1B 56 16 6E F6 7F B9 CF 2A | | | 58 36 37 99 29 AA 4F A8 12 E8 4F C7 82 2B 9D 72 | | | 2A 9C DE 6F C2 EE 12 6D CF F0 F2 B8 C4 DD 7C 5C | | | 1A C8 17 51 A9 AC DF 08 22 04 9D 2B D7 F9 4B 09 | | | DE 9A EB 5C 51 1A D8 F8 F9 56 9E F8 FB 37 9B 3F | | | D3 74 65 24 0D FF 34 75 57 A4 F5 BF 55 | | 02 03 ;INTEGER (0x03 = 3 bytes) | | | 01 00 01 ;hex for 65537. see it?
В декодированном ASN.1 вы можете видеть, как они только префикс старого RSAPublicKey с помощью OBJECT_IDENTIFIER.
Принимая приведенные выше байты и PEM (то есть base-64), кодируя их:
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDcZ/r0nvJyHUUstIB5BqCUJ1CC
Cd1nzle4bEpPQJ/S0Wn7mV2FDAeh+UcbVhZu9n+5zypYNjeZKapPqBLoT8eCK51y
Kpzeb8LuEm3P8PK4xN18XBrIF1GprN8IIgSdK9f5SwnemutcURrY+PlWnvj7N5s/
03RlJA3/NHVXpPW/VQIDAQAB
Стандарт — это обернуть его заголовком, похожим на RSA PKCS # 1, но без «RSA» (поскольку это может быть нечто иное, чем RSA):
-----BEGIN PUBLIC KEY-----
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDcZ/r0nvJyHUUstIB5BqCUJ1CC
Cd1nzle4bEpPQJ/S0Wn7mV2FDAeh+UcbVhZu9n+5zypYNjeZKapPqBLoT8eCK51y
Kpzeb8LuEm3P8PK4xN18XBrIF1GprN8IIgSdK9f5SwnemutcURrY+PlWnvj7N5s/
03RlJA3/NHVXpPW/VQIDAQAB
-----END PUBLIC KEY-----
И как вы изобретаете формат X.509 SubjectPublicKeyInfo/OpenSSL PEM открытого ключа.
Это не останавливает список стандартных форматов для открытого ключа RSA. Далее следует проприетарный формат открытого ключа, используемый OpenSSH:
SSH-RSA AAAAB3NzaC1yc2EAAAADAQABAAAAgNxn + vSe8nIdRSy0gHkGoJQnUIIJ3WfOV7hs Sk9An9LRafuZXYUMB6H5RxtWFm72f7nPKlg2N5kpqk + oEuhPx4IrnXIqnN5vwu4Sbc/w8rjE3XxcGsgXUams3wgiBJ0r1/lLCd6a61xRGtj4 + Vae + Ps3mz/TdGUkDf80dVek9b9V
На самом деле это формат SSH открытого ключа, но с префиксом ssh-rsa, а не завернутый в ---- BEGIN SSh3 PUBLIC KEY ----/---- END SSh3 PUBLIC KEY ----.
Здесь легкодоступный XML RSAKeyValue открытый ключ:
- Экспонента:
0x 010001закодировано base64AQAB - Modulus:
0x 00 dc 67 fa f4 9e f2 72 1d 45 2c b4 80 79 06 a0 94 27 50 82 09 dd 67 ce 57 b8 6c 4a 4f 40 9f d2 d1 69 fb 99 5d 85 0c 07 a1 f9 47 1b 56 16 6e f6 7f b9 cf 2a 58 36 37 99 29 aa 4f a8 12 e8 4f c7 82 2b 9d 72 2a 9c de 6f c2 ee 12 6d cf f0 f2 b8 c4 dd 7c 5c 1a c8 17 51 a9 ac df 08 22 04 9d 2b d7 f9 4b 09 de 9a eb 5c 51 1a d8 f8 f9 56 9e f8 fb 37 9b 3f d3 74 65 24 0d ff 34 75 57 a4 f5 bf 55base64 закодированANxn+vSe8nIdRSy0gHkGoJQnUIIJ3WfOV7hsSk9An9LRafuZXYUMB6H5RxtWFm72f7nPKlg2N5kpqk+oEuhPx4IrnXIqnN5vwu4Sbc/w8rjE3XxcGsgXUams3wgiBJ0r1/lLCd6a61xRGtj4+Vae+Ps3mz/TdGUkDf80dVek9b9V.
Это означает, что XML:
<RSAKeyValue>
<Modulus>ANxn+vSe8nIdRSy0gHkGoJQnUIIJ3WfOV7hsSk9An9LRafuZXYUMB6H5RxtWFm72f7nPKlg2N5kpqk+oEuhPx4IrnXIqnN5vwu4Sbc/w8rjE3XxcGsgXUams3wgiBJ0r1/lLCd6a61xRGtj4+Vae+Ps3mz/TdGUkDf80dVek9b9V</Modulus>
<Exponent>AQAB</Exponent>
</RSAKeyValue>
Гораздо проще. Недостатком является то, что он не обертывает, не копирует, не вставляет, так же хорошо (например, Xml не так удобен для пользователя):
-----BEGIN RSA PUBLIC KEY-----
MIGJAoGBANxn+vSe8nIdRSy0gHkGoJQnUIIJ3WfOV7hsSk9An9LRafuZXY
UMB6H5RxtWFm72f7nPKlg2N5kpqk+oEuhPx4IrnXIqnN5vwu4Sbc/w8rjE
3XxcGsgXUams3wgiBJ0r1/lLCd6a61xRGtj4+Vae+Ps3mz/TdGUkDf80dV
ek9b9VAgMBAAE=
-----END RSA PUBLIC KEY-----
Но он делает большой нейтральный формат хранения.
См. также
- Переводчик, двоичный: отлично подходит для декодирования и кодирования данных base64.
- ASN.1 JavaScript-декодер: отлично подходит для декодирования кодированных по ASN.1 шестнадцатеричных данных (которые вы получаете из
Translator, Binary - Документация Microsoft ASN.1: описывает отличительные правила кодирования (DER), используемые для структур ASN.1 ( вы не найдете лучшего набора документации в другом месте, я бы сказал, что Microsoft — это не только настоящая документация).
qaru.site
RSA или авторизация SSH по ключу
Настроим авторизацию по ключу RSA для SSH сервера. Помимо удобства в использовании мы сильно обезопасим нашу систему от взлома. Рассмотрим разные варианты использования подключения по ключу. Надежное хранение приватных ключей гарантия подключения.
Введение
Не на долго удалось мне отложить настройку этого варианта подключения к серверу. Необходимость настройки доступа по ключу пришла откуда я даже не думал. Неожиданно обнаружил что резервные копии периодически не проходят на Yandex.Disk. Резервирование сайтов у меня производится скриптом который резервирует вначале файлы сайта а потом базу. Пропуски были как с файлами так и с базами. Решил настроить резервное копирование на сервер с которым идет соединение ssh.
Для того чтобы система сама соединялась по ключу к ssh серверу я создал на сервере пользователя которого запер в своей домашней директории с архивными копиями и при генерации связки ключей не указывал парольной фразы.
Генерация пары ключей RSA
Механизм авторизации по ключу прост. На то место куда мы подключаемся нам надо повесить замок (публичный ключ название.pub) а сам ключик с помощью которого мы сможем подключится (приватный ключ название) держать у себя и с помощью его открывать замочек. Мало того, замок вешается не на всю систему а именно на конкретного пользователя под которым мы будем авторизовываться.
Можно не указывать путь куда мы будем устанавливать ключи и тогда они создадутся в папке по умолчанию с базовым названием. Я не буду менять путь по умолчанию для ключей а лишь буду создавать их со своим удобным мне названием.
Создадим связку ключей указав тип -t rsa, длину ключа -b 2048 и место с необходимым нам названием:
ssh-keygen -t rsa -b 2048 -f /home/user/.ssh/rsa_sevo44 = вывод команды = Generating public/private rsa key pair. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/user/.ssh/rsa_sevo44. Your public key has been saved in /home/user/.ssh/rsa_sevo44.pub. The key fingerprint is: SHA256:A9d+2cz6M1GK482oOxf/zweqt9B18WPox04m+Deczgc user@h5530 The key's randomart image is: +---[RSA 1024]----+ | | | . | | . . . . | | o . =. +| | S . oo==o| | . o*oE..| | [email protected].| | ..B.&*o| | +B.o+BO| +----[SHA256]-----+
По результату видим что создалась пара ключей с названием rsa_sevo44.
Надежно сохраните эту пару ключей чтобы в случае краха системы и потери жесткого диска вы могли подключится к необходимому ресурсу к которому открыт доступ для подключения только по ключу.
Настройка SSH сервера
Настройка сервера на всех системах Linux сводится к редактированию конфигурационного файла ssh сервера. Данный пример файла от системы CentOS 7 но и у других тоже самое:
mcedit /etc/ssh/sshd_config = необходимые параметры с пояснениями = RSAAuthentication yes PubkeyAuthentication yes PubkeyAcceptedKeyTypes ssh-dss #Путь к файлу с публичными ключами AuthorizedKeysFile %h/.ssh/authorized_keys #Отключение возможности авторизации по паролю PasswordAuthentication no #Вид публичного ключа для авторизации PubkeyAcceptedKeyTypes ssh-rsa
Не советую сразу отключать подключение по паролю. Отключите его только после проверки авторизации по ключу!
Перезагрузим сервер SSH:
systemctl restart ssh
Добавление публичного ключа RSA
Используем для добавления публичного ключа команду указав необходимый ключ и пользователя куда мы хотим повесить замок:
ssh-copy-id -i /home/user/.ssh/rsa_sevo44.pub -p 25555 [email protected] = вывод команды = /usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/user/.ssh/rsa_sevo44.pub" /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys [email protected]'s password: Number of key(s) added: 1 Now try logging into the machine, with: "ssh '[email protected]'" and check to make sure that only the key(s) you wanted were added.
После введения пароля от пользователя к которому мы хотим повесить публичный ключ он добавится в список который находится в файле /root/.ssh/authorized_keys.
Проверим добавление ключа на сервере:
cat /root/.ssh/authorized_keys = вывод команды = ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgQDCHkWoBv8b+j11IJ685m4WrYCdgx/v5bqwC3AahFyySh5yK0CV8ZJA7H6e3bbkPEI1Aw2xB6xRUS7NC4B3dGciDycMJJumX/OGpocm7A4BdrdODXfHzW5ap/WTN46/nlq7pMZH/8sa8GLzhpOv3OokUogLZFh2zZaFD4M0Hiseyw== user@h5530
Если хотите можете сверить данные с нужной строки и данными с файла публичного ключа. Данные будут идентичны.
Запоминаем пароль с помощью ssh-agent
Так как мы указали нестандартное название то без указания места нашего приватного ключа система его не будет видеть.
Для добавления ключей в список для использования во время работы на компьютере используем сервис ssh-agent.
Проверим состояние ssh-agent:
ps -C ssh-agent = вывод команды = PID TTY TIME CMD 4564 ? 00:00:00 ssh-agent
Теперь нам надо добавить нужный ключ командой:
ssh-add /home/user/.ssh/rsa_sevo44 = вывод команды = Enter passphrase for /home/user/.ssh/rsa_sevo44: вводим пароль Identity added: /home/user/.ssh/rsa_sevo44 (/home/user/.ssh/rsa_sevo44)
После перезагрузки данную процедуру придется повторить!
Посмотреть добавленные ключи можно командой:
ssh-add -l = вывод команды = 1024 SHA256:A9d+2cz6M1GK482oOxf/zweqt9B18WPox04m+Deczgc /home/user/.ssh/rsa_sevo44 (RSA)
Для удаления всех ключей применим опцию -D:
ssh-add -D = вывод команды = All identities removed.
Такую команду удобно использовать когда мы работали на чужом компьютере. Для удаления только своего ключа можно использовать опцию -d путь к ключу.
Права на ключи RSA
В папку пользователя .ssh можно добавить ранее созданные сертификаты. Достаточно выставить необходимые права и сертификат будет активен после перезагрузки системы.
Выставим необходимые права (на примере ключа с именем rsa_sevo44 пользователя local):
chmod 0600 /home/local/.ssh/rsa_sevo44 chmod 0644 /home/local/.ssh/rsa_sevo44.pub Для проверки выведем полную информацию о файлах ls -l = Необходимая часть = -rw------- 1 local local 986 июл 15 21:24 rsa_sevo44 -rw-r--r-- 1 local local 225 июл 15 21:24 rsa_sevo44.pu
Авторизация по ключу в SSH
Только после добавления необходимого ключа командой ssh-add возможно подключится по ключу!
Подключимся к нужному серверу по нестандартному порту с выводом истории подключения ssh:
ssh -p 4223442 [email protected] -v = вывод части команды с комментариями = OpenSSH_7.5p1-hpn14v12, OpenSSL 1.0.2k 26 Jan 2017 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Connecting to 10.10.0.2 [10.10.0.2] port 4223442. debug1: Connection established. debug1: Server host key: ecdsa-sha2-nistp256 SHA256:i8TBEPr+jQo0HT49dpo1zOgCX9xPUOlvFEDCU63tHQA debug1: Host '[10.10.0.2]:4223442' is known and matches the ECDSA host key. debug1: Found key in /home/user/.ssh/known_hosts:20 debug1: rekey after 134217728 blocks debug1: SSh3_MSG_NEWKEYS sent debug1: expecting SSh3_MSG_NEWKEYS debug1: SSh3_MSG_NEWKEYS received debug1: rekey after 134217728 blocks debug1: SSh3_MSG_SERVICE_ACCEPT received # В этой строчке мы видим возможные варианты подключения к серверу debug1: Authentications that can continue: publickey debug1: Next authentication method: publickey debug1: Offering RSA public key: /home/user/.ssh/rsa_sevo44 debug1: Server accepts key: pkalg ssh-rsa blen 151 debug1: Authentication succeeded (publickey). Authenticated to10.10.0.2 ([10.10.0.2]:4223442). debug1: HPN to Non-HPN Connection debug1: Final hpn_buffer_size = 2097152 debug1: HPN Disabled: 0, HPN Buffer Size: 2097152 debug1: channel 0: new [client-session] debug1: Enabled Dynamic Window Scaling debug1: Requesting [email protected] debug1: Entering interactive session. debug1: pledge: network The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Last login: Sun Jul 16 00:28:36 2017 from 10.10.0.3 root@proxmox:~#
Результат
Мы успешно можем подключатся и работать на нужном сервере без ввода пароля, но лишь до тех пор пока не перезагрузим компьютер. Конечно можно создать сертификат без ключа и тогда некоторые вещи упрощаются но вопрос в том насколько вы доверяете своему компьютеру. Обычно использую сертификат без парольной фразы в редких случаях и с ограничением возможностей пользователя под которым подключаемся.
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
sevo44.ru
Кодирование и шифрование информации с открытым ключом.
Генерация ключа RSA.
Для генерации вашей собственной уникальной пары открытый/секретный ключ заданного размера, наберите:
pgp -kg
PGP покажет вам меню рекомендуемых размеров ключа (простой уровень, коммерческий уровень или военный уровень) и запросит требуемый размер ключа (около тысячи бит). Чем длиннее ключ, тем выше степень секретности, но платить за это придется скоростью.
PGP также запросит идентификатор пользователя, что означает ваше имя. Хорошая мысль — использовать ваше имя как идентификатор пользователя, так как впоследствии меньше риск того, что другой человек использует неверный открытый ключ для шифровки сообщения, адресованного вам. В идентификаторе пользователя допускаются пробелы и знаки пунктуации.
Это поможет вам в том случае, если вы помещаете ваш адрес в электронной почте в <угловые скобки> после вашего имени, например:
Robert M. Smith <[email protected]>
Если вы не имеете адреса электронной почты, используйте ваш номер телефона или любую другую уникальную информацию, которая поможет гарантировать, что ваш идентификатор пользователя уникален.
PGP также запросит «фразу пароля» для зашиты вашего секретного ключа на случай, если он попадет в чужие руки. Никто не сможет использовать ваш файл секретного ключа без этой фразы пароля. Фраза пароля — это обычный пароль, за исключением того, что это может быть целая фраза или предложение с большим количеством слов, пробелов, знаков пунктуации, или любых других символов. Не потеряйте эту фразу пароля, так как нет никакого способа восстановить ее при утрате. Эта фраза пароля будет необходима каждый раз при использовании вашего секретного ключа. Фраза учитывает регистр, и не должна быть слишком короткой или простой настолько, что ее можно было бы предположить. Она никогда не отображается на экране. Не оставляйте ее в записанном виде нигде, где кто-либо может ее увидеть и не храните ее на вашем компьютере. Если вы не хотите использовать фразу пароля (и тогда вы просто дурак!), просто нажмите ENTER в ответ на запрос PGP.
Пара открытый/секретный ключ — это производная от множества действительно случайных чисел, полученных путем измерения интервалов времени между вашими нажатиями клавиш быстрым таймером.
Имейте ввиду, что генерация ключей RSA — ОЧЕНЬ длительный процесс. На это может потребоваться от нескольких секунд для маленького ключа на быстром процессоре, до нескольких минут для большого ключа на старой IBM PC/XT.
Сгенерированная пара ключей будет помещена в ваши каталоги открытых и секретных ключей. Вы можете позже использовать опцию -kx для извлечения (копирования) вашего нового открытого ключа из вашего каталога открытых ключей и помещать его в отдельный файл открытого ключа, который уже будет пригоден для распространения среди ваших друзей. Файл открытого ключа может посылаться вашим друзьям для включения в их каталоги открытых ключей. Конечно, вы храните ваш файл секретного ключа у себя, и вы должны включать его в ваш каталог секретных ключей. Каждый секретный ключ в каталоге защищен своей собственной фразой пароля.
Никогда не передавайте ваш секретный ключ кому-либо другому. По той же причине, не делайте пары ключей для своих друзей. Каждый должен делать их собственноручно. Всегда сохраняйте физический контроль за вашим секретным ключом и не рискуйте «засветить» его, храня на удаленном компьютере, храните его только на вашем персональном компьютере.
Поделитесь на страничкеСледующая глава >
it.wikireading.ru