Управление ключами openssh для windows

Введение

Не на долго удалось мне отложить настройку этого варианта подключения к серверу. Необходимость настройки доступа по ключу пришла откуда я даже не думал. Неожиданно обнаружил что резервные копии периодически не проходят на Yandex.Disk. Резервирование сайтов у меня производится скриптом который резервирует вначале файлы сайта а потом базу. Пропуски были как с файлами так и с базами. Решил настроить резервное копирование на сервер с которым идет соединение ssh.

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

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

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

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

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

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

ssh-keygen -y -f id_rsa

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

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

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

chmod 600 id_rsa

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

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

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

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

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

UsePrivilegeSeparation yes

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

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

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

AllowUsers adminguideru root@192.168.1.100 root@192.168.1.101

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

IgnoreRhosts yes

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

HostbasedAuthentication no

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

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

sudo systemctl restart ssh sshd

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

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

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

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

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

sudo nano /etc/hosts.allow

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

sshd: 127.0.0.1 192.168.1.100 192.168.1.101 192.168.1.254

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

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

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

sudo nano /etc/ssh/sshd_config

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

PasswordAuthentication no

Общие сведения о SSH и ключах

SSH — это протокол зашифрованного подключения, обеспечивающий безопасный вход в систему через незащищенные соединения. SSH — это протокол подключения по умолчанию для виртуальных машин Linux, размещенных в Azure. Хотя протокол SSH и обеспечивает зашифрованное подключение, использование паролей для соединений SSH все же сохраняет уязвимость виртуальной машины к атакам методом подбора. Мы рекомендуем подключаться к виртуальной машине по SSH с помощью пары «открытый ключ — закрытый ключ», также известных как ключи SSH.

Открытый ключ размещается на виртуальной машине с ОС Linux.
Закрытый ключ остается в локальной системе. Его нужно защищать и нельзя никому предоставлять.

При использовании клиента SSH для подключения к виртуальной машине Linux (с открытым ключом) удаленная виртуальная машина проверяет, имеется ли у клиента правильный закрытый ключ. Если у клиента есть закрытый ключ, он получает доступ к виртуальной машине.

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

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

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

Для генерации пары ключей используется программа ssh-keygen, она включена в пакет ssh и если SSH у вас уже настроен, то дополнительно устанавливать ничего не нужно.

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

Сгенерим ключ через команду:

При выполнении команды у нас спрашивают имя файла, не нужно ничего вводить, будет использовано имя по умолчанию. Также спрашивается пароль. Этот пароль позволяет установить дополнительную защиту — при подключении с помощью ключей не будет спрашиваться пароль пользователя, но будет спрашиваться пароль самого ключа. Устанавливать пароль необязательно. Но надо учитывать следующие, использование дополнительного шифрования имеет только один минус — необходимость вводить пароль, и несколько преимуществ:

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

В результате будет создано два файла: ~/.ssh/id_rsa и ~/.ssh/id_rsa.pub

Первый файл id_rsa (это приватный ключ) всегда нужно хранить в секрете. Второй файл id_rsa.pub (это публичный ключ) нужно добавить на удалённый компьютер, где запущен сервер SSH.

Закручиваем гайки

Все приведённые ниже настройки производятся в файле sshd_config если не указано обратное. Сразу же сделаем бекап этого файла

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bkp

Открыть его на редактирование можно следующей командой:

sudo nano /etc/ssh/sshd_config

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

Жестко прописываем IP адрес ssh сервера

Например у вашего хоста IP адрес 192.168.1.100. А опция отвечающая за интерфейс на котором работает SSH сервер прописана как “*”. А потом к примеру вы нечаянно добавляете этому хосту ещё один сетевой интерфейс. И ещё неожиданно этот интерфейс начинает смотреть жопкой прямо в инторнет. Опция “*” – автоматом сделает возможным подключение к SSH серверу через тот новый интерфейс. Чтобы этого не произошло – необходимо ограничить IP адрес на котором работает SSH сервер. Прописать там можно как жестко IP адрес этого сервера. В случае с ag-dc-1 – это 192.168.1.100, так и подсеть: 192.168.1.0/24.

Для ag-dc-1

ListenAddress 192.168.1.100 #ip ag-dc-1

Для ag-dc-2

ListenAddress 192.168.1.101 #ip ag-dc-2

Изменяем порт SSH сервера

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

#Port <желаемый номер нестандартного порта>
Port 54322

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

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

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

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

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

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

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

Логирование ssh подключений по сертификату

Мне необходимо знать, когда и какой сертификат подключался к серверу. По-умолчанию такой информации чаще всего в логах не остается. Исключение я заметил только в CentOS 7. Там с дефолтными настройками ssh и уровнем логирования INFO отображается отпечаток ключа в логе:

По отпечатку становится понятно, какой сертификат подключился. Для каждого сертификата отпечаток можно посмотреть в puttygen. В CentOS более ранних версий, в Ubuntu 12 и 14 в логах будет только такая информация:

Информации о самом ключе нет. Я так думаю, это зависит от версии OpenSSH. В первом случае 6-я версия, во втором 5-я. Специально я не проверял. Если у вас нет информации о ключе в лог файле, исправить это очень просто. В файле /etc/ssh/sshd_config меняем параметр:

и перезапускаем службу:

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

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

Добавление публичного ключа RSA

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

ssh-copy-id -i /home/user/.ssh/rsa_sevo44.pub -p 25555 root@10.10.0.1
= вывод команды =
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/user/.ssh/rsa_sevo44.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
root@10.10.0.1's password:

Number of key(s) added: 1

Now try logging into the machine, with: "ssh 'root@10.10.0.1'"
and check to make sure that only the key(s) you wanted were added.

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

Проверим добавление ключа на сервере:

cat /root/.ssh/authorized_keys
= вывод команды =
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgQDCHkWoBv8b+j11IJ685m4WrYCdgx/v5bqwC3AahFyySH4yK0CV8ZJA7H6e3bbkPEI1Aw2xB6xRUS7NC4B3dGciDycMJJumX/OGpocm7A4BdrdODXfHzW5ap/WTN46/nlq7pMZH/8sa8GLzhpOv3OokUogLZFh1zZaFD4M0Hiseyw== user@H4530

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

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

Чтобы использовать аутентификацию на основе ключей, необходимо заранее создать для клиента одну или несколько пар открытого и закрытого ключей. Программа 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 в этом примере.
Если вы утратите доступ к закрытому ключу, вам нужно будет создать новую пару ключей и обновить открытый ключ во всех системах, с которыми вы работаете.

Создание ключей для ssh аутентификации

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

# Просматриваем домашний каталог пользователя
ls -1a

Если по каким-то причинам каталог .ssh отсутствует, его необходимо создать, причем на обоих машинах: и на клиенте, и на сервере.

# Создаем скрытый каталог .ssh
mkdir -p ~/.ssh

На домашней машине (клиенте) генерируем ключи командой ssh-keygen.

ssh-keygen

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

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:wzV0scS8cw8g8CaalAiVSrgYQ0yrVunTGhjs454QRIk root@home-16
The key's randomart image is:
+-------+
|==o...  ...o+.   |
|Eoo.o. . o.o+.   |
|.X +. o . =..o   |
|* * .. + + .o o  |
|o= + .o S    o o |
|o.. +    .      .|
|.. .             |
|o .              |
| o               |
+---------+

По умолчанию вышеуказанная команда создает пару 2048-битных ключей в каталоге .ssh (id_rsa и id_rsa.pub). Ключ id_rsa — закрытый (приватный), он остается на домашней машине. Ключ id_rsa.pub — открытый (публичный), он передается на удаленную машину.

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

При желании можно создать 4096-битные ключи (лучше не надо — это на любителя).

ssh-keygen -b 4096

Создание и настройка файла конфигурации SSH

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

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

Создайте файл.

Изменение файла для добавления новой конфигурации SSH

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

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

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

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

2: Копирование открытого ключа на сервер

Самый быстрый способ скопировать открытый ключ на хост Ubuntu – это использовать утилиту ssh-copy-id. Этот метод очень прост, потому используйте его, если у вас есть такая утилита. Если на вашем клиентском компьютере нет ssh-copy-id, вы можете использовать один из двух альтернативных методов, перечисленных в этом разделе ниже (копирование через парольную аутентификацию SSH или копирование ключа вручную).

Копирование ключа с помощью ssh-copy-id

Инструмент ssh-copy-id включен по умолчанию во многие операционные системы, поэтому вы можете использовать его в своей локальной системе. Чтобы этот метод работал, у вас уже должен быть парольный доступ SSH к серверу.

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

Утилита использует такой синтаксис:

Вы увидите такой вывод:

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

Затем утилита сканирует локальную учетную запись, чтобы найти ключ id_rsa.pub. Когда она найдет ключ, она предложит вам ввести пароль учетной записи удаленного пользователя:

Введите пароль (ваш ввод не будет отображаться из соображений безопасности) и нажмите Enter. Утилита подключится к учетной записи на удаленном хосте, используя предоставленный вами пароль. Затем она скопирует содержимое файла ~/.ssh/id_rsa.pub в файл authorized_keys в домашнем каталоге ~/.ssh удаленной учетной записи.

Вы увидите такой вывод:

На данный момент ваш ключ id_rsa.pub скопирован в удаленную учетную запись. Переходите к разделу 3.

Копирование открытого ключа по SSH

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

Сделать это можно с помощью команды cat, которая прочитает содержимое файла открытого SSH-ключа на локальном компьютере, и конвейера, который передаст ключ через SSH-соединение. После этого нужно убедиться, что каталог ~/.ssh существует в удаленной учетной записи, а затем проверить его содержимое.

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

Команда выглядит так:

Вы можете увидеть такой вывод:

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

После этого будет предложено ввести пароль учетной записи удаленного пользователя:

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

Копирование открытого ключа вручную

Если у вас нет парольного доступа, вам придется выполнить описанный выше процесс вручную.

Вручную нужно вставить содержимое файла id_rsa.pub в файл ~/.ssh/authorized_keys на удаленной машине.

Чтобы отобразить содержимое id_rsa.pub, введите на локальной машине:

Вы увидите такой ключ:

Любым доступным способом подключитесь к удаленному хосту.

Если у вас есть доступ к учетной записи на удаленном сервере, убедитесь, что каталог ~/.ssh существует. Эта команда при необходимости создаст каталог или не сделает ничего, если он уже существует:

Теперь вы можете создать или изменить файл authorized_keys в этом каталоге. Вы можете добавить содержимое файла id_rsa.pub в конец файла authorized_keys с помощью этой команды:

Если файла authorized_keys не существует, команда создаст его.

В приведенной выше команде замените public_key_string выводом команды cat ~/.ssh/id_rsa.pub в вашей локальной системе. Он должен начинаться с ssh-rsa AAAA ….

Теперь можно проверить беспарольную аутентификацию на сервере Ubuntu.

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

Генерация пары ключей 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..|
| .oo@.O.|
| ..B.&*o|
| +B.o+BO|
+---------+

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

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

Настройка алиасов для ssh

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

На домашней машине в каталоге .ssh создадим файл config.

nano ~/.ssh/config

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

Общие параметры задаются сразу для всех хостов. Пример ниже не дает разрывать соединения при простое.

Host * 
    KeepAlive yes 
    ServerAliveInterval 30

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

# У меня не 20000 порт - это для примера)
Host techlist
    HostName techlist.top
    Port 20000
    User root

Директива Host задает имя подключения (алиас) в моем случае — techlist, это имя используется для подключения к серверу. В значении директивы HostName можно указать как ip-адрес, так и доменное имя (если оно есть) в таком случае оно резолвится через DNS.

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

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

ssh techlist

А теперь я расскажу как подключаться только одним словом, как и писал выше, Да, я ленивый, и даже два слова — это для меня много. Поэтому я сделал вот такой костылик на скриптах.

Создаю скрипт в каталоге /usr/bin. Обзывайте его как хотите, это и будет ваша команда.

nano /usr/bin/techlist

Добавляю в него следующее содержимое (просто вызов команды которую настроили выше).

#!/bin/bash

ssh techlist

exit

Делаю файл исполняемым.

chmod +x /usr/bin/techlist

Подключаюсь к серверу только одним словом)

techlist

Установка публичного ключа на сервере

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

# Подключаемся к нашему серверу
open 185.65.247.114
# Далее стандартная процедура авторизации 
# После успешной авторизации пиши:
put public_key.pub /tmp/public_key.pub

Ключ с копировался, теперь нужно добавить его в ~/.ssh/authorized_keys. Далее логинемся еще раз по паролю, через PuTTY и выполняем:

mkdir ~/.ssh
chmod 0700 ~/.ssh
cat /tmp/public_key.pub > ~/.ssh/authorized_keys
chmod 0600 ~/.ssh/authorized_keys
rm -f /tmp/public_key.pub

Далее нужно проверить настройки нашего SSH сервера, сами настройки лежат в файле /etc/ssh/sshd_config:

# Путь до публичного ключа в домашней директиве.
AuthorizedKeysFile .ssh/authorized_keys 
# Разрешить аутентификацию по ключу
RSAAuthentication yes
PubkeyAuthentication yes

Теперь нам надо будет перезапустить SSH сервер: