Авторизация по ключу ssh

Простое копирование ssh ключей между серверами c использованием утилиты ssh-copy-id

Традиционно администраторы решают задачу копирования ssh ключей между серверами путем копирования содержимого файла /root/.ssh/id_rsa.pub с сервера server1 на server2 в файл /root/.ssh/authorized_keys. Копируют обычно из одного терминала в другой, но есть более изящное решение — это использование утилиты ssh-copy-id, которая позволяет скопировать содержимое id_rsa.pub сервера источник (в нашем случае server1) на сервер приемник (server2) в нужный нам authorized_keys не открывая консоль сервера приемника (server2).

Исходные данные: 2 сервера с Debian 8 (server1 и server2).Задача: Организовать вход по ssh ключу с сервера server1 на server2 с правами root.

Итак сделаем все по порядку:

1. Генерируем публичный открытый и закрытый ключи, под пользователем root на server1:

ssh-keygen -t rsa

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

Мы создаем ключи впервые, поэтому предупреждения не будет, будет выведена примерно такая информация:

Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): <-- ENTER
Created directory '/root/.ssh'.
Enter passphrase (empty for no passphrase): <-- ENTER
Enter same passphrase again: <-- ENTER
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.

Вы можете защитить приватный ключ паролем и тогда чтобы попасть на сервер server2 по ssh ключу нужно будет ввести этот пароль, я настоятельно рекомендую для доступа с уровнем root ввести пароль на приватный ключ.

Ключи сгенерированы, мы можем проверить под пользователем root выполнив команду

cat ~/.ssh/id_rsa.pub

В ответ увидим примерно:

ssh-rsa AAAAB3Nz.....ywWmpl 

Теперь нужно передать публичный ключ id_rsa.pub пользователя root на server2, для этого на server1 выполняем:

ssh-copy-id -i ~/.ssh/id_rsa.pub 

Вводим пароль root от сервера server2 и ключ будет передан и записан в нужный файл authorized_keys

Важное уточнение: Чтобы передать публичный ключ на server2 под root нужно чтобы пользователю root было разрешен вход по ssh на server2, обычно при базовой установке Debian/Ubuntu вход под root по ssh разрешен, это настраивается директивой PermitRootLogin в файле /etc/ssh/sshd_config

PermitRootLogin yes — Вход под root по ssh разрешен.

PermitRootLogin no — Вход под root по ssh запрещен.

PermitRootLogin without-password — Вход под root по ssh разрешен только по ssh ключам.

PermitRootLogin forced-commands-only — Вход под root по ssh разрешен только по ssh ключам и только для выполнения заранее определенной команды, сама команда прописывается в /root/.ssh/authorized_keys в формате:

command="rsync" ssh-rsa AAAAB3N……. 

После изменения PermitRootLogin не забудьте перезапустить службу sshd командой:

service sshd restart

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

Linux, MacOS, Windows 10

Создание SSH-ключей

Запустите терминал или Windows PowerShell на вашем компьютере и выполните команду:

ssh-keygen

Вы увидите примерно следующее сообщение:

Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa):

Нажмите Enter — ключ будет сохранен в указанную директорию по умолчанию.

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

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

Процедура создания ключей завершена, ключи сохранены в директории ~/.ssh/ в файлах id_rsa и id_rsa.pub. Теперь их необходимо скопировать на сервер.

Копирование ключей на сервер

  1. Выполните в терминале следующую команду, указав вместо user имя пользователя, созданного на сервере, а вместо server — IP-адрес вашего сервера:

    ssh-copy-id user@server
     
    #Например:
    ssh-copy-id [email protected]
    
  2. В результате содержимое файла с публичным ключом id_rsa.pub будет скопировано в файл ~/.ssh/authorized_keys на сервере, и в дальнейшем вы сможете устанавливать соединение с сервером, используя команду:

    ssh user@server
     
    #Например:
    ssh [email protected]

