Повышаем безопасность закрытых ssh-ключей / хабр

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

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

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

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

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

6 ответов

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

Я предлагаю вам определить, почему он думает, что что-то изменилось, скорее всего, обновление SSH изменило ключи шифрования из-за возможной дыры в безопасности. Затем вы можете очистить эту конкретную строку от файла known_hosts:

Эта строка d elets 377, как показано после двоеточия в предупреждении:

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

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

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

В вопросе говорится: «Как удалить строгую проверку ключей RSA в SSH и в чем проблема?»

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

Однако я не видел, чтобы какие-либо ответы касались определенной части вопроса « Как удалить строгую проверку ключей RSA в SSH ».

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

Пример блока Host приведен ниже:

Конкретно добавленная строка является последней версией , которая делает именно это. В зависимости от вашего конкретного сценария это может быть полезно для вас, например, запустить несколько виртуализированных контейнеров на выделенном сервере, всего на несколько ips, остановить и запустить другой экземпляр на одном и том же ip.

Другой способ удалить StrictHostKeyChecking, когда вам нужно сделать это только для одного сервера:

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

Во-вторых, включите отладку ssh,

и посмотрите, что вам скажет, попробуйте найти в /var /log /secure и /var /log /messages на сервере, к которому вы пытаетесь подключиться для подсказок, sshd дает хорошие сообщения об ошибках.

В-третьих, эта машина подключена к Интернету? Если вы действительно разрешаете вход в систему root?

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

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

Ваше соединение может быть потеряно из-за установки StrictHostKeyChecking. См. этот поток для аналогичной проблемы.

В качестве «хоста» [в широком смысле это может быть все: от переустановки /мультизагрузки до совершенно другого компьютера с IP-адресом, к которому вы подключили раньше, например], кажется, что клиент ssh изменился, это давая вам ошибку.

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

Вполне возможно иметь два разных ключа, перечисленных в known_hosts для определенного имени хоста или IP-адреса; давая вам 2 альтернативы в зависимости от того, считаете ли вы, что вам может понадобиться «старый» ключ, который в настоящее время хранится в known_hosts

Либо удалите конкретный ключ, на который он ссылается, в l377 известных_hosts для OP, либо сохраните оба

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

Изменить known_hosts, чтобы добавить # в начале «старой» записи, на которую ссылаются в known_hosts временно
Подключите , согласитесь на приглашение добавить новый ключ «автоматически»
Затем заново отредактируйте known_hosts, чтобы удалить #

больше ответов на «Добавить правильный ключ хоста в known_hosts» /несколько ключей хоста ssh для имени хоста?

Шаг 1 — Создание пары ключей

Первый шаг — создание пары ключей на клиентской системе (обычно на вашем компьютере):

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

После ввода команды вы должны увидеть следующее:

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

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

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

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

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

Вывод затем должен выглядеть примерно следующим образом:

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

5 ответов

Вы можете сделать это, объединив и :

(к сожалению, гораздо проще не работает)

Недавно мне пришлось сделать это, поэтому я подумал, что добавлю ответ, который показывает
как это можно сделать (с версиями OpenSSH 7.2 или новее ) в одной строке
с использованием замены процесса:

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

Получить общедоступные ключи хоста

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

Тип ключа

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

(устаревший протокол SSH версии 1)
(последние версии OpenSSH)
(последние версии OpenSSH)

В современных версиях OpenSSH типы default , которые нужно извлечь, следующие:
(начиная с версии 5.1), (начиная с версии 6.0) и (начиная с версии
6.7).

С старыми версиями из (до версии OpenSSH версии 5.1)
Клавиша default была устаревшим (SSH Protocol 1), поэтому типы ключей
необходимо будет явно указать:

Получить хэши отпечатков пальцев клавиш Base64

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

Если вы используете Bash, Zsh (или оболочку Korn), процесс
замена может быть использована
для удобной однострочной линии:

