What is rsa and rsa in linux

Как сгенерировать открытый/закрытый SSH-ключ в Linux

Если вы часто используете ssh для подключения к удаленному хосту, одним из способов обеспечения безопасности соединения является применение открытого/закрытого SSH-ключа, так как при этом по сети не передается никакой пароль и система устойчива к атакам методом «грубой силы».
Создать открытый/закрытый SSH-ключ в Linux очень просто.

1. Откройте терминал. Введите:

Альтернативой является использование для создания ключа технологии DSA (Digital Signing Algorithm):

Примечание: Было много дебатов о том, что безопаснее, DSA или RSA. По моему мнению, если только вы не любитель копаться в технических подробностях, большой разницы между этими технологиями нет. Обе работают хорошо.

2. На нижеследующем скриншоте вы видите предложение указать место для сохранения ключа. По умолчанию это папка .ssh в вашей домашней директории. Для того, чтобы согласиться с настройками по умолчанию, просто нажмите «Enter».

3. Далее, вас попросят ввести идентификационную фразу. Это не идентификационная фраза для соединения с удаленным хостом. Это идентификационная фраза для разблокировки закрытого ключа, поэтому она не поможет вам получить доступ к удаленному серверу, даже если на нем хранится ваш закрытый ключ. Ввод идентификационной фразы не является обязательным. Чтобы оставить ее пустой, просто нажмите «Enter».

4. Теперь ваши открытый и закрытый SSH-ключи должны быть сгенерированы. Откройте файловый менеджер и перейдите в директорию .ssh. Вы должны увидеть два файла: id_rsa и id_rsa.pub.

5. Загрузите файл id_rsa.pub в домашнюю директорию вашего удаленного хоста (предполагается, что удаленный хост работает под Linux). Подключитесь к удаленному хосту с помощью SSH и переместите открытый ключ в его целевую директорию с помощью команд:

6. Оставаясь на удаленном хосте, откройте конфигурационный файл SSH:

Убедитесь, что следующие атрибуты имеют корректные значения:

Нажмите «ctrl + o», чтобы сохранить изменения, затем «ctrl + x», чтобы закрыть файл.

7. И последнее, перезапустите сервер SSH на удаленном хосте:

На этом все. Теперь вы можете соединяться со своим удаленным хостом с помощью команды:

Источник

Linux Generate RSA SSH Keys

H ow do I generate ssh RSA keys under Linux operating systems?

You need to use the ssh-keygen command as follows to generate RSA keys (open terminal and type the following command):
ssh-keygen -t rsa
OR
ssh-keygen
Sample outputs:

The -t type option specifies the type of key to create. The possible values “rsa” or “dsa” for protocol version 2. The $HOME/.ssh stores the following two files:

• $HOME/.ssh/id_rsa – Your private RSA key
• $HOME/.ssh/id_rsa.pub – Your public RSA key

Please do not share keys file with anyone else. You can upload keys to remote server as follows:
ssh-copy-id userName@server2.nixcraft.net.in
Finally, you can login to remote server as follows:
ssh userName@server2.nixcraft.net.in
scp file.txt userName@server2.nixcraft.net.in:

• No ads and tracking
• In-depth guides for developers and sysadmins at Opensourceflare✨
• Join my Patreon to support independent content creators and start reading latest guides:
  • How to set up Redis sentinel cluster on Ubuntu or Debian Linux
  • How To Set Up SSH Keys With YubiKey as two-factor authentication (U2F/FIDO2)
  • How to set up Mariadb Galera cluster on Ubuntu or Debian Linux
  • A podman tutorial for beginners – part I (run Linux containers without Docker and in daemonless mode)
  • How to protect Linux against rogue USB devices using USBGuard

Join Patreon ➔

See also:

• Howto Linux / UNIX setup SSH with DSA public key authentication (password less login)
• sshpass: Login To SSH Server / Provide SSH Password Using A Shell Script
• keychain: Set Up Secure Passwordless SSH Access For Backup Scripts

🐧 Get the latest tutorials on Linux, Open Source & DevOps via

Источник

Linux.yaroslavl.ru

Автор: Инга Захарова, arlantine@lnx.ru
Опубликовано: 8.6.2002

Перевод статьи Дэниэла Робинса (Daniel Robbins) OpenSSH key management, Part 1

Из этой серии статей вы узнаете, как действует RSA и DSA-аутентификация и как правильно настроить беспарольную аутентификацию. В первой статье цикла Дэниел Робинс уделяет внимание представлению протоколов аутентификации RSA и DSA и демонстрирует, как применять их для работы в сети.

Многие из нас используют замечательную программу OpenSSH (смотрите раздел Источники далее в этой статье) в качестве защищенной шифрованной замены архаичных telnet и rsh. Одной из самых захватывающих особенностей OpenSSH является ее способность аутентифицировать пользователей посредством протоколов аутентификации RSA и DSA, в основе которых лежит пара комплементарных числовых «ключей». Одной из самых притягательных сторон RSA- и DSA-аутентификации является их потенциальная способность устанавливать соединения с удаленными системами без указания пароля . Поскольку это очень заманчиво, новые пользователи OpenSSH зачастую настраивают RSA/DSA второпях, в результате получая беспарольные входы, но при этом открывая огромную дыру.

Что такое RSA/DSA-аутентификация?

SSH, и в особенности OpenSSH (свободно распространяемая версия SSH) – просто невероятная утилита. Так же, как и в telnet или rsh , ssh -клиент может быть использован для входа на удаленную машину. Все, что требуется от этой удаленной машины – использовать sshd , серверный процесс ssh . Но в отличие от telnet , протокол ssh является безопасным. Он использует специальные алгоритмы для шифрования потоков данных, обеспечивая неприкосновенность и целостность потока данных, и выполняет аутентификацию надежным и безопасным способом.

Хотя ssh действительно замечательная программа, среди функций ssh существует определенная компонента, часто обделяемая вниманием и катастрофически неиспользуемая, или просто недопонятая. Эта компонента – система ключей аутентификации RSA/DSA для OpenSSH, являющаяся альтернативой стандартной системе аутентификации безопасных паролей, которая в OpenSSH используется по умолчанию.

Протоколы RSA и DSA-аутентификации для OpenSSH имеют в основе два специально созданных криптографических ключа, носящие названия «личный ключ» и «публичный ключ» . Преимущество использования этой основанной на ключах системы аутентификации в том, что в большинстве случаев они позволяют устанавливать безопасные соединения без необходимости набирать пароль вручную.

Хотя основанные на ключах протоколы аутентификации относительно безопасны, в случае, если пользователь воспринимает быстрый вход как всего лишь удобное приспособление и не полностью осознает ее прямую связь с безопасностью, то могут возникнуть проблемы. В данной статье мы внимательно рассмотрим как правильно использовать протоколы RSA- и DSA-аутентификации и при этом не подвергать собственную безопасность ненужному риску. В своей следующей статье я продемонстрирую вам, как использовать ssh-agent для кэширования дешифрованных личных ключей, и представлю вашему вниманию keychain – программу-надстройку над ssh-agent который обеспечивает целый ряд полезных преимуществ, не жертвуя при этом безопасностью. Если вы всю жизнь мечтали докопаться до сути самых крутых примочек, тогда продолжайте читать.

Как работают ключи RSA/DSA.

Вот общий обзор принципов работы ключей RSA/DSA. Начнем с гипотетического сценария, в котором мы хотим использовать RSA-аутентификацию, дабы позволить локальной рабочей станции под Linux (назовем ее localbox ) открыть shell на удаленной машине remotebox нашего поставшика интернет услуг (ISP). И теперь, при попытке установить соединение с remotebox используя клиент ssh , мы получаем следующее уведомление:

Вот пример того, как ssh по умолчанию управляет аутентификацией. А именно, она запрашивает пароль учетной записи drobbins на remotebox . Если мы наберем пароль для remotebox , ssh задействует собственный безопасный протокол аутентификации паролей, который передаст наш пароль дальше на remotebox для подтверждения. Однако в отличие от того, как это происходит в telnet , здесь наш пароль зашифрован, таким образом тому, кто прослушивает наше соединение, не удастся его перехватить. Далее remotebox произведет аутентификацию поступившего от нас пароля с собственной базой данных паролей, и в случае успешного отождествления нам будет позволено войти и shell машины remotebox выдаст сообщение с приветствием. И хотя метод аутентификации осуществляемый ssh по умолчанию вполне надежен, все же RSA/DSA-аутентификация раскрывает кое-какие дополнительные возможности.

Однако, в отличие от осуществляемой ssh надежной «парольной» аутентификации, RSA-аутентификация требует некоторой первоначальной настройки. Нам нужно только один раз выполнить пункты этой первоначальной настройки. После этого RSA-аутентификация между localbox и remotebox станет абсолютно беспроблемной процедурой. Чтобы настроить RSA-аутентификацию, нам прежде всего потребуется генерировать пару ключей. Один личный и один публичный. Эти два ключа обладают весьма интересными особенностями. Публичный ключ можно использовать для шифрования сообщений и только владелец личного ключа сможет это сообщение дешифровать. Публичный ключ используется только для шифрования , а личный ключ используется только для расшифровки сообщений, закодированных при помощи соответствующего публичного ключа. Протоколы RSA- (и DSA-) аутентификации используют специфические особенности парных ключей для осуществления безопасной аутентификации, где нет необходимости пересылать конфиденциальную информацию через сеть.

Для того чтобы RSA- или DSA-аутентификация заработала, выполняем один единственный пункт настройки. Копируем наш публичный ключ через сеть на remotebox . «Публичным» этот ключ назван не без оснований. Поскольку он может быть использован только для шифрования наших сообщений, не стоит особенно беспокоиться, если он попадет в чужие руки. Теперь, когда публичный ключ скопирован через сеть на remotebox и помещен в специальный файл (

/.ssh/authorized_keys), sshd remotebox ‘а сможет его обнаружить, и мы готовы использовать RSA-аутентификацию для входа на remotebox . Чтобы это сделать, мы просто как всегда набираем ssh drobbins@remotebox на консоли localbox . Однако теперь ssh сообщает sshd remotebox ‘а, что она хочет использовать протокол аутентификации RSA. А дальше происходит совсем интересное. sshd remotebox ‘а генерирует случайное число и зашифровывает его при помощи публичного ключа, скопированного нами ранее. Затем он отправляет это случайное число в зашифрованном виде обратно к ssh на localbox ‘е. В свою очередь ssh нашей машины использует свой личный ключ для расшифровки этого случайного числа, которое затем отправляет обратно на remotebox в качестве утверждения: «Видишь, у меня на самом деле есть соответствующий личный ключ. Я смогла успешно расшифровать твое сообщение!» В итоге sshd делает вывод, что нам можно позволить войти, поскольку у нас есть соответствующий личный ключ. Таким образом наличие у нас соответствующего личного ключа обеспечивает нам доступ к remotebox .

Два нюанса.

Существует два немаловажных нюанса, касающихся RSA/DSA-аутентификации. Первое – то, что нам в действительности понадобится генерировать всего лишь пару ключей. Далее мы можем скопировать публичный ключ на удаленные машины, к которым хотим получить доступ, и все они будут успешно аутентифицировать нас по нашему личному ключу. Другими словами, нам не понадобится своя пара ключей для каждой системы, к которой мы хотим получить доступ. Будет достаточно одной единственной пары.

Второй нюанс заключается в том, что ваш личный ключ не должен попасть в чужие руки . Личный ключ – единственная вещь, открывающая доступ к вашим удаленным системам, и любому использующему ваш личный ключ обеспечиваются точно такие же как у вас права. Мы не собираемся давать незнакомцам ключи от нашего дома, и точно так же нужно защитить свой личный ключ от несанкционированного использования. В мире битов и байтов это означает, что никто не должен иметь возможности прочесть или скопировать ваш личный ключ.

Конечно, разработчики ssh осознают важность личного ключа, и в ssh и генераторе ключей ssh-keygen предпринят ряд мер безопасности для того чтобы не нарушался режим использования личного ключа. Во-первых, ssh настроен таким образом, чтобы выводить большое предупредительное сообщение, если кто-либо кроме вас имеет доступ «чтение» к файлу личного ключа. Во-вторых, когда вы при помощи ssh-keygen создаете вашу пару ключей личный/публичный, ssh-keygen попросит вас ввести ключевую фразу. Если вы это делаете, то ваш личный ключ будет зашифрован с использованием этой ключевой фразы, таким образом даже если ключ будет похищен, он будет абсолютно бесполезен в руках того, кто этой фразы не знает. Вооруженные этим знанием, давайте посмотрим как настроить ssh на использование протоколов RSA- и DSA-аутентификации.

ssh-keygen при «ближайшем рассмотрении».

Первый шаг настройки RSA-аутентификации начинается с генерирования пары ключей публичный/личный. RSA-аутентификация – оригинальная версия ключевой аутентификации ssh , поэтому RSA будет работать с любой версией OpenSSH, кроме того я рекомендую вам установить самую свежую доступную версию (на момент, когда была написана эта статья, это openssh-2.9_p2). Генерируйте пару ключей RSA как показано ниже:

Когда ssh-keygen запрашивает местонахождение ключа по умолчанию, нажимаем ввод в знак принятия указанного по умолчанию /home/drobbins/.ssh/identity. ssh-keygen будет хранить личный ключ под приведенным выше паролем, а публичный ключ будет храниться рядом с ним в файле с именем identity.pub.

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

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

Быстрый компромисс.

Если вы задаете ключевую фразу, это позволяет ssh-keygen защитить ваш личный ключ от злоумышленного использования, но также создает и некоторое неудобство. Теперь, каждый раз, когда вы пытаетесь, используя ssh установить соединение с учетной записью drobbins@remotebox , ssh просит вас ввести ключевую фразу, чтобы расшифровать ваш личный ключ и использовать его для RSA-аутентификации. Еще раз напоминаю, что мы не будем вводить пароль для учетной записи drobbins на remotebox , мы наберем ключевую фразу, необходимую для расшифровки личного ключа на локальной машине. Поскольку наш личный ключ зашифрован, ssh-клиент позаботится обо всем остальном. Хотя механизмы использования пароля для удаленного доступа и ключевой фразы в RSA абсолютно различны, на практике нас по-прежнему приглашают набрать в ssh «условную фразу».

И вот именно здесь люди вступают на опасный путь «быстрого компромисса». В большинстве случаев люди создают незашифрованные личные ключи, поэтому им не приходится вводить пароль. Таким образом они просто вводят команду ssh , сразу же аутентифицируются посредством RSA (или DSA) и входят в систему.

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

Знаю, о чем вы подумали. Беспарольная аутентификация, несмотря на несколько повышенную степень риска, все же кажется воистину привлекательной. Я полностью с этим согласен. Но существует лучший выход! Оставайтесь со мной, и я покажу вам, как получить все преимущества беспарольной аутентификации, не подвергая риску безопасность вашего личного ключа. В своей следующей статье я покажу вам, как мастерски использовать ssh-agent (ту самую штуку, которая в первую очередь делает возможной безопасную беспарольную аутентификацию). А сейчас давайте приготовимся использовать ssh-agent для настройки RSA- и DSA-аутентификации. Вот вам пошаговые указания на этот счет.

Генерирование пары RSA-ключей.

Для того, чтобы настроить RSA-аутентификацию понадобится один раз выполнить действие по созданию пары ключей личный/публичный. Делаем это, набирая:

Подтвердите месторасположение ключа по умолчанию (как правило, для публичного ключа это

/.ssh/identity.pub) в строке предложения и снабдите ssh-keygen надежной ключевой фразой. Когда ssh-keygen завершит процесс, у вас в наличии будет публичный ключ, а также зашифрованных с помощью ключевой фразы личный ключ.

Установка публичного ключа RSA.

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

До тех пор, пока RSA-аутентификация не будет полностью настроена, строка приглашения будет требовать от нас ввести пароль для доступа к remotebox . Сделайте это. Теперь войдите в систему remotebox и добавьте публичный ключ в файл

/.ssh/authorized_keys вот таким образом:

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

Ура, настройка RSA-аутентификации завершена! Если вы не получили приглашения ввести ключевую фразу, вам следует кое-что проверить. Прежде всего попытайтесь войти в систему, набирая ssh -1 drobbins@remotebox . Таким образом вы укажете ssh использовать только версию 1 ssh-протокола, вам может это потребоваться, если по какой-либо причине удаленная система по умолчанию настроена использовать DSA-аутентификацию. Если это не работает, убедитесь, что у вас нет строки, которая считывает запрет RSA-аутентификации из вашего файла /etc/ssh/ssh_config. Если такая есть, отметьте ее, поставив в начале «#». В противном случае попытайтесь связаться с администратором системы remotebox и удостоверьтесь, что RSA-аутентификация разрешена к использованию на выходе и соответствующие настройки имеются в файле /etc/ssh/sshd_config.

Генерирование DSA-ключей.

Если RSA-ключи используются протоколом ssh версии 1, то DSA-ключи используются для 2-го уровня и обновленной версии протокола. Любая из современных версий OpenSSH должна поддерживать работу как RSA так и DSA ключей. Генерирование DSA-ключей посредством ssh-keygen для OpenSSH можно осуществить аналогично той же процедуре в RSA следующим образом:

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

/.ssh/id_dsa.pub вполне подойдет. Генерирование ключей DSA завершено, и теперь самое время установить публичный DSA-ключ в удаленной системе.

Установка публичного DSA-ключа.

И снова мы сталкиваемся с тем, что установка публичного DSA-ключа практически идентична такой же процедуре в RSA. Для DSA мы скопируем наш файл

/.ssh/id_dsa.pub в удаленную систему remotebox и добавим его в файл

/.ssh/authorized_keys2 в этой системе. Обратите внимание, что этот файл имеет иное имя, чем файл authorized_keys в RSA. По окончании настройки мы должны получить возможность входить в систему remotebox , набирая ключевую фразу для личного DSA-ключа, вместо того чтобы вводить текущий пароль для входа в remotebox .

В следующий раз.

Теперь у вас имеется работающая RSA- или DSA-аутентификация, но вам все еще приходится вводить ключевую фразу для каждого нового соединения. В моей следующей статье вы увидите, как использовать ssh-agent – действительно классную систему, позволяющую устанавливать соединения без предоставления пароля, но при этом также позволяющую хранить наши личные ключи зашифрованными на диске. Я также представлю вашему вниманию keychain – весьма полезного клиента ssh-agent ‘а, который делает ssh-agent еще более надежным, удобным и прикольным. А пока ознакомьтесь с полезными источниками, приведенными ниже, дабы войти в курс дела.

Источник