Автономный удаленный компьютер

В настоящее время это экспериментальная функция, но она будет включена по умолчанию в следующем выпуске.

Если вы ограничены брандмауэром или ваша компания блокирует ваши виртуальные машины, и они не могут подключиться к Интернету, расширение Remote-SSH не сможет подключиться к вашей виртуальной машине, поскольку VS Code должен загрузить компонент, называемый VS Code Server, на удаленную машину.

Однако теперь вы можете решить эту проблему с помощью нового пользовательского параметра в расширении Remote-SSH. Если вы включите параметр , расширение сначала установит VS Code Server на клиент, а затем скопирует его на сервер через SCP.

Настройки клиентской машины

Для начала проверим версию SSH, запустив в терминале.

В нашем случае была установлена версия 8.1. Не проблема — 8.2 доступна для установки через Homebrew.

Итак, запускаем в своем терминале:

После установки на всякий случай убедимся, что версия теперь та, которая нам нужна:

Вывод должен быть примерно такой:

Далее можно переходить к генерированию новой пары SSH-ключей с использованием аппаратного токена U2F.

По информации с официального сайта, для поддержки FIDO-токенов в OpenSSH появились два новых типа публичных ключей: «ecdsa-sk» и «ed25519-sk» (-sk означает Security Key). Стоит отметить, что первый тип должен поддерживаться любыми U2F-токенами, а второй — не обязательно. В случае с Yubikey (как у нас) аппаратный ключ должен иметь версию прошивки 5.2.3 или новее. В нашем случае только Yubikey 5 удовлетворяет этому требованию (Yubikey 4 — нет).

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

Теперь вставим Yubikey в ноутбук и запустим следующую команду в терминале:

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

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

Результатом работы ssh-keygen будет, как и всегда, два файла — один с приватным, другой с публичным SSH-ключами. Поведение, знакомое по работе с обычными SSH-ключами. Есть только одно отличие — сохраненный на диске приватный ключ не работает, пока соответствующий ему аппаратный Yubikey не подключен к машине и вы не нажали на нем золотую кнопку!

На этом конфигурация клиента завершена, и мы можем перейти к серверной стороне.

Подключение к серверу через SSH

Мы уже выяснили, что представляет собой SSH и команды для него. Теперь установим соединение с сервером.

Естественно, перед началом надо арендовать виртуальный хостинг или VDS у одного из доступных провайдеров. У Timeweb, к примеру.

Если у вас macOS или Linux

  • Запускаем программу Terminal.
  • Вводим в консоль команду со следующим синтаксисом ssh имя пользователя@адрес сервера. В моем случае это ssh [email protected].
  • Указываем пароль суперпользователя (его отправляет хостинг-провайдер сразу после регистрации).
  • Жмем Enter.

Все. Соединение установлено, можно переходить к работе непосредственно с сервером.

Если у вас Windows

  • Скачиваем и устанавливаем программу PuTTY.
  • В строку IP-адрес вводим адрес своего VDS или виртуального хостинга.
  • Жмем на кнопку Open.
  • Вводим пароль администратора, чтобы получить доступ к управлению.

Управление протоколом SSH

У команды для подключения к удаленному PC по SSH есть две важных опции:

  1. ssh -p номер порта имя пользователя@адрес сервера — заменяет стандартный 22-й порт на иной, что положительно сказывается на безопасности и устойчивости к автоматическим хакерским атакам от ботов.
  2. ssh-copy-id -i путь до файла с ключом имя пользователя@адрес сервера— копирует ключ на сервер, чтобы вход осуществлялся без логина и пароля, а именно через ключ.

Добавление публичного ключа на удаленный сервер

На удалённой машине нам нужно создать каталог .ssh. Далее нам нужно скопировать содержимое файла публичного ключа id_rsa.pub на удалённую машину в файл ~/.ssh/authorized_keys.

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

Для это выполним команду:

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

Первый раз, когда вы заходите на сервер,SSH вас спрашивает, доверяете ли вы ключу. Если отвечаете нет, соединение закрывается. Если да — ключ сохраняется в файл ~/.ssh/known_hosts. Узнать, где какой ключ нельзя (ибо считается что это небезопасно).

Если ключ сервера поменялся (например, сервер переустановили), SSH вопит от подделке ключа

Обратите внимание, если сервер не трогали, а SSH вопит, значит вы не на тот сервер ломитесь (например, в сети появился ещё один компьютер с тем же IP, особо этим страдают всякие локальные сети с 192.168.1.1, которых в мире несколько миллионов). 

  • Ключ сервера хранится в /etc/ssh/ssh_host_rsa_key и /etc/ssh/ssh_host_rsa_key.pub. Их можно:скопировать со старого сервера на новый.
  • сгенерировать с помощью ssh-keygen. Пароля при этом задавать не надо (т.е. пустой). Ключ с паролем ssh-сервер использовать не сможет.

Старые ключи из know_hosts при этом лучше убрать, иначе ssh будет ругаться на duplicate key.

Структура конфигурационного файла

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

Каждый из разделов начинается с заголовка, определяющего хосты, которые должны соответствовать параметрам конфигурации в этом разделе. Конкретные элементы конфигурации для этого хоста определяются ниже. Здесь необходимо указать только те элементы, которые отличаются от значений по умолчанию, поскольку хост наследует эти значения для любых неопределенных элементов. Раздел определяется от одного заголовка Host до следующего заголовка Host.

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

Общий формат будет выглядеть примерно так:

Host firsthostSSH_OPTION_1 custom_valueSSH_OPTION_2 custom_valueSSH_OPTION_3 custom_valueHost secondhostANOTHER_OPTION custom_valueHost *hostANOTHER_OPTION custom_valueHost *CHANGE_DEFAULT custom_value

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

5 ответов

11

Как отмечено в других ответах, known_hosts не поддерживает диапазоны IP-адресов. Тем не менее, он поддерживает подстановочные знаки. Конечно, дикие карты не совсем то же самое, поэтому вам нужно быть очень осторожными в том, как вы используете их в IP-адресах, но в конкретном случае Github это можно сделать безопасно.

Кажется, что ситуация стала проще, поскольку вопрос был задан. Согласно официальной документации Github , используется только один диапазон IP-адресов (по крайней мере, до IPv4). Это диапазон 192.30.252.0/22. Это делает возможным 1020 возможных IP-адресов, которые удобно охватывают весь возможный диапазон для последнего октета всего в четырех разных блоках C.

Из , это то, с чем мы должны работать в known_hosts:

Используя эту информацию, мы можем построить запись с использованием подстановочного символа * для последнего октета, который соответствует всем возможным конечным точкам Github (и ТОЛЬКО этим конечным точкам) следующим образом:

Если диапазон IP, который вам нужно построить, не заполнил полный блок C и, следовательно, все возможные значения для октета, было бы невозможно использовать подстановочные знаки для такого точного соответствия.

6

Я не думаю, что вы можете легко добавлять диапазоны, но я думаю (не могу проверить это прямо сейчас), что тот же эффект можно достичь, добавив следующее в .ssh /ssh_config:

Затем вы добавите ключ в файл known_hosts под именем github-server-pool.github.com.

Предположение: хост github-server-pool.github.com не существует или никогда не подключается через SSH.

Идея этого заключается в том, что ssh будет использовать ключ github-server-pool.github.com в качестве ключа для поиска общедоступного ключа хоста для всех хостов домена github.com.

4

Нет поддержки наборов IP-адресов в файле . Вы должны будете иметь одну строку на адрес.

Несмотря на то, что часть имен хостов по умолчанию хеширована, это касается только конфиденциальности, поэтому кто-то получает ваш код Невозможно легко узнать, к каким узлам вы подключались. (Они все еще могут проверить догадки.) Вы можете использовать простое имя хоста или IP-адрес.

