Как настроить ssh сертификаты входа на ubuntu

Сгенерировать пару ключей

Первый шаг — это генерация пары ключей. Обычно это делается на клиентской машине.
Например, на вашем ноутбуке.

Основная команда ssh-keygen создаст 2048-битную пару RSA ключей. Для
большей надёжности можно добавить флаг -b 4096

Выполните

ssh-keygen -b 4096

Чтобы сгенерировать ключ в /home/$(whoami)/.ssh

или

sudo ssh-keygen -b 4096

Чтобы сгенерировать ключ в /home/root/.ssh

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

Нужно придумать имя ключа.

Я назову ключ

andrei-key101

а сохранять буду в текущую директорию.

Enter file in which to save the key (/root/.ssh/id_rsa): andrei-key101
Enter passphrase (empty for no passphrase):
Enter same passphrase again:

Нужно два раза ввести пароль. Если он вам нужен. Обычно нет.

Your identification has been saved in andrei-key101
Your public key has been saved in andrei-key101.pub
The key fingerprint is:
SHA256:abcd/abcdefghijklmnopqrstuvwxyz1234567890ab root@urn-su
The key’s randomart image is:
+——-+
|=o oo++ |
|= oo o. = o |
|+ |
|Oo=o . . |
|B+.o S . |
|+o.o |
|+.0. . |
|o+= . E |
|+=oo. . . |
+———+

Ключи готовы. Я сохранил их в текущую директорию поэтому увижу их сделав ls

andrei-key101 andrei-key101.pub

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

Создание ключей пользователя

Чтобы использовать аутентификацию на основе ключей, необходимо заранее создать для клиента одну или несколько пар открытого и закрытого ключей. Программа ssh-keygen.exe используется для создания файлов ключей, при этом вы можете задать алгоритмы DSA, RSA, ECDSA или Ed25519. Если алгоритм не указан, используется RSA. Необходимо использовать надежный алгоритм и соответствующую длину ключа, например Ed25519 в этом примере.

Чтобы создать файлы ключей с помощью алгоритма Ed25519, выполните следующую команду в командной строке PowerShell или в командной строке на клиенте:

Эта команда возвращает такие выходные данные (username заменяется вашим именем пользователя):

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

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

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

После этого при каждом выполнении аутентификации с этого клиента с использованием закрытого ключа, ssh-agent будет автоматически извлекать его и передавать клиенту SSH.

Важно!

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

About key pairs

Key pairs refer to the public and private key files that are used by certain authentication protocols.

SSH public key authentication uses asymmetric cryptographic algorithms to generate two key files – one «private» and the other «public». The private key files are the equivalent of a password, and should stay protected under all circumstances. If someone acquires your private key, they can log in as you to any SSH server you have access to. The public key is what is placed on the SSH server, and may be shared without compromising the private key.

When using key authentication with an SSH server, the SSH server and client compare the public key for a user name provided against the private key. If the server-side public key cannot be validated against the client-side private key, authentication fails.

Multi-factor authentication may be implemented with key pairs by entering a passphrase when the key pair is generated (see below). During authentication the user is prompted for the passphrase, which is used along with the presence of the private key on the SSH client to authenticate the user.

Option 2: MacOS

Watch the video below for an overview of the Generate SSH Keys Mac option.

If you don’t already have a shortcut to the terminal application for MacOS, you can find it in the Applications > Utilities menu or (Shift+Command+U) on your keyboard.
Start up Terminal and type in the command . ssh-keygen will ask you where to save the key, accept the default of the .ssh folder in your home directory by pressing Enter. File name will be or whatever you choose to name your key. Press Enter twice for no passphrase. Remember the directory where you saved your key (~/.ssh), you will need to reference it later when you create your instance.
Type the following commands in the terminal window to verify that the public and private keys were created, and to copy the contents of the public key for use in creating your instance in the OCI dialog.

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 content 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.
If you’re ready to create an instance, copy the contents and paste when prompted for the SSH key. Make sure that you remove any hard returns that may have been added when copying.

Использование ключа

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

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

Генерирование ключа и подключение на Windows

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

Запустите программу PuTTYgen.
Нажмите на кнопку Gengerate.
Водите курсором мышки по рабочему столу, чтобы сгенерировать случайные значения ключей.
Нажмите на кнопку Save private key, чтобы сохранить на жестком диске приватный ключ. Место хранения может быть любым — его нужно указать в параметрах PuTTY. Сделаем это позже.
Скопируйте публичный ключ в буфер обмена (Ctrl + C) и закройте генератор ключей.

Теперь нужно перенести публичный ключ на сервер. Запустите программу PuTTY и подключитесь к серверу с помощью пароля. Затем последовательно введите следующие команды:

mkdir ~/.ssh

chmod 0700 ~/.ssh

touch ~/.ssh/authorized_keys

chmod 0644 ~/.ssh/authorized_keys

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

Следующий шаг — вставка публичного ключа из буфера обмена в файл authorized_keys. Для этого используется команда cat > .ssh/authorized_keys. После ввода команды щелкните по окну терминала правой кнопкой, чтобы вставить скопированный ранее публичный ключ. Для завершения ввода нажмите на сочетание клавиш Ctrl+D.

Вернитесь в настройки PuTTY. Перейдите в раздел Connection — SSH — Auth. Нажмите на кнопку Browse и укажите путь к приватному ключу, который вы ранее сохранили на жестком диске.

Теперь для подключения к серверу через SSH пароль не нужен — достаточно указать логин и IP-адрес сервера.

Генерирование ключа и подключение на Linux и macOS

Теперь посмотрим, как подключиться через SSH ключи на Linux и macOS.

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

Генератор предложит также задать кодовую фразу для ключа. Это дополнительная мера безопасности: если кто-то получит доступ к вашей локальной машине, то все равно не сможет подключиться к серверу через SSH. Минус один — вам тоже придется постоянно вводить ключевую фразу. Можно отказаться от этой меры защиты, просто нажав на клавишу Enter.

На этом процедура создания ключей завершена. Файлы d_rsa (приватный ключ) и id_rsa.pub (публичный ключ) хранятся в папке ~/.ssh/. Осталось скопировать открытую часть ключа на сервер.

Вернитесь в терминал.
Выполните команду ssh-copy-id root@185.104.114.90, где root — логин для подключения к серверу по SSH, а 185.104.114.90 — IP-адрес или хост сервера.

После выполнения этой команды публичный ключ будет скопирован на сервер. Теперь вы можете подключаться к удаленной машине с помощью логина и IP-адреса — например, ssh root@185.104.114.90. Ключи будут сопоставляться автоматически.

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

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

Подключитесь к удаленному серверу.
Выполните команду sudo nano /etc/ssh/sshd_config. Файл sshd_config откроется во встроенном текстовом редакторе.
Найдите строку PasswordAuthentication yes и измените ее на PasswordAuthentication no.
Сохраните изменения и перезапустите службу SSH командой sudo service ssh restart.

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

Introduction

The SSH (Secure Shell) protocol is a method for secure remote login from one computer to another. SSH enables secure system administration and file transfers over insecure networks using encryption to secure the connections between endpoints. SSH keys are an important part of securely accessing Oracle Cloud Infrastructure compute instances in the cloud.

If you already have an SSH key pair, you may use that to connect to your environment. We recommend you use the Oracle Cloud Shell to interface with the OCI compute instance you will create. Oracle Cloud Shell is browser-based, does not require installation or configuration of anything on your laptop, and works independently of your network setup. However, if you prefer to connect via your laptop, please select an option based on your configuration.

Important: If the SSH key is not created correctly, you will not be able to connect to your environment and will get errors. Please ensure you create your key properly.

Troubleshooting

Key ignored by the server

If it appears that the SSH server is ignoring your keys, ensure that you have the proper permissions set on all relevant files.

For the local machine:

$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/key

For the remote machine:

$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/authorized_keys

For the remote machine, also check that the target user’s home directory has the correct permissions (it must not be writable by the group and others):

$ chmod go-w /home/target_user

If that does not solve the problem you may try temporarily setting StrictModes to no in /etc/ssh/sshd_config. If authentication with StrictModes off is successful, it is likely an issue with file permissions persists.

Make sure keys in are entered correctly and only use one single line.
Make sure the remote machine supports the type of keys you are using: some servers do not support ECDSA keys, try using RSA or DSA keys instead, see .
You may want to use debug mode and monitor the output while connecting:

# /usr/bin/sshd -d

If you gave another name to your key, for example id_rsa_server, you need to connect with the -i option:

$ ssh -i id_rsa_server user@server

Some best practices for SSH keys

SSH keys are very useful, but can lead to problems if they are not properly managed. They are access credentials just like user names and passwords. If they are not properly removed when people leave or systems are decommissioned, no-one may any longer know who really has access to which systems and data. Many large organizations have ended up having millions of SSH keys.

Use a passphrase when possible

It is recommended that keys used for single sign-on have a passphrase to prevent use of the key if it is stolen or inadvertatly leaked. The ssh-agent and ssh-add programs can be used to avoid having to enter the passphrase every time the key is used.

Generally all keys used for interactive access should have a passphrase. Keys without a passphrase are useful for fully automated processes. They allow shell scripts, programs, and management tools to log into servers unattended. This is often used for backups and data transfers between information systems.

Add a command restriction when possible

The tool does not automatically add command restrictions to keys. Using command restrictions is highly recommended when the key is used for automating operations, such as running a report for fetching some files. A command restriction is basically a option added to the beginning of the line in the server’s authorized_keys file.

Managing SSH keys

Anyone having more than a few dozen servers is strongly recommended to manage SSH keys. Not managing the keys exposes the organization to substantial risks, including loss of confidentiality, insertion of fraudulent transactions, and outright destruction of systems.

The tool can be dangerous. It can easily accidentally install multiple keys or unintended keys as authorized. The logic for choosing which key to install is convoluted. Extra authorized keys grant permanent access. They can later be used to spread attacks host-to-host, and the more keys there are, the higher the risk. It also violates all regulatory compliance requirements.

The Universal SSH Key Manager is a widely used product for managing SSH keys.

Настройка и подключения PuTTY

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

Создаем новый сеанс пиши на IP Адрес к серверу.

Далее, мы выбираем меню категорию SSH и там выберем под категорию Auth

В поле Private key file for authentication загружаем наш приватный ключ.

Далее переходим обратно в раздел Session и сохраняем нашу сессию для того чтобы следующий раз не заполнять все эти поля.

Остаётся только проверить правильность аутентификации к SSH серверу по ключу. Запустите PuTTY и подключитесь к своему серверу. Если вы при создании, ключа заполнили поле Key Passphrase и Confirm Passphrase то вас запросит вести этот пароль. Если же всё настроено неправильно, то будет выдано сообщение об ошибке и предложено ввести пароль.

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

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

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

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

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

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

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

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

chmod 0700 ~/.ssh

touch ~/.ssh/authorized_keys

chmod 0644 ~/.ssh/authorized_keys
```
Откройте созданный файл с помощью текстового редактора:
```
nano ~/.ssh/authorized_keys
```
Вставьте в него скопированный на предыдущем шаге текст public key из окна PuTTYgen и сохраните файл.
Запустите pageant — его иконка появится в трее. Щелкните по ней правой кнопкой мыши и выберите Add Key.
В открывшемся окне укажите путь к приватному ключу mykey.ppk, сохраненному ранее, и нажмите Open. Если при создании ключа вы указывали кодовую фразу, pageant запросит ее на данном этапе.
Для проверки работы авторизации по ключу снова запустите утилиту PuTTY, подключитесь к вашему серверу и введите свой логин. Если все настроено корректно, вы увидите подобный вывод в окне консоли:
```
Authenticating with public key "rsa-key-20151220" from agent
```

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

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

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

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

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

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

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

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