Centos вход по сертификату

Teleport Blog — How to Generate and Configure SSH Certificate-Based Authentication — Apr 26, 2022

The SSH protocol offers multiple authentication options: passwords, public keys and certificates. Certificate-based authentication is the most secure of them all, but historically, it has been the most complicated to set up. This tutorial guides you through simple steps to configure certificate-based authentication for an OpenSSH server.

First, let’s consider the differences between certificates and keys.

As you can see, an SSH key is a binary proposition. Either you have it or you don’t, and a server will grant access to whomever happens to be in possession of the key, very similar to a physical door key. There is very little data about the owner of the key. Even the comment field is not mandatory, and a client does not pass it to a server.

A certificate, on the other hand, contains much more data, and therefore:

• Certificates are tied to user identity.
• Certificates automatically expire.
• Certificates can contain SSH restrictions, e.g. forbidding PTY allocation or port forwarding.
• SSH certificates can be synchronized with Kubernetes certificates.
• Certificates include metadata. This enables role-based access control.
• Certificates solve TOFU (trust on first use) problems. The user and host certificates signed by the same CA establish trust and eliminate the need for TOFU.

SSH или Secure Shell — это зашифрованный протокол, который часто используется для взаимодействия и удаленного управления серверами. Если вы захотите что-либо сделать на удаленном сервере, скорее всего, вам придется воспользоваться SSH и работать через терминал.

В SSH существует несколько способов авторизации. Вы можете каждый раз вводить пароль пользователя или использовать более безопасный и надежный способ — ключи SSH. Что самое интересное, он более удобен для применения, вам даже не нужно будет вводить пароль. В этой статье мы рассмотрим как настраивается авторизация по ключу SSH.

SSH сервер может выполнять аутентификацию пользователей с помощью различных алгоритмов. Самый популярный — это аутентификация по паролю. Он достаточно прост, но не очень безопасный. Пароли передаются по безопасному каналу, но они недостаточно сложны для противостояния попыткам перебора. Вычислительная мощность современных систем в сочетании со специальными скриптами делают перебор очень простым. Конечно, существуют другие способы дополнительной безопасности, например, fail2ban, но аутентификация по ключу SSH более надежна.

Открытый ключ используется для шифрования сообщений, которые можно расшифровать только закрытым ключом. Это свойство и используется для аутентификации с помощью пары ключей. Открытый ключ загружается на удаленный сервер, к которому необходимо получить доступ. Его нужно добавить в специальный файл ~/.ssh/authorized_keys.

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

Есть виртуальная инфраструктура на базе Proxmox, где один виртуальный сервер выступает в роли основного сервера ( dev, nginx-прокси
) и имеет внешний IP. И есть куча дополнительных виртуальных серверов.

Задача:
нужно настроить возможность входа с dev-сервера на другие сервера по внутренним IP адресам без ввода пароля.

Подключитесь к серверу разработки и создайте открытый и закрытый ключи.

 [root@localhost]# ssh-keygen
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:rHLydfgdfgdfgcvbcvbcvbG3GM9tosDSERPfsEW8 root@ct-dev-01
The key's randomart image is:
+---[RSA 2048]----+
|^/o. . |
|*=@=o o |
|.*+*o+ E |
|+.+ o o. |
|+o. . S |
|+. . |
|.. o.o. |
| . .=. . |
| .o .. |
+----[SHA256]-----+ 

В результате выполнения команды сгенерировано 2 файла в каталоге ~/.ssh/

• id_rsa.pub
  — открытый ключ
• id_rsa
  — Секретный ключ

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

 [root@localhost]# ssh-copy-id [email protected]/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/root/.ssh/id_rsa.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys[email protected]'s password:
Number of key(s) added: 1
Now try logging into the machine, with: "ssh '[email protected]'"
and check to make sure that only the key(s) you wanted were added. 

 [root@localhost]# ssh [email protected]Last login: Wed Oct 2 09:48:44 2019 from 192.168.12.2
[root@ct-sefton-01 ~]# ll .ssh
total 9
-rw------- 1 root root 396 Oct 2 09:48 authorized_keys
-rw-r--r-- 1 root root 193 Sep 19 10:47 known_hosts 

Файл author_keys появился на сервере, которому мы передали публичный ключ. Содержимое этого файла является содержимым открытого ключа.

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

Коллеги, приветствую. Сегодня мы познакомимся с методом аутентификации по открытым ключам в SSH. Познакомимся с основными принципами и ключевыми понятиями. Разберем несколько способов формирования ключевой пары, а также произведем конфигурацию и подключение к SSH серверу на системах Windows и Linux. Если Вы в своей деятельности часто используете SSH и хотели бы увеличить безопасность подключений, то давайте вместе разбираться как можно применять аутентификацию по ключу на проектах.

Что это такое и зачем это нужно?

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

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

Симметричное и асимметричное шифрование

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

Асимметричное шифрование противопоставляется симметричному. Этот тип появился в 70-х годах и позволил применять новые подходы, при которых процедуры шифрования и дешифровки информации производятся разными, но взаимосвязанными ключами.
Именно на принципе использования разных частей ключей основана аутентификация по открытому ключу.

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

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

Применение на практике

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

и ssh-keygen

.

Также нам будет необходимо установить и сконфигурировать SSH сервер. В качестве примера мы возьмем популярный проект — OpenSSH Server

, который доступен для установки на различных операционных системах в т.ч — Windows и Linux.

Настройка доступа по ключам

Разворачиваем виртуальную машину

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

Когда предварительные действия будут выполнены, перейдите в папку сценария Localhost_1.2

для развертывания CentOS, либо в папку Localhost_1.3

для развертывания Ubuntu, либо в папку Localhost_1.0

для развертывания Windows Server и выполните команду:

 vagrant up 

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

Спустя время, виртуальная машина будет готова и мы сможем подключиться к ней либо через менеджер виртуальных машин VirtualBox, либо при помощи ssh подключения по адресу 127.0.0.1:2222.

В качестве учетной записи для подключения указываем — vagrant. Пароль — vagrant.

В случае, если была выбрана виртуальная машина на Windows, мы можем подключиться к ней при помощи RDP по адресу 127.0.0.1:33389.

Конфигурация сервера. Установка OpenSSH на Linux

Для установки OpenSSH сервера на CentOS выполним следующую команду:

 sudo yum install openssh-server -y 

Итогом должна быть установка, обновление или сообщение об актуальности версии OpenSSH. В моем случае установлена актуальная версия инструмента.

Для установки OpenSSH сервера на Ubuntu выполним следующие команды:

 sudo apt-get update
sudo apt-get install openssh-server -y 

Результатом также будут установка, обновление или сообщение об актуальности версии OpenSSH.

Запустим службу sshd выполнив команду:

 sudo systemctl start sshd
sudo systemctl enable sshd 

Конфигурация сервера. Установка OpenSSH на Windows

Компонент OpenSSH Server доступен в Windows из коробки начиная с версии Windows 10 1809 и Windows Server 2019. Для быстрой установки откроем Powershell от имени администратора и введем команду:

 Get-WindowsCapability -Online | ? Name -like 'OpenSSH*' | Add-WindowsCapability -Online 

Будет запущен процесс установки компонента OpenSSH Server.

В дополнение к вышеуказанной команде выполним еще пару команд. Запустим службу sshd и выберем тип запуска — Автоматический.

 Start-Service sshd; Set-Service -Name sshd -StartupType 'Automatic' 

Создадим разрешающее правило в Firewall Windows.

 New-NetFirewallRule -Name sshd -DisplayName 'OpenSSH Server (sshd)' -Enabled True `
-Direction Inbound -Protocol TCP -Action Allow -LocalPort 22 

Конфигурация клиента. Формирование ключевой пары на Windows (PuTTYgen)

Инструмент PuTTY нам понадобится для ssh подключения чуть позже, а с помощью PuTTYgen мы сможем сформировать ключевую пару прямо сейчас.

Запустим PuTTYgen и выберем Generate. Все остальные настройки можно оставить по умолчанию.

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

Поздравляю, мы успешно сгенерировали ключевую пару при помощи PuTTYgen. Сохраним закрытую часть ключа в виде файла при помощи кнопки Save private key

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

Не закрывая окно PuTTYgen переходим в раздел Public key for pasting into OpenSSH authorized_keys file

и копируем из него все содержимое. Эта информация нам понадобится на этапе добавления открытого ключа на SSH сервер.

Конфигурация клиента. Формирование ключевой пары на Linux (ssh-keygen)

Теперь попробуем сгенерировать ключевую пару из под Linux при помощи инструмента ssh-keygen. Для теста воспользуемся Ubuntu.

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

В итоге в папке ~/.ssh должны появиться две части ключа. id_rsa — закрытая часть, id_rsa.pub — открытая часть.

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

 chmod 600 ~/.ssh/id* 

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

 cat ~/.ssh/id_rsa.pub 

Конфигурация сервера. Разрешение аутентификации по ключу и добавление ключей на Linux.

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

 vi ~/.ssh/authorized_keys 

Вставляем открытую часть ключа и сохраняем файл.

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

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

 sudo sed -i 's/PubkeyAuthentication no/PubkeyAuthentication yes/g' /etc/ssh/sshd_config
sudo sed -i 's/PasswordAuthentication yes/PasswordAuthentication no/g' /etc/ssh/sshd_config 

Или откроем конфигурационный файл /etc/ssh/sshd_config

любым удобным редактором.

 sudo vi /etc/ssh/sshd_config 

Находим строку PasswordAuthentication

и устанавливаем значение no

. Также находим строку PubkeyAuthentication

и устанавливаем значение yes

.

Для применения конфигурации перезапустим службу OpenSSH сервера выполнив команду:

 sudo systemctl restart sshd 

Конфигурация сервера. Разрешение аутентификации по ключу и добавление ключей на Windows.

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

Для этого запустим PowerShell от имени администратора и выполним команду:

 ((Get-Content -path C:\ProgramData\ssh\sshd_config -Raw) `
-replace '#PubkeyAuthentication yes','PubkeyAuthentication yes' `
-replace '#PasswordAuthentication yes','PasswordAuthentication no')` | Set-Content -Path C:\ProgramData\ssh\sshd_config; Restart-Service sshd 

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

 New-item -Path $env:USERPROFILE -Name .ssh -ItemType Directory -Force
echo "ssh-rsa" | Out-File $env:USERPROFILE\.ssh\authorized_keys -Encoding ascii 

Подключение к серверу SSH по открытой части ключа на Windows.

Запустим PuTTY и введем адрес подключения к SSH серверу.

В разделе Connection > SSH > Auth

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

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

Результат ssh аутентификации по ключу на сервере CentOS или Ubuntu.

Результат ssh аутентификации по ключу на сервере Windows.

Подключение к серверу SSH по открытой части ключа на Linux.

Выполним подключение к серверу SSH. Для этого запустим на исполнение команду:

 ssh vagrant@127.0.0.1 -p 2222 

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

Результат ssh аутентификации по ключу на сервере CentOS или Ubuntu.

Результат ssh аутентификации по ключу на сервере Windows.

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

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

К сожалению, если скопировать такой ключ и попытаться произвести вход на SSH сервер, мы скорее всего получим ошибку: Load key «/root/.ssh/id_rsa»: invalid format
, либо подобные.

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

Самый просто способ — запустить PuTTYgen, загрузить сохраненную закрытую часть ключа при помощи кнопки Load.

Перейти в раздел Conversions и выбрать меню Export OpenSSH key.

Инструмент позволит нам сохранить закрытую часть в формате (PEM), который генерирует ssh-keygen.

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

Configuring SSH for user certificate authentication

 TrustedUserCAKeys /etc/ssh/user_ca.pub 

Once this is done, restart sshd
with systemctl restart sshd
.

Настройка SSH для использования сертификатов хоста

Сначала скопируйте три файла, которые вы только что создали, на сервер, сохраните их в папке /etc/ssh
директории, установите разрешения, соответствующие другим файлам, затем добавьте эту строку в свой /etc/ssh/sshd_config
файл:

 HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub 

Как только это будет сделано, перезапустите sshd
с systemctl restart sshd
.

Теперь ваш сервер настроен на предоставление сертификата всем, кто подключается. Для вашего местного ssh
клиент, чтобы использовать это (и автоматически доверять хосту на основе удостоверения сертификата), вам также необходимо добавить открытый ключ ЦС к вашему known_hosts
файл.

 @cert-authority *.example.com ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDwiOso0Q4W+KKQ4OrZZ1o1X7g3yWcmAJtySILZSwo1GXBKgurV4jmmBN5RsHetl98QiJq64e8oKX1vGR251afalWu0w/iW9jL0isZrPrmDg/p6Cb6yKnreFEaDFocDhoiIcbUiImIWcp9PJXFOK1Lu8afdeKWJA2f6cC4lnAEq4sA/Phg4xfKMQZUFG5sQ/Gj1StjIXi2RYCQBHFDzzNm0Q5uB4hUsAYNqbnaiTI/pRtuknsgl97xK9P+rQiNfBfPQhsGeyJzT6Tup/KKlxarjkMOlFX2MUMaAj/cDrBSzvSrfOwzkqyzYGHzQhST/lWQZr4OddRszGPO4W5bRQzddUG8iC7M6U4llUxrb/H5QOkVyvnx4Dw76MA97tiZItSGzRPblU4S6HMmCVpZTwva4LLmMEEIk1lW5HcbB6AWAc0dFE0KBuusgJp9MlFkt7mZkSqnim8wdQApal+E3p13d0QZSH3b6eB3cbBcbpNmYqnmBFrNSKkEpQ8OwBnFvjjdYB7AXqQqrcqHUqfwkX8B27chDn2dwyWb3AdPMg1+j3wtVrwVqO9caeeQ1310CNHIFhIRTqnp2ECFGCCy+EDSFNZM+JStQoNO5rMOvZmecbp35XH/UJ5IHOkh9wE5TBYIeFRUYoc2jHNAuP2FM4LbEagGtP8L5gSCTXNRM1EX2gQ== host_ca 

Стоимость *.example.com
является совпадением с шаблоном, указывающим, что этому сертификату следует доверять для идентификации любого хоста, к которому вы подключаетесь и который имеет домен *.example.com
— такие как host.example.com
выше. Это разделенный запятыми список применимых имен хостов для сертификата, поэтому, если вы используете IP-адреса или конфигурацию SSH
записи здесь, вы можете изменить это на что-то вроде host1,host2,host3
или 1.2.3.4,1.2.3.5
по мере необходимости.

После настройки удалите все старые записи ключа хоста для host.example.com
в вашем ~/.ssh/known_hosts
файл и запустите ssh
связь. Вы должны быть подключены напрямую к хосту без необходимости доверять ключу хоста. Проверить правильность представления сертификата можно с помощью такой команды:

 $ ssh -vv host.example.com >& | grep "Server host certificate" Server host certificate: [email protected] SHA256:dWi6L8k3Jvf7NAtyzd9LmFuEkygWR69tZC1NaZJ3iF4, serial ID CA ssh-rsa SHA256:gVhYAAW9r2BWBwh7uXsx2yHSCjY5OPo/X3erqQi6jg valid --T11:: --T11:: Server host certificate hostname: host.example.com 

На этом этапе вы можете продолжить, выпустив сертификаты хоста для всех хостов в вашем имении, используя ЦС хоста. Преимущество этого двойное: вам больше не нужно полагаться на ненадежное доверие при первом использовании (TOFU)
модель для новых хостов, и если вы когда-нибудь повторно развернете сервер и, следовательно, измените ключ хоста для определенного имени хоста, ваш новый хост может автоматически представить подписанный сертификат хоста и избежать ужасного WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!
сообщение.

Как работает аутентификация на основе сертификата SSH

Сгенерируйте пару ключей SSH CA, используя ssh-keygen
команда:

 $ ssh-keygen -t rsa -b -f host_ca -C host_ca
Generating / rsa pair.
Enter passphrase (empty no passphrase):
Enter same passphrase again:
Your identification has been saved host_ca.
Your has been saved host_ca.pub.
The fingerprint :
tltbnMalWg+skhm+VlGLd2xHiVPozyuOPl34WypdEO0 host_ca
The 's randomart image is:+---[RSA ]----+
| +o.|
| .+..o|
| o.o.+ |
| o o.= E|
| S o o=o |
| ....+ = +.|
| ..=. %.o.o|
| *o Oo=.+.|
| .oo=ooo+..|
+----[SHA256]-----+
$ ls -l
total
-rw-------. honda honda Mar : host_ca
-rw-r--r--. honda honda Mar : host_ca.pub 

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

 $ ssh-keygen -t rsa - -f user_ca -C user_ca 

Выдача сертификатов хоста (для аутентификации хостов пользователям)

Сгенерируйте новый ключ хоста и подпишите его ключом ЦС:

  # the passphrase used for the host CASigned host key ssh_host_rsa_key-cert.pub:  

ssh_host_rsa_key-cert.pub
содержит подписанный сертификат хоста.

Вот объяснение используемых флагов:

• -s host_ca
  : указывает имя файла закрытого ключа ЦС, который следует использовать для подписи.
• -I host.example.com
  : идентификатор сертификата — буквенно-цифровая строка, которая будет идентифицировать сервер. Я рекомендую использовать имя хоста сервера. Это значение также можно использовать для отзыва сертификата в будущем, если это необходимо.
• -h
  : указывает, что этот сертификат будет сертификатом хоста, а не сертификатом пользователя.
• -n host.example.com
  : указывает разделенный запятыми список принципалов, для аутентификации которых сертификат будет действительным — для сертификатов хоста это имя хоста, используемое для подключения к серверу. Если у вас настроен DNS, вы должны использовать полное доменное имя сервера (например, host.example.com
  ) здесь. Если нет, используйте имя хоста, которое вы будете использовать в ~/.ssh/config
  файл для подключения к серверу.
• -V +52w
  : указывает срок действия сертификата, в данном случае 52 недели (один год). По умолчанию сертификаты действительны вечно. Сроки действия сертификатов хоста настоятельно рекомендуются для поощрения принятия процесса ротации и замены сертификатов при необходимости.

Выдача пользовательских сертификатов (для аутентификации пользователей на хостах)

 $ sshkeygen f key b t rsa
$ ls l
rwr
rw
$ sshkeygen s user_ca I honda.com n ec2,honda V d key.pub
Enter passphrase: # the passphrase used the CA
Signed key keycert.pub: id "[email protected]" serial ec2,honda valid T16:: T16::
$ ls l
rw
rwr
rwr 

Вот объяснение используемых флагов:

• -s user_ca
  : указывает закрытый ключ ЦС, который следует использовать для подписи
• -I [email protected]
  : идентификатор сертификата, буквенно-цифровая строка, которая будет отображаться в журналах SSH при предъявлении сертификата пользователя. Я рекомендую использовать адрес электронной почты или внутреннее имя пользователя, для которого предназначен сертификат — что-то, что позволит вам однозначно идентифицировать пользователя. Это значение также можно использовать для отзыва сертификата в будущем, если это необходимо.
• -n ec2-user,honda
  : указывает разделенный запятыми список принципалов, для аутентификации которых сертификат будет действителен, т. е. пользователей *nix, которым этот сертификат должен разрешить вход в систему. В нашем примере мы даем этому сертификату доступ к обоим ec2-user
  и honda
  .
• -V +1d
  : specifies the validity period of the certificate; in this case +1d
  means 1 day. Certificates are valid forever by default, so using an expiry period is a good way to limit access appropriately and ensure that certificates can’t be used for access perpetually.

If you need to see the options that a given certificate was signed with, you can use ssh-keygen -L
:

Как создать ключи SSH?

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

И так, генерация ключей ssh выполняется командой:

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

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

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

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

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

Отключение проверки пароля

Если пароль больше не будет использоваться, то для увеличения безопасности системы лучше его вовсе отключить. Но убедитесь, что ключ надежно сохранен и вы его не потеряете, потому что по паролю вы больше не войдете. Авторизуйтесь на сервере, затем откройте конфигурационный файл /etc/ssh/sshd_config и найдите там директиву PasswordAuthenticatin. Нужно установить ее значение в No:

Теперь сохраните файл и перезапустите службу ssh:

sudo service ssh restart

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

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

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

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

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

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

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

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

Выводы

Обнаружили ошибку в тексте? Сообщите мне об этом. Выделите текст с ошибкой и нажмите Ctrl+Enter.