Обратите внимание, что это может добавить дубликаты. SSH, похоже, не имеет понятия диапазонов IP для known_hosts

Я думаю, что предположение состоит в том, что каждый из них будет иметь уникальный ключ по соображениям безопасности

SSH, похоже, не имеет понятия диапазонов IP для known_hosts. Я думаю, что предположение состоит в том, что каждый из них будет иметь уникальный ключ по соображениям безопасности.

Два способа, которые я вижу, чтобы предварительно заполнить ваши known_hosts:

  1. — Напишите короткий скрипт для итерации по всем этим адресам и либо подайте его на или файл для для чтения. может сканировать несколько хостов для каждого вызова, либо путем указания в одной строке, либо указания списка хостов.

  2. Заполните самостоятельно скриптом или редактором. Формат довольно прост, если вы используете не хешированную версию. Это:

    имя хоста, IP-адрес ssh-keytype key

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

Ничто не элегантно, но я думаю, что люди SSH полагают, что никто не будет делать то, что делает GitHub.

Привет, я нашел сценарий из Gilles весьма полезным, но только для сетей до было ограничение, я расширил сценарий для работы с большими сетями до , возможно, он будет полезен для кого-то другого.

Генерация SSH ключей в Linux/MacOS/Windows 10

Чтобы сгенерировать ключи на Linux/MacOS/Windows 10:

  1. Откройте консоль, терминал (MacOS) или командную строку (cmd.exe) для Windows 10.
  2. Выполните команду: «ssh-keygen -t rsa -b 2048».
  3. Укажите название ключа в строке «Enter file in which to save the key».

Внимание! Если не указывать директорию (например, «.ssh/» ), ключи сохранятся в «~./» (для Linux/MacOS) или в «C:Users» (для Windows 10)

  1. Нажмите «Enter».
  2. Далее задайте пароль для ключа или оставьте поле пустым и нажмите «Enter», если хотите создать ключ без пароля.
  3. Подтвердите пароль или оставьте поле пустым и нажмите «Enter» для сохранения ключа без пароля. 
  4. Ключ создан в директории по умолчанию или в той, которую вы прописали. 
  5. Публичная часть ключа будет сохранена в файле «<имя_ключа>.pub».

Используйте его для последующего добавления к виртуальной машине или физическому серверу. Файл можно открыть в текстовом виде в приложении «Блокнот».

Старые версии Windows (без OpenSSH)

Создание SSH-ключей

Запустите программу, в открывшемся окне выберите «Type of key — SSH-2 RSA и нажмите «Generate».

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

Если вы решите задать кодовую фразу, обратите внимание, что ее потребуется вводить при каждой авторизации по ключу.
Далее сохраните созданные ключи, нажав на кнопки «Save public key» и «Save private key», например, под именами id_rsa.pub и mykey.ppk. Также скопируйте и сохраните в любом текстовом файле содержимое окна «Public key for pasting…» — оно потребуется при копировании созданного ключа на сервер.

На этом процедура создания ключей завершена.

Копирование ключей на сервер

  1. Подключитесь к серверу по SSH и выполните команду для создания на сервере директории и файла для хранения ключей:

    mkdir ~/.ssh
    
    chmod 0700 ~/.ssh
    
    touch ~/.ssh/authorized_keys
    
    chmod 0644 ~/.ssh/authorized_keys
  2. Откройте созданный файл с помощью текстового редактора:

    nano ~/.ssh/authorized_keys
  3. Вставьте в него скопированный на предыдущем шаге текст public key из окна PuTTYgen и сохраните файл.
  4. Запустите pageant — его иконка появится в трее. Щелкните по ней правой кнопкой мыши и выберите Add Key.
  5. В открывшемся окне укажите путь к приватному ключу mykey.ppk, сохраненному ранее, и нажмите Open. Если при создании ключа вы указывали кодовую фразу, pageant запросит ее на данном этапе.
  6. Для проверки работы авторизации по ключу снова запустите утилиту PuTTY, подключитесь к вашему серверу и введите свой логин. Если все настроено корректно, вы увидите подобный вывод в окне консоли:

    Authenticating with public key "rsa-key-20151220" from agent

Загрузка ключа на сервер

Когда генерация ключей завершена, нам осталось только загрузить ключ на сервер. Для загрузки ключа можно использовать несколько способов. В некоторых случаях вы можете указать ключ в панели управления сервером, например, сPanel или любой другой. Но мы такой способ рассматривать не будем. Мы рассмотрим ручные способы.

Самый простой способ скопировать ключ на удаленный сервер — это использовать утилиту ssh-copy-id. Она тоже входит в пакет программ OpenSSH. Но для работы этого метода вам нужно иметь пароль доступа к серверу по SSH. Синтаксис команды:

При первом подключении к серверу система может его не распознать, поэтому вам нужно ввести yes. Затем введите ваш пароль пользователя на удаленном сервере. Утилита подключится к удаленному серверу, а затем использует содержимое ключа id.rsa.pub для загрузки его на сервер в файл ~/.ssh/authorized_keys. Дальше вы можете выполнять аутентификацию с помощью этого ключа.

Если такой способ по какой-либо причине для вас не работает, вы можете скопировать ключ по ssh вручную. Мы создадим каталог ~/.ssh, а затем поместим наш ключ в файл authorized_keys с помощью символа >>, это позволит не перезаписывать существующие ключи:

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

Если вы не захотели создать ssh ключ с доступом по паролю, то вы сразу же будете авторизованы, что очень удобно. Иначе, сначала вам придется ввести фразу-пароль для расшифровки ключа.

Как просмотреть ключ SSH

Первый метод, который вы можете использовать для просмотра своего ключа SSH, – это использовать простую команду cat. Эта команда распечатает содержимое файла, которое вы можете скопировать и вставить на удаленный хост. По умолчанию ключи SSH хранятся в /home/$USER/.ssh

Для просмотра содержимого:

cd ~/.ssh
cat id_rsa.pub

Приведенная выше команда распечатает содержимое вашего открытого ключа SSH. Ниже приведен пример ключа:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQC4P7J4iUnK+lbKeBxEJqgBaapI6/tr2we9Ipr9QzYvAIzOyS396uYRhUldTL0sios0BlCes9k9FEU8/ZFABaPlvr/UcM/vBlVpEv1uCkq1Rg48bK8nWuCBcLmy2B+MUoiXT/0W51qT2fSYRUk0fafnxvBnqRidRdOpRLi48CzvsSua+tU5AciEuYJ+L4X32UF2sHe6o+GzAyItK5ZzpneiEPfoHUSJ4N7+wUcrTI52NPrHmH11jzLPpMHxoqiDBzF2IIVxxU1GSioGAij7T5Sf6aWDOnBHnpeJBFujChg+p2WPlha+B2NaCt25eBtwPMMFQqmJ38xoPr1BCtF6ViOR1e2e7rk/+XMLuY67U8mawhJbl6IqfzRtn5C8dP6vGqMg30kW9vIp4GqlbGLMeAyuBsA45rNnVqxtiMXdKcHPvA+Mmbm+7YSXzoyQcuRUzJY9K+Y+ty7XQP09HGvT7bvtFvC5B9wWAqt5qgmTToLp7qHLCXK+m/6rpJp7d57tGv0= ubuntu@UBUNTU

Другой метод, который вы можете использовать для просмотра содержимого вашего SSH-ключа, – это использование инструмента аутентификации Open-SSH с помощью команды, показанной ниже:

ssh-agent sh -c "ssh-add; ssh-add -L"

Эта команда запросит у вас пароль аутентификации для парольной фразы, если она назначена, как показано ниже:

