Single sign-on для ssh своими руками / блог компании itsumma / хабр

Настройка 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

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

Для генерации ключа будем использовать утилиту
После запуска выбираем тип ключа для генерации — 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.

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

Показ публичного ключа из приватного

Опция -y прочитает файл OpenSSH формата с приватным ключом и напечатает в стандартный вывод публичный ключ OpenSSH.

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

ssh-keygen -y -f ПРИВАТНЫЙ-КЛЮЧ

Например, приватный ключ помещён в файл id_rsa, тогда команда извлечения из него публичного ключа следующая:

ssh-keygen -y -f id_rsa

Вы можете столкнуться с ошибкой:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for 'id_rsa' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "id_rsa": bad permissions

Она означает, что приватный ключ доступен для чтения кому угодно и программа ssh-keygen отказывается работать с ним по этой причине. Чтобы исправить эту ошибку, просто установите на файл с приватным ключом права доступа 600:

chmod 600 id_rsa

Как конвертировать .ppk ключ в OpenSSH ключ

Ключ .ppk генерируется при экспорте ключей из PuTTY.

Пример файла .ppk:

Конвертация ключей из файла .ppk в формат OpenSSH в Linux

Для конвертации формата .ppk в формат OpenSSH можно использовать утилиту puttygen, которая включена в пакет Putty. Следовательно, нам нужно установить PuTTY

Linux: с вашим менеджером пакетов установите PuTTY (или более минимальный пакет PuTTY-tools):

Debian, Kali Linux, Linux Mint, Ubuntu и их производные:

sudo apt install putty-tools

Дистрибутивы на основе RPM:

yum install putty

Gentoo:

emerge putty

Arch Linux, BlackArch и их производные:

sudo pacman -S putty

OS X: Установите Homebrew, затем запустите

brew install putty

Поместите ваши ключи в какую-нибудь директорию, например, в домашнюю папку. Теперь конвертируем PPK ключи в SSH пару.

Для извлечения приватного ключа:

cd ~
puttygen id_dsa.ppk -O private-openssh -o id_dsa

и для извлечения публичного ключа:

puttygen id_dsa.ppk -O public-openssh -o id_dsa.pub

Переместите эти ключи в ~/.ssh и убедитесь, что для приватного ключа ограничены права записи:

mkdir -p ~/.ssh
mv -i ~/id_dsa* ~/.ssh
chmod 600 ~/.ssh/id_dsa
chmod 666 ~/.ssh/id_dsa.pub

Конвертация ключей из файла .ppk в формат OpenSSH в Windows

Откройте PuTTYgen, нажмите кнопку «Load» и выберите файл .ppk с ключами.

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

Теперь в меню перейдите в «Conversions» → «Export OpenSSH key» и сохраните приватный ключ.

Скопируйте ваш приватный ключ в файл ~/.ssh/id_dsa (или id_rsa).

Авторизация с Linux машины

Способ 1

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

На вопрос об имени файла можем не отвечать. По умолчанию создадутся ключи (приватный ключ) и (публичный ключ) в каталоге домашней директории. Приватный ключ ВСЕГДА остается на сервере! Если Вы хотите авторизовываться на разных серверах разными ключами, то необходимо указать полное имя файла, включая путь.

Далее мы пойдем по второму варианту, зададим имя “key_name” для файлов ключей :

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

Переходим в директорию .ssh

Файлы key_name и key_name.pub сгенерированы и лежат в /home/user/.ssh

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

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

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

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

Далее необходимо разрешить авторизацию по ключу на удаленном сервере. Это можно сделать в файле конфигурации /etc/ssh/sshd_config

Теперь можно попробовать авторизоваться на удаленном сервере с нашей клиентской Linux машины:

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

Способ 2 — ssh-copy-id

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

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

После чего ввести пароль пользователя удаленной машины “webmaster”.

Если на удаленной машине порт отличный от 22

Настраиваем доступ по SSH

Часть 2.

Перед тем как начнём, давайте создадим нового пользователя с root правами.

Команда

adduser test

Укажем права пользователю test командой

usermod -a -G sudo test

Чтобы убедиться, что пользователь test был добавлен в группу sudo, можно выполнить следующую команду:

id test

Теперь настраим удаленный доступ к серверу по ssh (командная строка), как по локальной сети, так и по интернету

Установим ssh

sudo apt-get install openssh-server

После установки нам необходимо настроить безопасность соединения и непосредственный доступ.
Зайдем в файл с настройками

sudo nano /etc/ssh/sshd_config

По умолчанию, ssh использует порт 22. Заменим его на нестандартный, это повысит безопасность нашего доступа. Порт заменим например на 2200

При подключении по ssh, наш сервер потребует вместо пароля ключ RSA, а не пароль.
Что бы этого не произошло, в параметре RSAAuthentication и PubkeyAuthentication, вписываем «NO».
Так же запрещаем доступ пользователю ROOT, для этого нужно раскомментировать параметр
Authetication: и в параметре PermitRootLogin вписать «NO»

Теперь пропишем доступ пользователям

В строке AllowUsers прописываем пользователей через пробел в виде юзер@хост, т. е. указываем какой пользователь откуда может подключаться.
Можно использовать знак *

Пропишем пользователю test права доступа и разберёмся в них.

test@* — пользователь test может подключаться откуда угодно
[email protected].* — пользователь test может подключаться только находясь в 192.168.0.0 подсети
[email protected] — пользователь test может подключиться только с ip адреса 192.168.0.104
*@192.168.0.* — все пользователи могут подключаться находясь в 192.168.0.0 подсети

Так же можно запретить доступ определённым пользователям (например пользователю test2), для этого нужно вписать ниже

DenyUsers test2

Запускаем

sudo /etc/init.d/ssh start

Ssh мы настроили. Теперь откроем к нему доступ. Для этого откроем доступ к порту 2200.

В прошлой части мы устанавливали firewall командой arno-iptables-firewall, теперь нужно внести туда изменения.
По этому перенатроим его.

sudo dpkg-reconfigure arno-iptables-firewall

Запустилась настройка

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

В следующем окне, так же вписваем порт 2200.

Как только вписали порты, можно везде нажимать ENTER и перезагрузить Файрвол.

После этого порт ssh будет доступен из сети

Для повышения безопасности ssh соединения можно настраиваем утилиту denyhosts.
Утилита представляет собой python-скрипт, который анализирует файл /var/log/auth.log
на наличие записей о несанкционированных попытках входа на сервер по ssh и
добавляет ip-адреса, с которых осуществлялись эти попытки в файл /etc/hosts.deny, с которых запрещен вход по ssh.

Установим командой

sudo aptitude install denyhosts

Сразу после установки утилита просканирует файл /var/log/auth.log и добавит ip-адреса,
с которых осуществлялся подбор паролей, в /etc/hosts.deny. На сканирование потребуется время,
если в файле /var/log/auth.log уже много таких записей.

После установки нужно подправить конфигурационный файл

sudo nano /etc/denyhosts.conf

Скорректируем настройку PURGE_DENY на 3 часа. А то мы можем заблокировать доступ
самому себе, введя несколько раз неверный пароль.

PURGE_DENY = 3h

Ещё, для контроля, нужно указать адрес электронной почты для рассылки уведомлений
о неудачных попытках доступа к серверу:

Для того чтобы новые настройки вступили в силу, нужно перезапустить службу denyhosts:

sudo service denyhosts restart

P.S. Если вам понадобиться сменить пароль на учетной записи. Введите команду

passwd user — где user это имя пользователя

P.S.S. Если возникнут проблемы с кодирвкой, то покопайтесь в настройках клиентской программы shh

Самая популярная программа для работы по ssh, программа PuttY.

Схожие статьи

Настраиваем на Ubuntu Dhcp и Dns сервера, а так же доступ в интернетНастраиваем доступ по SSHНастраиваем VPN PPPTPНастраиваем webminНастраиваем FTP на Ubuntu

Уважаемые посетители сайта, если вам нужна помощь в решении проблем, то оставляйте комментарий в форме, а не Вконтакте. Так я смогу быстре ответить на ваш вопрос

Если есть желание поблагодарить за помощь, просьба поддержать просмотрами видео на канале в YouTube

https://youtube.com/watch?v=videoseries

Или можете помочь проекту материально

Но я не хочу пользоваться Certificate Authority!

Let’s Encryptпоставщиками

Для пользовательских сертификатов мы воспользуемся поставщиком OAuth OIDC, соответствующим нашему Google OAuth приложению. Мы доверяем Google в надежном доступе людей и выдаче только корректных, подписанных Google токенов идентификации OAuth аутентифицированным пользователям. CA проверит токен открытым ключом Google.
Для новых EC2 хостов нам потребуется поставщик AWS, соответствующий нашему AWS аккаунту. Новые хосты будут запрашивать SSH сертификаты хостов через этого поставщика. Мы доверяем AWS в предоставлении подписанных Amazon IIDs, и CA проверит их открытым ключом Amazon.
И наконец, для еженедельного обновления сертификатов хостов мы воспользуемся поставщиком SSHPOP.

Ограничиваем количество попыток авторизации

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

MaxAuthTries 2 # Две неудачные попытки и разрыв связи

Включаем разделение прав пользователей

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

UsePrivilegeSeparation yes

Ограничиваем список доступа по SSH.

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

При этом запись adminguideru – разрешает доступ по ssh для этого юзера с любого источника подключения. Запись же [email protected] – разрешает доступ к серверу под учёткой рута только с ip 192.168.1.101 и 192.168.1.101

AllowUsers adminguideru [email protected] [email protected]

Отключим список доверенных хостов

IgnoreRhosts yes

Отключим авторизацию на стороне клиента

HostbasedAuthentication no

Сохраним все настройки (Ctrl+O) и закроем файл (Сtrl+X).

Перезапускаем SSH сервер

sudo systemctl restart ssh sshd

Настройка безопасности SSH – Пробуем подключиться к серверу через Putty

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

Поэтому важно не разрывать его пока вы не убедитесь что всё заработало. Если всё заработало идём к следующему пункту

Настройка безопасности SSH – Ограничим допущенные к подключению IP адреса

Необходимо отредактировать файл hosts.allow . Открываем его на редактирование

sudo nano /etc/hosts.allow

И добавляем IP адреса всех участников локальной сети, допущенных к подключению (включая IP адрес настраиваемого сервера)

sshd: 127.0.0.1 192.168.1.100 192.168.1.101 192.168.1.254

.254 – админская машина. 100 раз проверьте что у вас стоит IP адрес вашей админской машины. Иначе вы сможете авторизоваться на сервере только через консоль или сменив свой IP на тот что вы указали (если сервер примет с него подключение).

Настройка безопасности SSH – Проверяем авторизацию по паролю

Заходим в конфиг

sudo nano /etc/ssh/sshd_config

Находим пункт PasswordAuthentication раскомментируем и ставим no если там что-то другое.

PasswordAuthentication no

Передача ключей на удаленный сервер

Публичный ключ (id_rsa.pub) нужно передать на удаленную машину в каталог .ssh. Проще всего это можно сделать командой scp (потребуется ввод пароля ssh).

IP-свой подставьте только)

# Если на удаленной машине ssh работает на стандартном (22-ом) порту
scp ~/.ssh/id_rsa.pub [email protected]:~/.ssh

# Если на удаленной машине ssh работает на нестандартном порту (-P portnumber)
scp -P portnumber ~/.ssh/id_rsa.pub [email protected]:~/.ssh

На вопрос о продолжении соединения отвечаем — yes. Потом вводим пароль пользователя.

Are you sure you want to continue connecting (yes/no)? yes

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

cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

Редактируем файл sshd_config на сервере чтобы отключить аутентификацию по паролю. Нужно изменить значение директивы PasswordAuthentication с yes на no.

# Редактируем файл sshd_config в каталоге /etc/ssh
nano /etc/ssh/sshd_config

# Изменяем значение директивы PasswordAuthentication на no
PasswordAuthentication no

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

# Перезагружаем ssh-сервер
systemctl restart ssh

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

ssh [email protected]

Авторизация с Windows машины с помощью PuTTY

Первое что нужно сделать, это генерировать ключ на сервере:

При генерации можно указать путь/имя файлов ключей и защитить ли файлы ключей паролем. Можно ничего не вводить.

Далее переходим в каталог .ssh:

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

Далее на директорию и файл необходимо установить права на чтение и запись только владельцу:

Теперь копируем приватный ключ “id_rsa” на нашу Windows машину и называем его каким-нибудь именем с расширением “.ppk”, например server-privatkey.pkk.

Создание ключей SSH с помощью PuTTYgen

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

Запустите PuTTYgen, дважды щелкнув его файл «.exe» или выбрав в Windows меню «Пуск» → PuTTY (64-разрядная версия) → PuTTYgen.

В блоке «Тип ключа для генерации» оставьте RSA по умолчанию. В поле «Число бит в сгенерированном ключе» оставьте значение по умолчанию 2048, которого достаточно для большинства случаев использования. При желании вы можете изменить его на 4096.
Нажмите кнопку «Создать», чтобы начать процесс создания новой пары ключей.

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

Если вы хотите установить парольную фразу, введите ее в поле «Ключевая фраза-пароль» и подтвердите ту же парольную фразу в поле «Подтвердить парольную фразу». Если вы не хотите использовать кодовую фразу, оставьте поля пустыми.

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

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

Если установлена кодовая фраза, ее необходимо вводить каждый раз, когда используется закрытый ключ.
Сохраните закрытый ключ, нажав кнопку «Сохранить закрытый ключ». Вы можете сохранить файл в любом каталоге как файл «.ppk» (закрытый ключ PuTTY), но желательно сохранить его в месте, где вы можете легко его найти. Обычно для файла закрытого ключа используется описательное имя.

При желании вы также можете сохранить открытый ключ, хотя его можно восстановить позже, загрузив закрытый ключ.
Щелкните правой кнопкой мыши текстовое поле с надписью «Открытый ключ для вставки в файл авторизованных_ ключей OpenSSH» и выберите все символы, нажав «Выбрать все». Откройте текстовый редактор, вставьте символы и сохраните. Убедитесь, что вы вставляете весь ключ. Рекомендуется сохранить файл в том же каталоге, в котором вы сохранили закрытый ключ, используя то же имя закрытого ключа и «.txt» или «.pub» в качестве расширения файла.

Это ключ, который вы должны добавить на свой удаленный сервер Linux.

Развертывание открытого ключа

Чтобы использовать созданный выше ключ пользователя, поместите содержимое открытого ключа (~\.ssh\id_ed25519.pub) на сервер в текстовый файл, имя и расположение которого зависят от того, принадлежит ли учетная запись пользователя к учетной записи участника группы локальных администраторов или обычного пользователя.

Обычный пользователь

Содержимое открытого ключа (~\.ssh\id_ed25519.pub) нужно разместить на сервере в текстовом файле в папке C:\Users\username\.ssh\. Клиентский компонент OpenSSH включает scp (служебная программа безопасной передачи файлов) для упрощения этого процесса.

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

Администратор

Содержимое открытого ключа (~\.ssh\id_ed25519.pub) нужно разместить на сервере в текстовом файле в папке C:\ProgramData\ssh\. Клиентский компонент OpenSSH включает scp (служебная программа безопасной передачи файлов) для упрощения этого процесса. Список управления доступом для этого файла должен быть настроен на предоставление доступа только администраторам и системе.

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

Примечание

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

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

2. Генерация и размещение ключей

Если вы решили настроить на вашем сервере SSH авторизацию по ключу, первое, что необходимо сделать — это сгенерировать секретный и публичный RSA-ключи. Под Linux для генерации ключей я буду использовать ssh-keygen, для Windows есть утилита PuTTYgen.

2.1 Генерация ключей в Linux

Выполните указанную ниже команду для создания ключа длиной 2048 бит и с комментарием “Key for Neustroev Maxim“. Права root не требуются. Я советую добавить комментарий для ключа – в этом случае при подключении с его помощью в логах сервера будет отображаться этот комментарий. Можете ввести сюда свои имя и фамилию.

Авторизуемся под пользователем для которого создаем ключи:

su ЛОГИН

ЛОГИН – логин учетной записи, для которой создаем ключи.

ssh-keygen -t rsa -b 2048 -C "Key for Neustroev Maxim"

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

Generating public/private rsa key pair.
Enter file in which to save the key (/home/ЛОГИН/.ssh/id_rsa):
Created directory '/home/ЛОГИН/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/ЛОГИН/.ssh/id_rsa.
Your public key has been saved in /home/ЛОГИН/.ssh/id_rsa.pub.
The key fingerprint is:
72:56:ab:fd:e2:99:cb:4b:93:ef:63:26:73:f2:d3:19 ЛОГИН@pbx
The key's randomart image is:
+-------+
| |
| |
| . |
| . . |
| . D . |
| + o . T |
| . = . o |
| o=** o |
| .S&=o |
+-----------------+

После генерации ключа, появится 2 файла:

Your identification has been saved in /home/user/.ssh/id_rsa.
Your public key has been saved in /home/user/.ssh/id_rsa.pub.

id_rsa – приватный ключ пользователя;
id_rsa.pub – публичный ключ сервера.

Записываем созданный ключ:

cat id_rsa.pub >> ~/.ssh/authorized_keys

Копируем себе файл id_rsa, и удаляем его на сервере. Так же удаляем и id_rsa.pub. Далее переходим в раздел Настройка SSH авторизации по ключу в PuTTY для создания файла .ppk.

2.2 Генерация ключей в PuTTYgen

Думаю, что с генерацией ключей в PuTTYgen проблем быть не должно. Запускаете программу, нажимаете Generate и потом начинаете беспорядочно водить курсор по экрану. Затем копируете публичный ключ из поля ‘Public key for pasting into OpenSSH authorized_keys file’ и жмете Save private key, чтобы сохранить публичный и приватный ключ. После генерации, публичный ключ копируется в файл ~/.ssh/authorized_keys на сервере, а секретный ключ остается храниться на локальном компьютере.

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

Заносим сгенерированный нами открытый ключ в авторизованные ключи сервера. Для этого скопируйте содержимое id_rsa.pub в конец файла authorized_keys:

cat id_rsa.pub >> ~/.ssh/authorized_keys