Примечание : с версиями OpenSSH до 7.2 функции, используемые
, чтобы читать файлы, не обрабатывал именованные каналы (FIFO) очень хорошо, поэтому
этот метод не будет работать, что потребует использования временных файлов.

Хеширующие алгоритмы

Последние версии печатать SHA256 хэши отпечатков пальцев ключей.
Чтобы получить хеши MD5 отпечатков пальцев сервера (старое поведение),
опция может быть использована для указания алгоритма хеширования:

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

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

filezilla отображает клавиши , хэшированные с md5 в шестнадцатеричном формате .

, чтобы найти это на вашей машине ubuntu linux , используйте следующую команду:

Примечание: замените «localhost» на ip машины, которую вы хотите проверить.

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

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

Основная команда 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

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

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

Рассмотрим простой пример: вы достали из

базы данных

сертификат
MIIC4jCCAc … A7A6Rpt8V9Q==
, но он не отформатирован и не проходит валидацию

Сертификат, конечно, длиннее, я поставил троеточие для экономии места и вашего времени.

Выполните

echo ‘MIIC4jC … 7A6Rpt8V9Q==’ | base64 -d | openssl x509 -inform der

Либо, если вам нужно работать с файлами — сохраните исходный сертифика в фай

raw_cert

echo MIIC4jC … 7A6Rpt8V9Q== > raw_cert

cat raw_cert | base64 -d | openssl x509 -inform der > cert

cat cert

——BEGIN CERTIFICATE——
MIIC4jC … 7A6Rpt8V9Q==
——END CERTIFICATE——

Такого же результата можно было добиться аккуратно добавив ——BEGIN CERTIFICATE—— в начало
и ——END CERTIFICATE—— в конец файла, но не всегда всё так просто.

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

Ввод пароля для подключения через 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 [email protected], где root — логин для подключения к серверу по SSH, а 185.104.114.90 — IP-адрес или хост сервера.

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

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

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

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

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

Инструменты для анализа безопасности SSH

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

Lynis

Универсальный инструмент безопасности с открытым кодом для тестирования безопасности систем Linux. Он проверит все, что может, от загрузчика до сервера. Он бесплатный и написан с помощью shell script. Lynis работает в самой системе, поэтому может просматривать как файлы конфигурации, так и фактически загруженную конфигурацию. Он включает в себя несколько тестов для OpenSSH и его конфигураций, включая параметры безопасности. Результаты или возможные улучшения отображаются на экране, что позволяет непосредственно приступить к действиям и начать усиливать безопасность системы.

Скачайте утилиту с GitHub или с сайта. Используйте инструкцию, чтобы быстрее понять, с чего начать работу.

ssh-audit

Несмотря на то, что инструмент ssh-audit немного устарел, его стоит иметь в своем арсенале. Вместо тестирования на самом хосте, он может подключаться к SSH-серверу через сеть. Он выполняет тестирование на выбранной системе и просматривает полученные ответы, на основании которых узнает о системе и сервере SSH. Он даже узнает о конкретных уязвимостях и может предупредить о них. Загрузите инструмент через GitHub и попробуйте применить.

Чтобы найти больше информации о других инструментах, читайте раздел «Сканеры конфигурации безопасности Linux».

Настройка ssh клиента

В Debian настройки клиентской части ssh делятся на глобальные и пользовательские. Глобальные клиентские настройки находятся в файле /etc/ssh/ssh_config и применяются ко всем пользователям. Пользовательские настройки могут находиться в домашнем каталоге пользователя, в ~/.ssh/config и применяются к одному пользователю. Файл пользовательских настроек не создаётся автоматически в отличие от файла глобальных настроек клиентской части ssh. Для большинства выполняемых задач подойдут настройки по умолчанию, но для удобства использования, так сказать для тюнинга или для выполнения нестандартных задач клиентские настройки изменяются. Рассмотрим вкратце некоторые из этих настроек. Полезно помнить о приоритетах настроек: высший приоритет имеют ключи командной строки, затем следуют настройки пользователя, а после них используются глобальные настройки клиентской части.

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

Параметр HostName. Устанавливает соответствие между псевдонимами, сокращениями и настоящими именами хостов. По умолчанию используется имя, передаваемое в командной строке. Допустимо непосредственное указание IP-адресов.

Параметр Port. Порт на удалённой машине, к которому следует подключаться. Значение по умолчанию — 22

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

В качестве примера я создам файл пользовательских настроек /home/selifan/.ssh/config следующего содержания:

Host sunup

HostName sunup.aitishnik.local

Port 2203

User andrey

Host windbag

HostName windbag.nnov.ru

Port 2280

User joker

Host 212.177.65.1

HostName 212.177.65.1

Port 2222

User forester

Теперь при подключении к компьютерам sunup.aitishnik.local, windbag или по ip адресу 212.177.65.1 мне не нужно вспоминать, ни имя пользователя, ни ssh порт подключения, достаточно после ssh набрать имя сервера. Просто и удобно! Описания всех параметров, значений и некоторых примеров находятся в man ssh_config. Продолжаем настраивать SSH и читаем «Генерация ключей SSH».

Об авторе:

Меня зовут Андрей Золкин. Из более, чем пятнадцати лет работы в сфере информационных технологий, десять лет работаю с системами, базирующимися на открытом исходном коде. На страницах сайта Aitishnik.Ru веду блоги по CMC Joomla и Debian GNU/Linux.

Настройки безопасности клиента OpenSSH

Доступно множество клиентов SSH, поэтому рассказать о каждом из них в одной статье невозможно. Остановимся подробнее на инструменте клиента OpenSSH.

Конфигурация клиента

Клиент OpenSSH можно настроить тремя способами. Они обрабатываются по порядку и проверяются для каждого доступного параметра конфигурации. Выбирается первый подходящий.

Настройки задаются через командную строку;
Через файл конфигурации в домашней директории ();
Через файл конфигурации для всех пользователей ().

Допустим, есть настройка А. Она задана для всей системы (3 способ) со значением «True». Пользователь michael установил для нее значение «False» (2 способ). В этом случае второе значение в приоритете, т.к. оно рассматривается перед настройками всей системы.

Просмотр активных настроек

Помните, как мы просматривали настройки для сервера ()? У клиента есть похожий инструмент.

ssh -G abc

Здесь abc является произвольным именем хоста. Или, возможно, не совсем произвольным. Можно использовать что угодно, включая реальное имя хоста. Клиент может использовать блоки Host и Match для настройки конфигурации группы систем или отдельной системы. Если хоста abc не существует, будут рассматриваться настройки по умолчанию.

Настройки SSH для отдельной системы

Допустим, есть система secureserver. Вместо того, чтобы работать на порте 22, она принимает соединения по SSH на порте 2222. Вместо применения в командной строке можно добавить блок Host в файл конфигурации. Для этого необходимо в каталоге .ssh домашней директории создать файл config ().

Затем создадим блок и определим нужные настройки.

Host secureserver
    Hostname hostname.example.org
    User mynickname
    Port 2222
    MACs hmac-sha2-512
    KexAlgorithms [email protected]

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

Какие же настройки следует определять в файле конфигурации клиента?

Рекомендуем использовать те, которые облегчат вам ежедневную работу. Если вы отдаете предпочтение безопасности, задайте надежные настройки по умолчанию. Если какой-то хост использует другой SSH-порт, создайте блок Host и переопределите его настройки нужным образом. Что касается KexAlgorithms, используйте более новые доступные алгоритмы. Это сильно зависит от версии OpenSSH на серверах. Если на сервере используется новая версия OpenSSH, то хорошо подойдет curve25519. Это высокоскоростной алгоритм на основе эллиптических кривых, который на данный момент считается безопасным.

Ответ 5

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

sshpass

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

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

# Create a pipe

PIPE=$(mktemp -u)

mkfifo -m 600 $PIPE

# Attach it to file descriptior 3

exec 3<>$PIPE

# Delete the directory entry

rm $PIPE

# Write your password in the pipe

echo ‘my_secret_password’ >&3

# Connect with sshpass -d

sshpass -d3 ssh user@host

# Close the pipe when done

exec 3>&-

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

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

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

export SSHPASS=’my_secret_password’

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

sshpass -e ssh user@host

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

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

sshpass -p my_secret_password ssh user@host

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

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

# Generate a key pair

# Do NOT leave the passphrase empty

ssh-keygen

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

ssh-copy-id user@host

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

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

# Start the agent

eval `ssh-agent`

# Add the identity (private key) to the agent

ssh-add /path/to/private-key

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

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

ssh user@host

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

Подключение по SSH

Подключение происходит с помощью команды
ssh + имя_пользователя + хост

Например

ssh [email protected]

Если вы подключаетесь к хосту впервые, появится предупреждение

The authenticity of host ‘192.168.56.101 (192.168.56.101)’ can’t be established.
ECDSA key fingerprint is SHA256:db8az/qbrWOJWvNRv2d9UHaDBnnUHanJ9Svca9vFx7c.
Are you sure you want to continue connecting (yes/no/)?

Если выбрать yes
то в файл

~/.ssh/known_hosts

добавится похожая строка:

|1|abcdef+abcdefghijklmnopqrst=|abcdefghijklmnopqrstuvwxyz1= ssh-rsa abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrst/abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz12345/abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzB1234567

Обычно файл

known_hosts

имеет следующий формат (записи идут через пробел)

Таким образом

abcdef+abcdefghijklmnopqrst=|abcdefghijklmnopqrstuvwxyz1=

Это хэш от имени сервера.

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

Подключение к серверу через SSH

Мы уже выяснили, что представляет собой SSH и команды для него. Теперь установим соединение с сервером.

Естественно, перед началом надо арендовать виртуальный хостинг или VDS у одного из доступных провайдеров. У Timeweb, к примеру.

Если у вас macOS или Linux

Запускаем программу Terminal.
Вводим в консоль команду со следующим синтаксисом ssh имя пользователя@адрес сервера. В моем случае это ssh [email protected].
Указываем пароль суперпользователя (его отправляет хостинг-провайдер сразу после регистрации).
Жмем Enter.

Все. Соединение установлено, можно переходить к работе непосредственно с сервером.

Если у вас Windows

Скачиваем и устанавливаем программу PuTTY.
В строку IP-адрес вводим адрес своего VDS или виртуального хостинга.
Жмем на кнопку Open.
Вводим пароль администратора, чтобы получить доступ к управлению.

Управление протоколом SSH

У команды для подключения к удаленному PC по SSH есть две важных опции:

ssh -p номер порта имя пользователя@адрес сервера — заменяет стандартный 22-й порт на иной, что положительно сказывается на безопасности и устойчивости к автоматическим хакерским атакам от ботов.
ssh-copy-id -i путь до файла с ключом имя пользователя@адрес сервера— копирует ключ на сервер, чтобы вход осуществлялся без логина и пароля, а именно через ключ.

Шаг 4 — Отключение аутентификации с помощью пароля на сервере

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

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

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

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

Найдите в файле директиву . Эта строка может быть прокомментирована с помощью в начале строки. Раскомментируйте строку, удалив , и установите значение . После этого вы не сможете выполнять вход в систему через SSH с использованием паролей учетной записи:/etc/ssh/sshd_config

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

В качестве меры предосторожности откройте новое окно терминала и проверьте правильность работы службы SSH, прежде чем закрывать этот сеанс:

После проверки корректной работы службы SSH вы можете безопасно закрыть все текущие сеансы сервера.