Enter passphrase for /home/ubuntu/.ssh/id_rsa:
Identity added: /home/ubuntu/.ssh/id_rsa (ubuntu@CSALEM)
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQC4P7J4iUnK+lbKeBxEJqgBaapI6/tr2we9Ipr9QzYvAIzOyS396uYRhUldTL0sios0BlCes9k9FEU8/ZFABaPlvr/UcM/vBlVpEv1uCkq1Rg48bK8nWuCBcLmy2B+MUoiXT/0W51qT2fSYRUk0fafnxvBnqRidRdOpRZtxMLOj7Sua+tU5AciEuYJ+L4X32UF2sHe6o+GzAyItK5ZzpneiEPfoHUSJ4N7+wUcrTI52NPrHmH11jzLPpMHxoqiDBzF2IIVxxU1GSioGAij7T5Sf6aWDOnBHnpeJBFujChg+p2WPlha+B2NaCt25eBtwPMMFQqmJ38xoPr1BCtF6ViOR1e2e7rk/+XML3ypZU8mawhJbl6IqfzRtn5C8dP6vGqMg30kW9vIp4GqlbGLMeAyuBsA45rNnVqxtiMXdKcHPvA+Mmbm+7YSXzoyQcuRUzJY9K+Y+ty7XQPmwYgvLo7G78vC5B9wWAqt5qgmTToLp7qHLCXK+m/6rpJp7d57tGv0= ubuntu@UBUNTU

Генерация SSH ключей в Личном кабинете «G-Core Labs Cloud»

Для создания SSH ключа из личного кабинета, следуйте описанным ниже шагам.

  1. В панели управления «G-Core Labs Cloud» перейдите в раздел «Ключи SSH».
  2. Нажмите «Сгенерировать ключ».  
  3. Введите название ключа и нажмите «Создать SSH ключ». 

Важно! Допускается использование символов только латинского алфавита, нижнего подчеркивания, пробелов и точек. Длина имени должна быть от 3 до 63 символов

  1. Ключ сгенерируется и отобразится в списке SSH ключей, его открытая часть уже будет храниться в системе, а закрытый ключ будет загружен на устройство в папку по умолчанию.
  2. Для просмотра закрытого ключа найдите его на устройстве и откройте с помощью приложения «Блокнот».

Open SSH

Генерация пары ключей осуществляется утилитой ssh-keygen на компьютере под управлением Linux, с которого выполняется подключение к серверу. При этом в каталоге пользователя образуется 2 ключа:

  1. ~/.ssh/id_rsa — секретный
  2. ~/.ssh/id_rsa.pub — публичный

Публичный ключ должен хранится на сервере в ~/.ssh/authorized_keys. При подключении к серверу пользователя, в каталогах которого лежат соответствующие ключи (в ~/.ssh/id_rsa), нет необходимости вводить пароль. В файле ~/.ssh/authorized_keys может последовательно содержаться несколько ключей для доступа к данному серверу под данным пользователем с нескольких серверов.

Создаем пару ключей с помощью утилиты ssh-keygen:

user@hostname:~$ ssh-keygen -t rsa -b 4096

где:

  • -t – тип ключа. Доступные значения – rsa1, rsa, dsa, ecdsa
  • -b – количество бит ключа (по умолчанию для rsa – 2048).

Пароль для ключа (passphrase) в данном случае не используем (при запросе passphrase во время генерации пары ключей – просто жмем Enter). Проверяем наличие ключей в /home/user/.ssh/. Копируем публичный ключ на удаленную систему с помощью утилиты ssh-copy-id:

user@hostname:~$ ssh-copy-id -i ~/.ssh/id_rsa user@servername
user@servername's password: 
Now try logging into the machine, with "ssh 'user@servername'", and check in:

  ~/.ssh/authorized_keys

to make sure we haven't added extra keys that you weren't expecting.

При следующем логине по ssh — пароль уже не потребуется.

