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

Введение

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

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

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

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

Новое на сайте

13 май

почтовый сервер на основе Postfix с пользователями в MySQL и Dovecot как MDA

как установить почтовый сервер Postfix (MTA) для произвольного числа доменов и Dovecot 2.x в качестве MDA, использовать MySQL и PostfixAdmin, задействовать квоты, обеспечить защиту от спама и вирусов используя цифровую подпись DKIM, dspam и ClavaAV

подробнее…

18 апр

До опредленного времени, нежелательные сайты в офисе блокировались «прозрачным» SQUID-ом. Однако SQUID3 не может работать с SSL соединениями в режиме transparent и, соответственно, не может блокировать социалки, доступные по https. iptables нам поможет!

подробнее…

22 сент

настройка прозрачного squid3 с пулами задержки или как навести порядок в офисе

Работа в типичном офисе и социальные сети не совместимы. Любой администратор рано или поздно решает задачу — как запретить развлекательный контент и социальные сети в офисе и ограничить скорость Интернета. В этих начинаниях нам поможет Squid3.

подробнее…

18 мар

конечно можно настроить sftp или даже ftp на худой конец и деплоить каждый чих в своем приложении/сайте прямо из вашей любимой IDE, однако удобнее использовать опцию shared folders, которая идёт с VirtualBox прямо «из коробки».

подробнее…

17 фев

монтируем новый жёсткий диск в Debian или решаем проблемы со свободным местом

Знакомая ситуация — заканчивается место на жёстком диске на виртуальном сервере разработки Debian (VirualBox). Разберёмся, как подключить новый жесткий диск, создать на нём ext4 раздел и смонтировать его через fstab по UUID.

подробнее…

06 янв

быстрый старт bower + grunt или дань моде

Часто приходится настраивать связку bower+grunt. Bower — незаменимый менеджер пакетов. Grunt — замечательное средство для автоматизации рутинны со статикой проекта. Ах да, для установки всего этого безобразия нам ещё потребуется Node.js

подробнее…

09 сент

настройка почтового сервера как резервного (backup MX) или пересылка почты для домена клиента

Нобходимо настроить наш сервер как резервный Backup MX для отдельных клиентов. Ситуацию усложняет необходимость иметь несколько активных ящиков на нашем сервере, вне зависимости есть они или нету на основном почтовом сервере. Зачем же это было нужно?

подробнее…

22 май

настройка квоты домена в MDA Dovecot используя dict + mysql

Дело вкуса, но жизнь требует возможности настройки квот на уровне домена по той или иной причине. Как же настроить квоты для доменов в Dovecot, если используется mysql и dict соответственно. Ответ прост — никак. Детали — под катом.

подробнее…

16 май

настройка «greylisting» для postfix (postgrey) или борьба со спамом продолжается

Еще один инструмент для борьбы со спамом – грейлистинг. Суть – временно отклонять почту от новых отправителей со словами «зайдите завтра». Добропорядочный сервер обязательно «зайдет». Типичный спаммер – нет. Итак, Postgray для Postfix.

подробнее…

15 май

настройка Fail2Ban для защиты служб сервера от атак извне или как сделать логи аккуратными

Благая цель – избавить сервер от лишней работы (нагрузки) и блокировать попытки перебора паролей и хакерских атак – крайне благородна. Настроим инструмент fail2ban для мониторинга лог-файлов служб на сервере и блокирования вредителей по IP…

подробнее…

E-mail:
Skype: dmitry_rendov
Тел.:
включите javascript чтобы видеть номер

Все обновления в Twitter twitter.com/DmitryRendov

Настройка SSH авторизации по ключу в PuTTY

Если ключ id_rsa сгенерирован в Linux, нужно перевести его в формат .ppk с помощью утилиты PuTTYgen. Открываете утилиту PuTTYgen, выбираете меню Conversion -> Import key. Выбираете свой файл id_rsa и нажимаете Save private key:

Для авторизации по ключу в PuTTY укажите расположение ключа в меню Connetction -> SSH -> Auth -> Private key file for authentication.

Сохраните подключение.

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

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

Шаг 3 — Аутентификация на сервере Ubuntu с использованием ключей SSH

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

Процесс входа выглядит так же:

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

Это означает, что ваш локальный компьютер не узнал удалённый хост. Напечатайте “yes” и нажмите для продолжения.

Если при создании пары ключей вы не задали ключевую фразу (passphrase), вы будете залогинены автоматически

Если вы задали ключевую фразу, вам будет предложено её ввести (обратите внимание, что вводимые символы не будут отображаться на экране в целях безопасности). После аутентификации откроется новая сессия оболочки (shell session) на удалённом хосте от имени используемого вами удалённого аккаунта пользователя

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

Генерация пары ключей RSA

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

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

Создадим связку ключей указав тип -t rsa, длину ключа -b 2048 и место с необходимым нам названием:

ssh-keygen -t rsa -b 2048 -f /home/user/.ssh/rsa_sevo44
= вывод команды =
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/user/.ssh/rsa_sevo44.
Your public key has been saved in /home/user/.ssh/rsa_sevo44.pub.
The key fingerprint is:
SHA256:A9d+2cz6M1GK482oOxf/zweqt9B18WPox04m+Deczgc user@H4530
The key's randomart image is:
+-------+
| |
| . |
| . . . . |
| o . =. +|
| S . oo==o|
| . o*oE..|
| [email protected].|
| ..B.&*o|
| +B.o+BO|
+---------+

По результату видим что создалась пара ключей с названием rsa_sevo44.

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

Настраиваем сервер SSH

На сервере (к которому будем подключаться)

На сервер надо поместить открытый (публичный) ключ (myServer_rsa.pub из примера), а не приватный!

mkdir /home/vasya/.ssh
touch /home/vasya/.ssh/authorized_keys

Примечание 1: если файл уже есть и он к вашему удивлению не пустой, значит, кто-то когда-то пользовался подключением по ключу

Это важно, надо обязательно выяснить, кто еще заходил на сервер

Примечание 2: если вы под рутом зашли и папки-файлы создаете, то потом надо права на папку дать юзеру, иначе vasya в папку .ssh не попадет:

# chown -R vasya:vasya /home/vasya/.ssh
# chmod 600 /home/vasya/.ssh/authorized_keys
# chmod 700 /home/vasya/.ssh

Изменяем настройку сервера sshd

Отключаем аутентификацию по паролю, запрещаем логиниться пользователем root.

# nano /etc/ssh/sshd_config

…
PermitRootLogin no
MaxAuthTries 3
MaxSessions 3
AllowUsers vasya
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PermitEmptyPasswords no
PasswordAuthentication no
…

Перезапуск сервера sshd:

Стойте!!! Фуф, успел )) Перед тем, как копипастить команду ниже, подумайте, что будет, если сессия разорвется, а залогиниться вы вдруг не сможете ))

# service sshd restart

Вот и все? Еще немного внимания!

Грабли

Не спешите закрывать окно консоли, чтобы радостно войти с ключом! Если что-то пойдет не так (например, сервер не примет ваш клиентский сертификат), то вы не сможете войти на сервер с удаленной консоли. Конечно, можно подойти к серверу и на нем работать, но это совсем не так удобно, а порой (например, если это удаленный хостинг) невозможно. Поэтому попробуйте сначала открыть новое окно (например, putty) и войти на сервер с ключом.

Например, если не выполнить chmod 700 на папку и chmod 600 на файл из п.2.1, вам может быть отказано в авторизации. В /var/log/secure могут быть записи такого рода:

su: pam_unix(su-l:session): session opened for user root by vasya(uid=500)
su: pam_unix(su-l:session): session closed for user root
sshd: Authentication refused: bad ownership or modes for file /home/vasya/.ssh/authorized_keys
sshd: Connection closed by 192.168.1.2
sshd: Authentication refused: bad ownership or modes for directory /home/vasya/.ssh
sshd: Connection closed by 192.168.1.2
sshd: User root from 192.168.1.123 not allowed because not listed in AllowUsers
sshd: input_userauth_request: invalid user root
sshd: Connection closed by 192.168.1.2

где
192.168.1.2 — сервер;
192.168.1.123 — клиент.

Надо скорректировать права доступа:

# chmod 600 /home/vasya/.ssh/authorized_keys
# chmod 700 /home/vasya/.ssh

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

Вот и все.

Авторизуйтесь для добавления комментариев!

1: Установка PAM

Сначала давайте установим PAM от Google, или Pluggable Authentication Module – это инфраструктура для аутентификации пользователей, которая используется в системах Linux. Поскольку приложение OATH-TOTP разработано Google, компании понадобилось создать и модуль PAM для быстрой генерации одноразовых паролей, совместимый с любым TOTP-приложением (в том числе с Google Authenticator или Authy).

Затем установите PAM:

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

Запустите приложение:

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

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

Токены на основе математического алгоритма берут определенное число как исходный код, и после каждого использования токена следующий токен увеличивается на единицу. Синхронизированные по времени токены обновляются в заданный период времени. В этом мануале мы остановимся на токенах, синхронизированных по времени, поскольку именно такие обычно используют приложения типа Google Authenticator. Нажмите y.

Примечание: Сохраните секретный ключ, код подтверждения и коды восстановления в надежном месте (например, в менеджере паролей). Это ваш единственный способ восстановить доступ к TOTP-приложению, если вдруг вы его потеряете.

Остальные вопросы приложения посвящены настройке PAM. Давайте рассмотрим их по очереди.

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

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

При ответе yes эта опция будет создавать до 17 валидных кодов в скользящем окне в течение 4 минут. Если вы ответите no, их количество будет ограничено до 3 валидных кодов в полторы минуты – это более безопасный выбор. Позже вы сможете изменить эту настройку в файле .google_authenticator, который хранится в корне вашего домашнего каталога.

Этот параметр ограничит количество попыток угадать код: удаленному злоумышленнику дается всего несколько попыток ввести правильное значение, после чего ввод блокируется на некоторое время. Если ранее вы не настраивали ограничение скорости ввода непосредственно в SSH, сделайте это сейчас – это отличный способ укрепить защиту системы.

Примечание: После завершения настройки рекомендуем создать резервную копию секретного ключа. Для этого нужно скопировать файл ~/.google-authenticator в надежное место. Теперь вы сможете использовать его в других системах или хранить как резервную копию.

Следующим шагом будет настройка SSH для поддержки TOTP-ключа

Запоминаем пароль с помощью ssh-agent

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

Для добавления ключей в список для использования во время работы на компьютере используем сервис ssh-agent.

Проверим состояние ssh-agent:

ps -C ssh-agent
= вывод команды =
 PID TTY TIME CMD
 4564 ? 00:00:00 ssh-agent

Теперь нам надо добавить нужный ключ командой:

ssh-add /home/user/.ssh/rsa_sevo44
= вывод команды =
Enter passphrase for /home/user/.ssh/rsa_sevo44: вводим пароль
Identity added: /home/user/.ssh/rsa_sevo44 (/home/user/.ssh/rsa_sevo44)

После перезагрузки данную процедуру придется повторить!

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

ssh-add -l
= вывод команды =
1024 SHA256:A9d+2cz6M1GK482oOxf/zweqt9B18WPox04m+Deczgc /home/user/.ssh/rsa_sevo44 (RSA)

Для удаления всех ключей применим опцию -D:

ssh-add -D
= вывод команды =
All identities removed.

Такую команду удобно использовать когда мы работали на чужом компьютере. Для удаления только своего ключа можно использовать опцию -d путь к ключу.

Ответ 5

Единый вход SSH обычно достигается с помощью аутентификации с открытым ключом и агента аутентификации. Вы можете легко добавить свой тестовый ключ виртуальной машины к существующему агенту аутентификации (см. Пример ниже). Существуют и другие методы, такие как gssapi / kerberos, но они более сложные.

sshpass

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

Анонимный канал (рекомендуется sshpass)

# Create a pipe

PIPE=$(mktemp -u)

mkfifo -m 600 $PIPE

# Attach it to file descriptior 3

exec 3<>$PIPE

# Delete the directory entry

rm $PIPE

# Write your password in the pipe

echo ‘my_secret_password’ >&3

# Connect with sshpass -d

sshpass -d3 ssh user@host

# Close the pipe when done

exec 3>&-

Это довольно громоздко в bash, возможно, проще с языками программирования. Другой процесс может подключиться к вашему pipe / fd до того, как будет записан пароль. Окно возможностей довольно короткое и ограничивается вашими процессами или root.

Переменная окружения

# Устновка вашего пароля в переменные среды

export SSHPASS=’my_secret_password’

# Коннект с sshpass -e

sshpass -e ssh user@host

Вы и пользователь root можете читать переменные среды вашего процесса (например, ваш пароль) во время работы sshpass ( cat /proc/<pid>/environ | tr ‘\0’ ‘\n’ | grep ^SSHPASS=). Окно возможностей намного длиннее, но по-прежнему ограничено вашими собственными процессами или root, а не другими пользователями.

Аргумент командной строки (наименее безопасный)

sshpass -p my_secret_password ssh user@host

Это удобно, но менее безопасно, как описано на странице руководства. Аргументы командной строки видны всем пользователям (например ps -ef | grep sshpass). sshpass пытается скрыть аргумент, но по-прежнему есть окно, в течение которого все пользователи могут видеть ваш пароль, переданный по аргументу.

Аутентификация с открытым ключом SSH

# Generate a key pair

# Do NOT leave the passphrase empty

ssh-keygen

# Copy it to the remote host (added to .ssh/authorized_keys)

ssh-copy-id user@host

Пароль очень важен. Любой, кто каким-либо образом получит файл закрытого ключа, не сможет использовать его без парольной фразы.

Настройте агент аутентификации SSH

# Start the agent

eval `ssh-agent`

# Add the identity (private key) to the agent

ssh-add /path/to/private-key

# Enter key passphrase (one time only, while the agent is running)

Подключайтесь как обычно

ssh user@host

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

Использование пароля

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

Подключение на Windows

Моя основная система — Windows. Раньше для подключения к серверу через SSH я пользовался сторонней утилитой PuTTY, потому что в операционной системе не было встроенного компонента. В «десятке» он появился, так что теперь можно подключаться к SSH через командную строку (cmd).

Чтобы включить встроенный в систему OpenSSH:

Откройте «Параметры» (Win + I) и перейдите в раздел «Приложения».
Выберите опцию «Управление дополнительными компонентами».
Нажмите «Добавить компонент».
Выберите в списке OpenSSH Client и нажмите «Установить».
После завершения установки перезагрузите систему.

Теперь разберемся, как подключиться к SSH через cmd. Запустите командную строку и выполните запрос вида ssh [email protected].

Значение root — логин для подключения, вы получили его в письме при создании сервера. 185.104.114.90 — IP-адрес сервера. Его можно посмотреть в панели управления сервером или в том же письме, которое прислал хостер. У команды может быть также дополнительный параметр -p, после которого прописывается номер порта. По умолчанию используется порт 22. Если у вас настроен другой порт, нужно явно его указать, — например, полный адрес может выглядеть так: ssh [email protected] -p 150.

После выполнения команды клиент SSH предложит добавить устройство в список известных. Введите в командной строке yes и нажмите на Enter. Затем укажите пароль для доступа к серверу. На этом подключение к серверу через SSH завершено — теперь все команды будут выполняться на удаленной машине, к которой вы подключились.

На версиях младше Windows 10 1809 нет встроенной поддержки протокола OpenSSH. В таком случае понадобится сторонняя утилита. Смотрим, как через PuTTY подключиться по SSH:

Запустите PuTTY.
На вкладке Session укажите Host Name (IP-адрес сервера), Port (по умолчанию 22, но если вы в конфигурации сервера указали другой порт, нужно задать его номер).
Убедитесь, что тип соединения установлен SSH.
Нажмите на кнопку Open, чтобы подключиться.

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

Подключение на Linux и macOS

Теперь посмотрим, как подключиться по SSH через терминал на Linux. Для этого не требуется установка дополнительных компонентов, все работает «из коробки».

Запустите терминал. Обычно для этого используется сочетание клавиш Ctrl+Alt+T. Найти терминал также можно по пути «Главное меню» — «Приложения» — «Система».
Выполните команду для подключения. Синтаксис такой же, как на Windows, — ssh [email protected]. Если порт не стандартный, то нужно явно его указать: например, ssh [email protected] -p 150. Вместо root вы указываете свое имя пользователя, а вместо 185.104.114.90 — IP-адрес своего сервера.
Если хост и порт указаны верно, на следующем шаге появится запрос на ввод пароля. При первом подключении также будет предложение добавить новое устройство в список известных. Для этого введите yes и нажмите на клавишу Enter.

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

Если IP-адрес или порт указаны неверно, то на экране появится сообщение об ошибке — Connection Refused. Это может также говорить о том, что доступ запрещен брандмауэром на удаленном сервере (если вы его не отключили). Чтобы разрешить подключение через SSH:

на сервере с Ubuntu/Debian выполните команду $ sudo ufw allow 22/tcp;
на сервере CentOS/Fedora выполните команду $ firewall-cmd —permanent —zone=public —add-port=22/tcp.

Цифра 22 в синтаксисе — номер порта. Если вы используете другой порт, то укажите его явно.

Если вы знаете как подключиться через SSH на Linux, то справитесь с этой задачей и на macOS. В операционной системе Apple тоже есть встроенный терминал. Синтаксис команды для подключения не меняется: ssh [email protected], где root — ваш логин, а 185.104.114.90 — IP-адрес сервера, с которым вы устанавливаете соединение.

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