Аутентификация на сетевом оборудовании через ssh с помощью публичных ключей / habr

Option 5: SSH Keys for Linux

Open a terminal window and type in the command. There are a few command line options for the ssh-keygen utility; however, for quick and dirty key creation for lab use, no options are necessary. Type in your terminal window to see all the possible options.For now, just run the command by itself.
You should run this command from your home directory. In this case as the user-id . The dialog will default to a hidden directory, . If you don’t already have keys created, accept the default file name by hitting the Enter key. Press the Enter key two more times to create a key with no passphrase. The best practice in a production environment would be to use a secure passphrase; however, we don’t need to bother with these practice labs.

The dialog will indicate that the key pair has been saved in the directory and is now ready for use.
Change to the directory, list and examine your keys.

Note in the output that there are two files, a private key: and a public key: . Keep the private key safe and don’t share its contents with anyone. The public key will be needed for various activities and can be uploaded to certain systems as well as copied and pasted to facilitate secure communications in the cloud.
Use the Linux command to list the contents of .
In some labs you will be asked to upload or copy (rcp) the public key to an instance in order to facilitate communications. So remember where the file is kept. Other labs will ask for the ‘contents’ of the key to be pasted into various dialog boxes to facilitate secure connections. Use the command and copy/paste the information from the key starting at the word “ssh-rsa” and copy everything up to the final character in the line. In the example below, you would copy from “ssh-rsa … “ and to exactly after “… -01”. Copy the key contents exactly, capturing space after the key characters may render your key invalid.

You have created a public/private SSH key pair and can utilize it in any of the Oracle OCI labs that require an SSH key.

In case you’re interested, click here for more details on SSH, a short tutorial on initiating a connection from a Linux instance with the SSH keys we just created.

Создание ключей для ssh аутентификации

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

# Просматриваем домашний каталог пользователя
ls -1a

Если по каким-то причинам каталог .ssh отсутствует, его необходимо создать, причем на обоих машинах: и на клиенте, и на сервере.

# Создаем скрытый каталог .ssh
mkdir -p ~/.ssh

На домашней машине (клиенте) генерируем ключи командой ssh-keygen.

ssh-keygen

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

Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:wzV0scS8cw8g8CaalAiVSrgYQ0yrVunTGhjs454QRIk root@home-16
The key's randomart image is:
+-------+
|==o...  ...o+.   |
|Eoo.o. . o.o+.   |
|.X +. o . =..o   |
|* * .. + + .o o  |
|o= + .o S    o o |
|o.. +    .      .|
|.. .             |
|o .              |
| o               |
+---------+

По умолчанию вышеуказанная команда создает пару 2048-битных ключей в каталоге .ssh (id_rsa и id_rsa.pub). Ключ id_rsa — закрытый (приватный), он остается на домашней машине. Ключ id_rsa.pub — открытый (публичный), он передается на удаленную машину.

Для большей надежности к ключам можно добавить секретную фразу (passphrase), но в таком случае ее нужно будет вводить при каждом подключении. Секретная фраза конечно повышает надежность аутентификации, но по сути мы придем к тому, от чего уходим — постоянному вводу ~~пароля~~ секретной фразы при каждом подключении.

При желании можно создать 4096-битные ключи (лучше не надо — это на любителя).

ssh-keygen -b 4096

Копирование открытого ключа на сервер

Добавить открытый ключ на сервер можно несколькими способами.

Примечание: На каждый сервер можно добавить неограниченное количество SSH-ключей.

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

Копирование ключа с помощью ssh-copy-id

Если на локальном компьютере установлена утилита ssh-copy-id, с её помощью вы можете быстро добавить открытый ключ на удалённый сервер. Обычно (но не всегда) утилита ssh-copy-id включена в пакет OpenSSH.

Чтобы узнать, есть ли эта утилита на локальном компьютере, просто попробуйте запустить её. Если она не установлена, на экране появится ошибка:

Вы можете установить её или воспользоваться другим методом копирования ключа.

В команде ssh-copy-id нужно указать IP-адрес или доменное имя, а также имя пользователя, для которого нужно добавить эти SSH-ключи.

Команда может вернуть:

Это значит, что локальный компьютер не узнаёт удалённый сервер, потому что ранее SSH-ключи никогда не использовались при аутентификации. Чтобы продолжить, введите yes и нажмите RETURN.

Утилита сканирует локальную учетную запись пользователя в поисках открытого ключа, id_rsa.pub. Когда она найдёт нужный файл, она запросит пользователя удалённого сервера.

Введите пароль и нажмите RETURN. Утилита подключится к аккаунту пользователя на удалённом хосте и установит открытый ключ; это происходит путём копирования содержимого файла id_rsa.pub в файл .ssh/authorized_keys в домашнем каталоге удалённого пользователя.

Если копирование прошло успешно, на экране появится:

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

Примечание: Скопировав ключ на удалённый сервер, можете переходить к разделу «Аутентификация с помощью SSH-ключей».

Копирование ключа через SSH

Если на вашем сервере нет утилиты ssh-copy-id, но есть парольный SSH-доступ к серверу, вы можете установить открытый ключ с помощью SSH-клиента.

Для этого нужно вывести открытый ключ на локальном компьютере и передать его по SSH на удалённый сервер. На удалённом сервере нужно создать каталог ~/.ssh (если такого каталога нет), а затем добавить открытый ключ в файл authorized_keys в этом каталоге. Используйте перенаправление потока >>, чтобы вставить ключ в файл authorized_keys (если ранее вы добавляли SSH-ключи на удалённый сервер, такой файл уже существует; при этом ключи не будут переписаны новыми ключами).

Если вы не изменили название файла открытого ключа по умолчанию (id_rsa.pub), используйте эту команду:

Команда может вернуть такое сообщение:

Команда запросит пароль удалённого пользователя:

Введите пароль и нажмите RETURN. Если команда выполнена успешно, она не вернёт никакого вывода. Ключ id_rsa.pub будет добавлен в файл authorized_keys.

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

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

Процесс не меняется: вам нужно взять открытый ключ на локальной машине и добавить его в .ssh/authorized_keys в домашнем каталоге удалённого пользователя.

Войдите на удалённый сервер:

При этом может появиться сообщение:

После этого будет запрошен пароль удалённого пользователя:

Создайте каталог .ssh в домашнем каталоге удалённого пользователя, если такого каталога пока что нет:

Вернитесь на локальную машину и запросите открытый SSH-ключ:

Скопируйте вывод в буфер, затем откройте файл authorized_keys в текстовом редакторе:

Вставьте в него открытый ключ, а затем сохраните и закройте файл (Esc, a, a).

Открытый ключ 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

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

Copying the public key to the remote server

This article or section needs expansion.

Once you have generated a key pair, you will need to copy the public key to the remote server so that it will use SSH key authentication. The public key file shares the same name as the private key except that it is appended with a extension. Note that the private key is not shared and remains on the local machine.

Simple method

If your key file is you can simply enter the following command.

$ ssh-copy-id remote-server.org

If your username differs on remote machine, be sure to prepend the username followed by to the server name.

$ ssh-copy-id [email protected]

If your public key filename is anything other than the default of you will get an error stating . In this case, you must explicitly provide the location of the public key.

$ ssh-copy-id -i ~/.ssh/id_ed25519.pub [email protected]

If the ssh server is listening on a port other than default of 22, be sure to include it within the host argument.

$ ssh-copy-id -i ~/.ssh/id_ed25519.pub -p 221 [email protected]

Manual method

By default, for OpenSSH, the public key needs to be concatenated with . Begin by copying the public key to the remote server.

$ scp ~/.ssh/id_ecdsa.pub [email protected]:

The above example copies the public key () to your home directory on the remote server via . Do not forget to include the at the end of the server address. Also note that the name of your public key may differ from the example given.