Настройка ssh на сервере для авторизации по сертификатам

Здесь все просто. Во всех известных мне дистрибутивах авторизация по сертификатам уже настроена, нужно просто добавить этот сертификат на сервер. Сделаем это.

# mkdir ~/.ssh
# chmod 0700 ~/.ssh
# touch ~/.ssh/authorized_keys
# chmod 0644 ~/.ssh/authorized_keys

В файл authorized_keys вставляйте скопированный ключ из окна puttygen. Сохраняйте и подключайтесь с помощью сертификата. В putty сертификат нужно указать в разделе Connection -> SSH -> Auth.

Выбрать нужно приватный ключ, у которого расширение .ppk. Напоминаю, что на сервер мы отправили публичный ключ. Этот ключ можно использовать на множестве серверов, так что нет необходимости для каждого сервера генерировать новую пару ключей. Везде можно использовать один и тот же.

Теперь можно подключаться, необходимости перезапускать службу ssh нет.

Как можно сохранить свой SSH-ключ на аппаратном токене FIDO2

Процитируем официальную документацию OpenSSH (в нашем переводе):

Итак, если у вас есть FIDO2-совместимый токен (в нашем случае это Yubikey 5), вы можете использовать ssh-keygen с параметром при генерации пары ключей SSH. В дальнейшем вы сможете извлечь ваши SSH-ключи из токена и записать на диск в виде файлов. Для этого нужно подключить ваш Yubikey (или тот токен, который вы используете) и запустить команду .

Команда целиком может выглядеть примерно так:

Этот подход позволяет вам быть уверенным что ваши SSH-ключи у вас с собой всегда, когда с собой ваш Yubikey или другой аппаратный токен. Вам не нужно беспокоиться о копировании приватных и публичных SSH-ключей (в виде файлов) между разными машинами. Это довольно удобно, но нужно учитывать и связанные с этим риски.

Итак, если вам нужно начать работу в новом окружении (на новой машине), достаточно подключить ваш Yubikey и запустить команду

Эта команда извлечет все записанные SSH-ключи (как приватные, так и публичные!) и сохранит в виде файлов на диске.

Во-первых, если вы решите хранить свои SSH-ключи на токене, необходимо защитить его с помощью PIN-кода. Иначе любой, кто получит доступ к токену, сможет использовать и ваши SSH-ключи.

Для ключей Yubikey можно использовать официальное приложение Yubikey Manager.

Если FIDO2 PIN установлен, любой, кто попытается извлечь SSH-ключи из вашего токена, должен будет ввести код. Мы настоятельно рекомендуем установить PIN, если вы планируете воспользоваться функцией резидентных SSH-ключей.

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

Мы рекомендуем защищать приватные ключи паролем даже в случае использования с безопасными аппаратными токенами.

6 ответов

60

Пожалуйста, не удаляйте весь файл known_hosts, как рекомендовано некоторыми людьми, это полностью исключает точку предупреждения. Это функция безопасности, которая предупреждает вас, что может произойти человек в средней атаке.

Я предлагаю вам определить, почему он думает, что что-то изменилось, скорее всего, обновление SSH изменило ключи шифрования из-за возможной дыры в безопасности. Затем вы можете очистить эту конкретную строку от файла known_hosts:

Эта строка d elets 377, как показано после двоеточия в предупреждении:

В качестве альтернативы вы можете удалить соответствующий ключ, выполнив следующие

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

19

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

В вопросе говорится: «Как удалить строгую проверку ключей RSA в SSH и в чем проблема?»

Проблема в том, что, как сообщается некоторыми другими, изменение хоста возможно из-за переустановки сервера (наиболее распространенный сценарий). И рекомендуемое решение — действительно удалить удаляющий ключ из файла .ssh /authorized_keys с встроенным sed.

Однако я не видел, чтобы какие-либо ответы касались определенной части вопроса « Как удалить строгую проверку ключей RSA в SSH ».

Вы можете удалить проверку StrictHostKey в файле конфигурации ssh, обычно хранящемся в .

Пример блока Host приведен ниже:

Конкретно добавленная строка является последней версией , которая делает именно это. В зависимости от вашего конкретного сценария это может быть полезно для вас, например, запустить несколько виртуализированных контейнеров на выделенном сервере, всего на несколько ips, остановить и запустить другой экземпляр на одном и том же ip.

9

Другой способ удалить StrictHostKeyChecking, когда вам нужно сделать это только для одного сервера:

5

Прежде всего, это ваша машина? Вы сознательно изменили ключи хоста? Если бы не я, я был бы очень обеспокоен тем, что что-то изменило эти данные.

Во-вторых, включите отладку ssh,

и посмотрите, что вам скажет, попробуйте найти в /var /log /secure и /var /log /messages на сервере, к которому вы пытаетесь подключиться для подсказок, sshd дает хорошие сообщения об ошибках.

В-третьих, эта машина подключена к Интернету? Если вы действительно разрешаете вход в систему root?

3

Вы получаете это, потому что что-то изменилось (например, новый сетевой адаптер, новый IP-адрес, изменение на серверном программном обеспечении и т. д.). В фокусе безопасности есть хорошая статья о защите ключа хоста SSH .

Просто удалите ключ (используя SFTP или аналогичный) с сервера, отредактировав файл и примите новое при следующем подключении.

Ваше соединение может быть потеряно из-за установки StrictHostKeyChecking. См. этот поток для аналогичной проблемы.

2

В качестве «хоста» [в широком смысле это может быть все: от переустановки /мультизагрузки до совершенно другого компьютера с IP-адресом, к которому вы подключили раньше, например], кажется, что клиент ssh изменился, это давая вам ошибку.

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

Вполне возможно иметь два разных ключа, перечисленных в known_hosts для определенного имени хоста или IP-адреса; давая вам 2 альтернативы в зависимости от того, считаете ли вы, что вам может понадобиться «старый» ключ, который в настоящее время хранится в known_hosts

Либо удалите конкретный ключ, на который он ссылается, в l377 известных_hosts для OP, либо сохраните оба

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

  1. Изменить known_hosts, чтобы добавить # в начале «старой» записи, на которую ссылаются в known_hosts временно
  2. Подключите , согласитесь на приглашение добавить новый ключ «автоматически»
  3. Затем заново отредактируйте known_hosts, чтобы удалить #

больше ответов на «Добавить правильный ключ хоста в known_hosts» /несколько ключей хоста ssh для имени хоста?

Как сгенерировать SSH-ключ

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

В Linux используйте следующую команду для создания пары ключей SSH:

ssh-keygen

Приведенная выше команда потребует от вас ввода информации для настройки и создания ключей. Если вы находитесь в незащищенных сетях или критических системах, обязательно зашифруйте свои ключи парольной фразой.

Generating public/private rsa key pair.
Enter file in which to save the key (/home/ubuntu/.ssh/id_rsa):
Created directory '/home/ubuntu/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/ubuntu/.ssh/id_rsa
Your public key has been saved in /home/ubuntu/.ssh/id_rsa.pub
The key fingerprint is:
SHA256:hVkOnzk7nLWx3j4vqLv/B83tYN7w3juLAbFw610xh7Q ubuntu@CSALEM
The key's randomart image is:
+-------+
|        . .   .  |
|         B o . o |
|        o.Boo Eo.|
|         oo=++  +|
|        S =+o  +.|
|          .oo.* +|
|           ..*.B |
|            ..*.*|
|          +=.ooOB|
+---------+

Примечание
Для использования команды ssh-keygen в вашей системе должен быть установлен пакет OpenSSH.

Рейтинг
( Пока оценок нет )
Понравилась статья? Поделиться с друзьями:
Все про сервера
Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: