How to use public key authentication with ssh {step-by-step guide}

Overview

Public key authentication is a way of logging into an
SSH/SFTP account using
a cryptographic key rather than a password.

If you use very strong SSH/SFTP passwords, your accounts are already
safe from brute force attacks.
However, using public key authentication provides many benefits when working
with multiple developers.
For example, with SSH keys you can

allow multiple developers to log in as the same system user without
having to share a single password between them;
revoke a single developer’s access without revoking access by other
developers; and
make it easier for a single developer to log in to many accounts
without needing to manage many different passwords.

Manage Multiple SSH Keys

Though it’s considered good practice to have only one public-private key pair per device, sometimes you need to use multiple keys or you have unorthodox key names. For example, you might be using one SSH key pair for working on your company’s internal projects, but you might be using a different key for accessing a client’s servers. On top of that, you might be using a different key pair for accessing your own private server.

Managing SSH keys can become cumbersome as soon as you need to use a second key. Traditionally, you would use to store your keys to , typing in the password for each key. The problem is that you would need to do this every time you restart your computer, which can quickly become tedious.

A better solution is to automate adding keys, store passwords, and to specify which key to use when accessing certain servers.

The first thing we are going to solve using this file is to avoid having to add custom-named SSH keys using . Assuming your private SSH key is named , add following to the file:

Next, make sure that is not in by opening another terminal and running the following command:

This command will remove all keys from currently active session.

Now if you try closing a GitHub repository, your file will use the key at .

Here are some other useful configuration examples:

Now you can use

Now you can SSH into your server using . You no longer need to enter a port and username every time you SSH into your private server.

Password management

The last piece of the puzzle is managing passwords. It can get very tedious entering a password every time you initialize an SSH connection. To get around this, we can use the password management software that comes with macOS and various Linux distributions.

For this tutorial we will use macOS’s Keychain Access program. Start by adding your key to the Keychain Access by passing option to the command:

Now you can see your SSH key in Keychain Access:

But if you remove the keys from with or restart your computer, you will be prompted for password again when you try to use SSH. Turns out there’s one more hoop to jump through. Open your SSH file by running and add the following:

With that, whenever you run it will look for keys in Keychain Access. If it finds one, you will no longer be prompted for a password. Keys will also automatically be added to every time you restart your machine.

Now that you know the basics of creating new SSH keys and managing multiple keys, go out and to your heart’s content!

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

Публичный ключ (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]

Шаг 2. Bash-скрипт: всё гениальное просто

Можно, конечно, ничего не сочинять, а скачать готовый скрипт из сети, там их большой выбор. Но! В большинстве своём они избыточны: вместо того, чтобы сделать быстро и качественно своё дело, они начинают зачем-то копаться в конфигурационных файлах других проектов, выполнять кучу ненужных проверок, тормозить и т.п. В общем, зная, что мы хотим получить и как это сделать, можно за несколько минут самим составить отличный скрипт.

В сердце будущего скрипта у нас будет поисковый запрос в каталог LDAP. Вполне подойдёт тот, который мы использовали для проверки наличия ключа в учётной записи пользователя в самом конце предыдущего шага. Для большей определённости немного усовершенствуем поисковый фильтр LDAP (учётка будет выбираться лишь тогда, когда в ней есть открытый ключ):

$ ldapsearch -x -LLL -o ldif-wrap=no -H ldap://10.0.0.10 -b 'dc=mycompany,dc=ru' '(&(uid=ivanov)(sshPublicKey=*))' sshPublicKey
dn: uid=ivanov,ou=People,dc=mycompany,dc=ru
sshPublicKey: ssh-rsa XXXXXXXXXX...XXXXXXXXXX ivanov@host

Упростим вывод команды, оставив только интересующие нас строки (с помощью grep):

$ ldapsearch -x -LLL -o ldif-wrap=no -H ldap://10.0.0.10 -b 'dc=mycompany,dc=ru' '(&(uid=ivanov)(sshPublicKey=*))' sshPublicKey | \
> grep sshPublicKey
sshPublicKey: ssh-rsa XXXXXXXXXX...XXXXXXXXXX ivanov@host

Наконец, отрежем всё лишнее, оставив только открытый ключ пользователя (с помощью perl):

$ ldapsearch -x -LLL -o ldif-wrap=no -H ldap://10.0.0.10 -b 'dc=mycompany,dc=ru' '(&(uid=ivanov)(sshPublicKey=*))' sshPublicKey | \
> grep sshPublicKey | \
> perl -wpe 's/sshPublicKey: //'
ssh-rsa XXXXXXXXXX...XXXXXXXXXX ivanov@host

На этом можно было бы остановиться, но хочется всё же предусмотреть ситуацию, когда какой-нибудь пользователь по недосмотру внесёт в атрибут sshPublicKey повторно закодированное в Base64 значение. Усовершенствуем наш однострочник на perl:

$ ldapsearch -x -LLL -o ldif-wrap=no -H ldap://10.0.0.10 -b 'dc=mycompany,dc=ru' '(&(uid=ivanov)(sshPublicKey=*))' sshPublicKey | \
> grep sshPublicKey | \
> perl -MMIME::Base64 -wpe 's/^sshPublicKey(:{1,2}) (.+)$/$1 eq "::" ? decode_base64($2) : $2/e'
ssh-rsa XXXXXXXXXX...XXXXXXXXXX ivanov@host

Вот и всё. Оформим наш bash-скрипт :

Опробуем скрипт (предварительно не забыв дать ему права на исполнение):

$ /usr/bin/get_ldap_ssh_key.sh ivanov
ssh-rsa XXXXXXXXXX...XXXXXXXXXX ivanov@host

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

Terminal window and login credentials

After the security alert, you should get a terminal window. By default, this is a black, very bland window. It should first ask for your user name and then password. After these, you should get a command line on the server.

You can then type into the terminal Window. You are now connected to the server, and anything you type in the Window is sent to the server. Server’s responses are displayed in the Window. You can run any text-based applications on the server using the window. The session terminates when you exit the command-line shell on the server (typically by typing ) to the command line or pressing . Alternatively, you can forcibly terminate the session by closing the terminal window.

Configuration options and saved profiles

The initial configuration window contains a lot of options. Most of them are not needed in normal use.

Port

The port field specifies the TCP/IP port to connect. For SSH, this is the port on which the SSH server runs. Normally it can be left to 22. If for some reason you need to connect to a different port number, just change the value. Usually only developers would change this to a different value, but some enterprises are known to run SSH servers in non-standard ports or to run multiple SSH servers on the same server at different ports.

Connection type

The Connection type selection almost never needs to be touched. Just leave it as SSH. SSH is a secure, encrypted communications protocol designed to ensure your password and data are maximally protected.

Raw connections might be used for developers to connect a TCP/IP socket for testing (e.g., when developing a network application that listens on a TCP/IP port).

Telnet is an old legacy protocol that is almost never used, unless you manage equipment that is more than 10 years old. Telnet is not secure. Passwords are sent in the clear on the network. Attackers can easily eavesdrop on plaintext communications and steal user names and passwords. Rlogin is another legacy protocol with similar woes.

Serial refers to a serial port, another legacy communications mechanism for connecting computers to peripheral devices. Most PCs these days no longer have serial ports, but they are still sometimes used for controlling physical equipment, instrumentation, machinery, or communications devices. Another use for serial ports is debugging operating systems or embedded software.

Load, save, or delete a stored session

This section allows you to save your settings as named profiles. Just write the name of your new profile in the Saved Sessions box and click Save to create a new profile. The host name and your other settings are saved in the profile.

Saved profiles appear in the larger box below it. Initially it will contain just Default Settings. Profiles you save will be included there. Select a profile and click Load to use a previously saved profile. Select a profile and click Delete to delete a profile that is no longer needed.

Close window on exit

Finally, the Close window on exit setting specifies whether the terminal window should be automatically closed when the connection is terminated. There is rarely any need to change it from the default value of Only on clean exit.

Sshd_config: Конфигурационный файл сервера OpenSSH

Настройки сервере OpenSSH хранятся в конфигурационном файле %programdata%\ssh\sshd_config. Это обычный текстовый файл с набором директив. Для редактирования можно использовать любой текстовый редактор (я предпочитаю notepad++). Можно открыть с помощью обычного блокнота:

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

Чтобы разрешить подключение только для определенной доменной группы:

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

По умолчанию могут к openssh могут подключаться все пользователи Windows. Директивы обрабатываются в следующем порядке: DenyUsers, AllowUsers, DenyGroups,AllowGroups.

Можно запретить вход под учетными записями с правами администратора, в этом случае для выполнения привилегированных действий в SSH сессии нужно делать runas.

Следующие директивы разрешают SSH доступ по ключам (SSH аутентификации в Windows с помощью ключей описана в отдельной статье) и по паролю:

Вы можете изменить стандартный SSH порт TCP/22, на котором принимает подключения OpenSSH в конфигурационном файле sshd_config в директиве Port.

После любых изменений в конфигурационном файле sshd_config нужно перезапускать службу sshd:

Передача ключей не root-пользователю

Ключами может пользоваться и другой пользователь. Скопируем файл закрытого ключа (id_rsa) и файл настроек config в каталог /home/username/.ssh.

Хоть это и необязательно, но на всякий случай зададим права для каталога .ssh и файлов в нем.

chmod 700 /home/username/.ssh
chmod 600 /home/usename/.ssh/*

Пробуем подключиться (настроенные алиасы тоже работают).

ssh techlist

Соглашаемся и добавляем соединение в known_hosts.

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

Все должно работать. Если вдруг вы видите следующую ошибку — Permission denied (publickey), то тогда в файле config нужно указать пользователя от имени которого устанавливается соединение, если он не был указан ранее.

Host techlist
	HostName techlist.top
	Port 20000
        User root

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

На этом все. До встречи.

Основные ошибки

Отказ в доступе (парольная аутентификация)

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

Клиенты PuTTY и OpenSSH выдают такое сообщение:

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

Убедитесь, что вы используете правильное имя пользователя. В CoreOS используйте пользователя core. В FreeBSD используйте аккаунт пользователя freebsd.
Парольная аутентификация пользователя может быть нарушена. Проверьте, поддерживает ли парольную аутентификацию веб-консоль сервера. Если она не поддерживает пароли, вам придется попытаться сбросить пароль или обратиться за помощью к службе поддержки, чтобы восстановить доступ.
Убедитесь, что сервер поддерживает парольную аутентификацию.

Отказ в доступе (аутентификация на основе SSH-ключей)

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

Как настроить SSH-ключи
Создание SSH-ключей для PuTTY

Вы можете получить такую ошибку:

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

Убедитесь, что файл authorized_keys и сам закрытый ключ имеют правильные права доступа и собственности.
Убедитесь, что сервер поддерживает аутентификацию на основе ключей SSH.
Убедитесь, что клиент SSH может получить закрытый ключ. Если вы используете PuTTY, убедитесь, что ключи SSH правильно настроены в сессии. Если вы используете OpenSSH, убедитесь, что у закрытого ключа SSH есть соответствующие привилегии.
Убедитесь, что файл authorized_keys содержит правильный открытый ключ, и что открытый ключ добавлен на сервер.
Возможно, вы используете закрытый ключ, который больше не поддерживается сервисом OpenSSH. Эта ошибка обычно затрагивает серверы OpenSSH 7+ при использовании закрытого DSA-ключа SSH. Обновите конфигурацию сервера.

Консоль не поддерживает пароли

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

В консоли появляется форма аутентификации:

Но после ввода пароля появляется ошибка:

После сброса пароля вы получите:

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

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

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

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

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

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

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

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

Генерация с помощью PuTTY

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

Создание пары ключей PuTTYgen

Генерация с помощью ssh-keygen

Пользователи, которые используют Linux (или другую Unix-систему), могут генерировать ключи с помощью команды , которая входит в стандартный набор инструментов OpenSSH.

Для большей безопасности и скорости работы рекомендуется использовать более новый формат ключей Ed25519. Открытый ключ Ed25519 компактен. Он содержит только 68 символов по сравнению с RSA 3072, который имеет 544 символа. Генерирование ключа также почти так же быстро, как и процесс подписания. Также, при использовании Ed25519, возможно быстро выполнить проверку подписи. Для генерации ключа Ed25519 используйте следующую команду:

ssh-keygen -o -a 100 -t ed25519 -C "[email protected]"

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

ssh-keygen -o -t rsa -b 4096 -C "[email protected]"

Ответ будет выглядеть подобным образом:

Команда ssh-keygen создает 4096-битный ключ RSA

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

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

# ssh-keygen -l -f .ssh/id_rsa
 4096 98:eb:9a:f7:94:bf:a0:a1:4b:55:ca:82:c3:24:46:b8 .ssh/id_rsa.pub (RSA)

Как работают ключи SSH?

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

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

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

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

Добавление публичного ключа в профиль на GitHub #

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

В GitHub для работы с репозиториями скопируйте публичный ключ, одним из способов:

в GitBash выполните команду:

это скопирует публичный ключ в буфер обмена.

если данная команда не работает, откройте файл id_ed25519.pub в любом текстовом редакторе, и скопируйте все содержимое файла, публичный ключ выглядит так:

Переходите на страницу управления ключами:

Нажимайте не кнопку
В поле вставьте скопированный ключ:

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

Теперь можно использовать SSH доступ к вашим репозиторияем!

Пример. Скрипт. Копирование файла с удаленного компьютера.

Задача. На удаленном компьютере Anacron запускает один раз в сутки. Нужно создать скрипт который будет копировать удаленные backup-копии на локальный сервер бекапов. Скрипт запустим при помощи Использование планировщика cron в Linux.

$ ssh-keygen -t dsa
$ ls
id_dsa  id_dsa.pub
$ chmod 600 id_dsa

Поместим публичный ключ файл ~/.ssh/authorized_keys на удаленном компьютере.

$ ssh-copy-id -i id_dsa.pub USER@HOST

Скрипт:

#!/bin/bash
 
# Copy PostgreSQL
 
SFTP='/usr/bin/sftp'
DIR='/home/backups_mbill_sql/'
HOST='user@host:/home/backups_mbill_sql/'
FILES="psql-`date +%d.%m.%Y`*.sql"
 
$SFTP $HOST$FILES $DIR

Немножко теории — приватные и публичные ключи RSA

Для успешной авторизации по ключам, необходимо иметь публичный ключ и приватный ключ. Все ключи на linux машине хранятся в домашнем каталоге пользователя, в папке .ssh «/home/user/.ssh/».

На сервере хранится публичный ключ. Этот ключ имеет запись одной строкой вида«ssh-rsa AAAABG.. ..+qxQ== rsa-key-20180322»
По умолчанию ключи хранятся в файле authorized_keys. В этом файле могут хранится сразу несколько ключей, просто записываются каждый на строку.
Название файла можно поменять, но тогда нужно это явно указать в конфигурационном файле SSH сервера — /etc/ssh/sshd_config (нужна перезагрузка sshd).«AuthorizedKeysFile %h/.ssh/authorized_keys»

На клиенте (linux) хранится приватный ключ. Ключ имеет запись вида——BEGIN RSA PRIVATE KEY——MIIEoQIBAAKCAQEAjIDrQgbCcRXrGms9kHutJhU6+kopZ1IRca8WalZ/jLr6tyjs….….Hp5ygfYqspTYzGIqsPvYYPMlyg7Jrx8hiEwbbz4Ohpqq6hgvVQ==——END RSA PRIVATE KEY——

В отличии от публичного ключа, каждый приватный ключ это отдельный файл. При подключении к серверу, клиент ssh проверяет в папке .ssh наличие такого ключа. Название по умолчанию должно быть id_rsa. Если задано другое название или ключ лежит в другой директории, то это нужно указать: ssh [email protected] -i /home/user2/id_rsa2.

Важно, права на ключ id_rsa должны быть выставлены 600 (rw——-)

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

Generating an SSH Key Pair on Windows

You must generate two SSH keys (public and private) on the client computer that you will use to connect to the remote Windows host running OpenSSH. A private key is stored on a client side (keep the key safe and don’t share it with anyone!), and a public key is added to the authorized_keys file on the SSH server. To generate RSA keys on a Windows client, you must install the OpenSSH client.

On Windows 10/11 and Windows Server 2019/2022, the OpenSSH client is installed as an optional Windows feature using PowerShell:

On previous Windows versions, you can install the Win32-OpenSSH port from GitHub (see the example in the article about setting up an SFTP (SSH FTP) server on Windows).

Open a standard (non-elevated) PowerShell session and generate a pair of ED25519 keys using the command:

By default, the ssh-keygen tool generates RSA 2048 keys. Currently, it is recommended to use ED25519 instead of RSA keys.

You will be prompted to provide a password to protect the private key. If you specify the password, you will have to enter it each time you use this key for SSH authentication. I did not enter a passphrase (not recommended).

Generating public/private ed25519 key pair.
Enter file in which to save the key (C:\Users\myuser/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in C:\Users\myuser/.ssh/id_ed25519.
Your public key has been saved in C:\Users\myuser/.ssh/id_ed25519.pub.
The key fingerprint is: SHA256:xxxxxxxx myuser@computername
The key's randomart image is:
+----+
+---------+

Ssh-keygen will create the .ssh directory in the profile of a current Windows user () and generate 2 files:

– private key (if you generated an RSA key, the file will be named )
– public key (a similar RSA key is called

After the SSH keys are generated, you can add your private key to the SSH Agent service, which allows you to conveniently manage private keys and use them for authentication.

The SSH Agent service can store your private keys and provide them in the security context of the current user. Run the ssh-agent service and configure it to start automatically using the PowerShell service management commands:

Add your private key to the ssh-agent database:

Identity added: C:\Users\youruser\.ssh\id_ed25519 (youruser@computername)

Or as follows:

Настройка SSH на Linux для аутентификации с помощью ключей

В большинстве дистрибутивов Linux уже настроена поддержка аутентфикации с помощью сертификатов. Откройте конфигурационной файл сервера SSH (/etc/ssh/sshd_config) и раскомментируйте или добавьте следующие стройки:

Перезапустите SSH командой:

Затем создадим файл с ключом на сервере:

В файл authorized_keys нужно вставить ключ, скопированный из окна puttygen и сохранить его.

Затем на стороне клиента откройте Putty и перейдите в раздел Connection -> SSH -> Auth. Нажмите кнопку Browse и укажите путь к закрытому ключу, который вы сохранили ранее (расширение.ppk)

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

Теперь можно подключиться к серверу (нет необходимости перезапускать демона sshd).

Укажем только имя пользователя (в нашем случае это root).

Наличие строки « Authenticating with public key «rsa-key-20161208″» говорит о том, что вы успешно аутентифицировались с помощью ключа RSA.

OpenSSH: Configuring Key-Based Authentication with Public Key on Windows

Now you need to copy your SSH public key to the SSH server. The SSH server in this example is a remote Windows 11 machine that has the OpenSSH service installed and configured.

You can check out the full guide “How to configure an OpenSSH server on Windows?”.

Copy the id_ed25519.pub file to the .ssh directory in the profile of the user you will use to connect to the SSH server. For example, I have an user1 account on my remote Windows 11 device, so I need to copy the key to C:\Users\user1\.ssh\authorized_keys.

You can copy the public key to the SSH server from the client using SCP:

You can add multiple public keys to a single authorized_keys file.

Public key authentication is disabled by default in the OpenSSH server on Windows. You can check this in the sshd_config. The easiest way to get a list of allowed authentication methods in OpenSSH is to use the following PowerShell command (Select-String is used as an analog of grep in PowerShell):

#PubkeyAuthentication yes
#HostbasedAuthentication no
#HostbasedAuthentication
PasswordAuthentication yes
#GSSAPIAuthentication no

In this example, the PubkeyAuthentication line is commented out, which means that this authentication method is disabled. Open the sshd_config file with notepad and uncomment the line:

PubkeyAuthentication yes

Also, you will have to disable the StrictModes option in the sshd_config configuration file. By default, this mode is enabled and prevents SSH key-based authentication if private and public keys are not properly protected. Uncomment the line and change it to

To connect to a remote host using a native SSH client, use the following command:

For example:

It means that you want to connect to a remote SSH server with the IP address 192.168.1.15 under the user1 account. SSH Agent service will automatically try to use your private key to authenticate on a remote host.

If you do not want to use the ssh-agent service to manage SSH keys, you can specify the path to the private key file to be used for the SSH authentication:
To connect SSH host using a user account from an Active Directory domain, use the following format:

When connecting for the first time, you need to add the fingerprint of the SSH server key to the trusted list. Type yes -> Enter.

The authenticity of host '192.168.1.15 (192.168.1.15)' can't be established.
ECDSA key fingerprint is SHA256:xxxxxxx.
Are you sure you want to continue connecting (yes/no/)? yes

ETW logging is used in Windows OpenSSH to store SSH logs instead of plain text files. You can check the SSH key-based authentication logs in the Windows Event Viewer (Application and Services Logs -> OpenSSH -> Operational).

If the SSH connection with the private key is successful, the following event will appear in the OpenSSH log:

EventID 4
sshd: Accepted publickey for locadm from 192.168.15.20 port 55772 ssh2: ED25519 SHA256:xxxxxxx

If you were not able to connect to your SSH server using your private key and you are still prompted to enter a password, it is likely that the user account you are trying to connect to is a member of the local Windows administrators group (the group SID is ). We will discuss it later.

SSH-доступ по Ключу в Ubuntu и CentOS:

Чтобы сгенерировать открытый и закрытый SSH-ключ в Ubuntu или CentOS, используйте команду:

ssh-keygen -t rsa

Параметр -t означает тип, а RSA — протокол, используемый для генерации ключей. RSA является типом по умолчанию, поэтому вы также можете использовать упрощённую версию команды — ssh-keygen.

Длина ключа по умолчанию — 2048 бит. Однако, если вы хотите усилить защиту, измените значение на 4096 бит. В этом случае команда будет выглядеть так:

ssh-keygen -t rsa -b 4096

Это интерактивный процесс генерации ключей, и вас попросят выполнить несколько действий, таких как:

Enter file in which to save the key (/home/.ssh.id_rsa), или «Ввести файл для сохранения ключа (/home/.ssh.id_rsa)»
Enter passphrase (empty for no passphrase), или «Ввести кодовую фразу (оставьте пустым для отключения кодовой фразы)»

Если вы хотите, чтобы были заданы значения по умолчанию, просто нажмите Enter в ответ на каждый из этих запросов. Кодовая фраза используется для шифрования закрытого ключа; однако она не является обязательной и может быть пропущена. Закрытый ключ будет сохранён в папке по умолчанию — .ssh/id_rsa.

Открытый ключ будет сохранён в файле .ssh/id_rsa.pub. На этом генерация ключа будет завершена. Вы можете проверить файлы с помощью любого редактора.

Security alert dialog box

When you connect to a server for the first time, you are likely to see a dialog about the server’s host key not being cached in the registry. This is normal when you are connecting to a server for the first time. If you ever get this with a server, it could mean that someone is trying to attack your connection and steal your password using a man-in-the-middle attack.

But as said, the first time you connect, this is normal, and you should just click Yes. If you want to be fancy, you can check the displayed key fingerprint and make sure it is the same that is used by the server. In real life, almost nobody does that. It is more secure to use a proper SSH key management solution anyway.