On the remote server, you will need to create the directory if it does not yet exist and append your public key to the file.

$ ssh [email protected]
[email protected]'s password:
$ mkdir ~/.ssh
$ chmod 700 ~/.ssh
$ cat ~/id_ecdsa.pub >> ~/.ssh/authorized_keys
$ rm ~/id_ecdsa.pub
$ chmod 600 ~/.ssh/authorized_keys

The last two commands remove the public key file from the server and set the permissions on the file such that it is only readable and writable by you, the owner.

Пример использование ssh-keygen для беспарольной аутентификации

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

Немножко терминов:

RSA (Rivest-Shamir-Adleman) является одним из первых криптосистемы с открытым ключом и широко используется для безопасной передачи данных. Безопасность основана на целочисленной факторизации, поэтому безопасный RNG никогда не нужен. По сравнению с DSA RSA быстрее проверяет подпись, но медленнее для генерации.
DSA (Digital Signature Algorithm — алгоритм цифровой подписи) является федеральным стандартом обработки информации для цифровых подписей. Безопасность зависит от дискретной логарифмической проблемы. По сравнению с RSA DSA быстрее генерирует подпись, но медленнее для проверки.

Введите нижеприведённую команду и сгенерируйте ключ, на все вопросы просто жмите Enter. Если при генерации ключей был использован пароль (вы что-то написали на вопрос Enter passphrase (empty for no passphrase)), каждый раз для при использовании приватного ключа он будет запрашиваться у пользователя.

% ssh-keygen -t dsa
Generating publicprivate dsa key pair.
Enter file in which to save the key (homeuser.sshid_dsa):
Created directory '/home/user/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in homeuser.sshid_dsa.
Your public key has been saved in homeuser.sshid_dsa.pub.
The key fingerprint is:
bb:48:db:f2:93:57:80:b6:aa:bc:f5:d5:ba:8f:79:17 [email protected]

ssh-keygen создаст пару публичного и приватного ключей, используемых для аутентификации. Приватный ключ сохраняется в ~/.ssh/id_dsa или ~/.ssh/id_rsa, а публичный в ~/.ssh/id_dsa.pub или ~/.ssh/id_rsa.pub (для ключей DSA и RSA соответственно).

Для включения аутентификации по ключам, публичный ключ должен быть помещен в файл ~/.ssh/authorized_keys на удаленном компьютере, например так:

cat ~.sshid_rsa.pub | ssh root@ip-адрес-сервера 'cat >> ~/.ssh/authorized_keys'

Это позволяет соединяться с удаленным компьютером с помощью SSH-ключей вместо паролей.

Создаст ключи с паролем fgdfgytyityirioyroryoyuouiy:

$ ssh-keygen -N fgdfgytyityirioyroryoyuouiy -t rsa -C test4@test4 -f test4 -q

Создаст ключи без пароля (пароль пустой):

$ ssh-keygen -t rsa -N "" -C test4@test4 -f test4 -q

Общие сведения о SSH и ключах

SSH — это протокол зашифрованного подключения, обеспечивающий безопасный вход в систему через незащищенные соединения. SSH — это протокол подключения по умолчанию для виртуальных машин Linux, размещенных в Azure. Хотя протокол SSH и обеспечивает зашифрованное подключение, использование паролей для соединений SSH все же сохраняет уязвимость виртуальной машины к атакам методом подбора. Мы рекомендуем подключаться к виртуальной машине по SSH с помощью пары «открытый ключ — закрытый ключ», также известных как ключи SSH.

Открытый ключ размещается на виртуальной машине с ОС Linux.
Закрытый ключ остается в локальной системе. Его нужно защищать и нельзя никому предоставлять.

При использовании клиента SSH для подключения к виртуальной машине Linux (с открытым ключом) удаленная виртуальная машина проверяет, имеется ли у клиента правильный закрытый ключ. Если у клиента есть закрытый ключ, он получает доступ к виртуальной машине.

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

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

PuTTY Unable to use key file

Для тех, кто в первый раз на лыжах PuTTY — ошибка «Unable to use key file «X:\id_rsa» (OpenSSH SSH-2 private key)» может возникать по нескольким причинам:

Неформат SSH версии в которой ковался id_rsa ключ и версии в которой он пытается использоваться, для SSH-1 и SSH-2 ключи куются в разных форматах;
Неформат id_rsa ключа для использования в PuTTY, для PuTTY нужно ключи конвертировать в .ppk формат

Если id_rsa генерировался стандартными утилитами из пакета OpenSSH (ssh-keygen -t rsa), то для его использования в SSH клиенте PuTTY он должен быть экспортирован в .ppk формат следующим образом (CMD вариант — puttygen id_rsa -o id_rsa.ppk):

Запускаем puttygen и загружаем туда наш id_rsa приватный ключ, что был создан утилитами из пакета OpenSSH, и, если хотим, ставим на него пароль:
Сохраняем приватный ключ в формате .ppk (Save private key):

Теперь после попытки авторизации по ключу нам достаточно будет ввести логин, а если ставили пароль на приватный ключ, то и пароль от приватного ключа соответственно:

login as: shaman
Authenticating with public key "imported-openssh-key"
Last login: Sat Jan  4 09:50:16 2014 from 192.168.231.1
OpenBSD 5.4 (GENERIC) #37: Tue Jul 30 12:05:01 MDT 2013
 
Welcome to OpenBSD: The proactively secure Unix-like operating system.
 
Please use the sendbug(1) utility to report bugs in the system.
Before reporting a bug, please try to reproduce it with the latest
version of the code.  With bug reports, please try to ensure that
enough information to reproduce the problem is enclosed, and if a
known fix for it exists, include that as well.
 
-bash-4.2$

-------------
 
login as: sham
Authenticating with public key "imported-openssh-key"
Passphrase for key "imported-openssh-key":
Last login: Sat Jan  4 09:50:16 2014 from 192.168.231.1
OpenBSD 5.4 (GENERIC) #37: Tue Jul 30 12:05:01 MDT 2013
 
Welcome to OpenBSD: The proactively secure Unix-like operating system.
 
Please use the sendbug(1) utility to report bugs in the system.
Before reporting a bug, please try to reproduce it with the latest
version of the code.  With bug reports, please try to ensure that
enough information to reproduce the problem is enclosed, and if a
known fix for it exists, include that as well.
 
-bash-4.2$

Пример. ssh-keygen. Ключи для Azure

Создание ssh ключей для виртуальной Linux в Microsoft Azure. Для создания и использования ключей SSH с Azure выполните описанные ниже действия.

cd .ssh
ssh-keygen -t rsa -b 2048 -N "" -C 'your-email@example' -f azuressh -q

Будут созданы два ключа azuressh и публичный azuressh.pub. Чтобы без ошибок скопировать содержимое azuressh.pub и вставить его в поле при создании VE, используйте ssh-keygen. Весь вывод, без исключений нужно копировать.

ssh-keygen -e -f azuressh.pub
---- BEGIN SSH2 PUBLIC KEY ----
Comment: "2048-bit RSA
...
---- END SSH2 PUBLIC KEY ----

Не забудьте настроить файл config, для большего удобства.

Шаг 1 — Создание пары ключей RSA

Сперва создадим пару ключей на клиентской машине (обычно, это ваш компьютер):

По умолчанию создаёт 2048-битную пару ключей RSA, которая достаточно безопасна для большинства сценариев использования (вы можете также добавить к этой команде флаг для получения 4096-битный ключей).

После ввода этой команды вы должны увидеть следующий вывод:

Нажмите Enter для сохранения пары ключей в директорию внутри вашей домашней директории или задайте другую директорию.

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

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

Вы должны увидеть следующий вывод:

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

Вы должны увидеть следующий вывод:

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

Как сменить работу с HTTPS на SSH

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

Для этого убедитесь что доступ по HTTPS, для этого выведите список remote:

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

Зайдите в репозиторий и скопируйте SSH ссылку доступа, перейдите в локальный репозиторий и удалите текущий remote origin:

и добавьте новый, последняя строка в команде это ссылка доступа SSH:

проверьте список удаленных репозиториев:

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

На этом вопросы с доступом к вашим репозиториям на гитхабе закрыт!

Чистого кода и красивых коммитов!

Key Management Requires Attention

It is easy to create and configure new SSH keys. In the default configuration, OpenSSH allows any user to configure new keys. The keys are permanent access credentials that remain valid even after the user’s account has been deleted.

In organizations with more than a few dozen users, SSH keys easily accumulate on servers and service accounts over the years. We have seen enterprises with several million keys granting access to their production servers. It only takes one leaked, stolen, or misconfigured key to gain access.

In any larger organization, use of SSH key management solutions is almost necessary. SSH keys should also be moved to root-owned locations with proper provisioning and termination processes. For more information, see how to manage SSH keys. A widely used SSH key management tool for OpenSSH is Universal SSH Key Manager.

Practically all cybersecurity regulatory frameworks require managing who can access what. SSH keys grant access, and fall under this requirement. This, organizations under compliance mandates are required to implement proper management processes for the keys. NIST IR 7966 is a good starting point.

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

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

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

Сгенерируйте на локальном компьютере пару ключей SSH, введя следующую команду:

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

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

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

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

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

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

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

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

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

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

Тест на практике

Прежде всего, нам нужен пакет OpenSSH версии 8.2 на клиентской и серверной машинах. И здесь кроется основная проблема с этим решением на момент написания этого материала (май 2020). Поскольку 8.2 — это новейшая версия, выпущенная в феврале 2020 года, во многих ОС пока еще используются предыдущие версии.

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

По состоянию на май 2020 только несколько популярных дистрибутивов Linux имеют версию OpenSSH 8.2 в своих репозиториях. Среди них Fedora 32, Ubuntu 20.04 LTS и Kali Linux.

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

Для открытых ключей действуют определенные требования к ACL, которые в среде Windows соответствуют предоставлению доступа только администраторам и системной учетной записи. При первом использовании sshd будет автоматически создана пара ключей для узла.

Важно!

Сначала необходимо установить OpenSSH Server. См. статью о начале работы с OpenSSH.

По умолчанию служба sshd настроена для запуска вручную. Чтобы запускать ее каждый раз при перезагрузке сервера, выполните следующие команды в командной строке PowerShell с повышенными привилегиями на сервере:

Так как со службой sshd не связан какой-либо пользователь, ключи узла сохраняются в папке C:\ProgramData\ssh.

Генерация ключа

Для генерации ключа будем использовать утилиту
После запуска выбираем тип ключа для генерации — SSH-2 RSA, и длину ключа — 2048 бит. После чего нажимаем Generate и крутим мышкой по окну пока не закончится генерация ключа.

Key comment — комментарий к ключу.
Key passphrase — парольная фраза к приватному ключу. (Не обязательно к заполнению)
Confirm passphrase — подтверждение парольной фразы.

Если вы хотите обезопасить себя по максимальному вы можете задать пароль для защиты приватного ключа в полях Key Passphrase и Confirm Passphrase. Но при каждом входе у вас будет запрашивать пароль который вы ввели. Это обезопасит вас если ваш приватный ключ будет похищен.

Далее сохраняем public key и private key. Приватный ключ мы будем использовать для подключения к серверу, а вот публичный ключ надо будет передать на удаленный сервер которому мы будем подключаться.

Обратите внимания на то как был сгенерирован ваш публичный ключ.

Лично у меня он был сгенерирован не совсем верно, вот пример public_key в дальнейшем при подключении через PuTTY с таким ключом могут возникнуть ошибка Server refused our key.

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