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

Хеширование (hashing)

Еще один вид криптографических манипуляций с данными, который используется в SSH. Функция хеширования – метод создания короткой «подписи» или некая сумма данных. Основное свойство хеша заключается в его необратимости. Из него невозможно получить те данные, над которыми была выполнена функция хеширования. А еще он уникален для каждого набора данных (файла, строки, объекта…)

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

Благодаря данному свойству, хеши, в основном, используются для верификации. Главное применение в SSH – HMAC – hash-based message authentication code (проверка подлинности сообщений при помощи хеширования). Для того чтобы убедиться, что полученное сообщение не было изменено в процессе передачи.

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

Каждое сообщение, после того как будет зашифровано, «подписывается» с помощью MAC. Он вычисляется на основании симметричного ключа, порядкового номера пакета, и содержимого сообщения.

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

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

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

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

Такая схема еще часто называется с «общим секретом» (shared secret) или «секретный ключ». Чаще используется один ключ для всех операций, или пара ключей.

Симметричные ключи используются в SSH для шифрования всего соединения. Стоит отметить, что речь не о паре ключей public/private, которые применяются для авторизации. Они не имеют отношения к соединению, как таковому. Симметричное шифрование защищает, так же, и сам процесс ввода логина/пароля от «подслушивания».

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

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

SSH можно сконфигурировать, чтобы использовались различные системы симметричного шифрования: AES, Blowfish, 3DES, CAST128 и Arcfour. Сервер и клиент, имеют список поддерживаемых систем, которые указаны в порядке приоритета. Первый из списка клиента, поддерживаемый сервером, используется для соединения.

В Ubuntu 14.04, список алгоритмов, по умолчанию, представлен следующим порядком: aes128-ctr, aes192-ctr, aes256-ctr, arcfour256, arcfour128, [email protected], [email protected], [email protected], aes128-cbc, blowfish-cbc, cast128-cbc, aes192-cbc, aes256-cbc, arcfour.

Если две машины, под управлением Ubuntu 14.04 соединяются друг с другом (при условии, конечно, что в конфигурационных файлах не изменялись настройки по умолчанию), они всегда будут использовать aes128-ctr.

Добавить ключ на сервер

Вариант 1:

Вручную скопировать публичную часть ключа в файл
~/.ssh/authorized_keys  на сервере:

$ cat ~/.ssh/key.pub | ssh username@hostname ‘cat >> ~/.ssh/authorized_keys

1	$ cat ~/.ssh/key.pub | ssh username@hostname ‘cat >> ~/.ssh/authorized_keys

Вариант 2:

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

Пример:

$ ssh-copy-id -i ~/.ssh/key username@hostname

1	$ ssh-copy-id -i ~/.ssh/key username@hostname

В любом случае сначала будет запрошен пароль для подключения к серверу hostname с логином username.

Конфигурация сервера

Как вы помните, в качестве сервера у нас виртуальный сервер от ATLEX с предустановленной Ubuntu 20.04 LTS. Мы предполагаем, что наш сервер доступен по SSH и некоторая его предварительная настройка уже произведена (например, добавлен пользователь с правами sudo, запрещен доступ рутом по SSH, запрещен доступ через SSH по паролям и разрешен только по публичным ключам). Хотя такая настройка и необязательно для этой статьи, мы рекомендуем произвести ее в целях безопасности.

Ок, теперь давайте зайдем на сервер по SSH и для начала проверим версию ОС и пакета SSH.

(все верно, у нас установлена Ubuntu 20.04 LTS)

(и у нас нужная версия SSH, ничего дополнительно устанавливать или апгрейдить не нужно).

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

А теперь вернемся к серверу и добавим этот ключ в файл

Сохраняем файл и возвращаемся вновь к клиентской машине.

Сетевые настройки SSHv2

Сетевых настроек будет много, но большинство из них тривиальны – “что использовать” и “как фильтровать трафик”, поэтому по разделу на каждую заводить смысла нет.

Блок будет выглядеть примерно так:

Port 22 AddressFamily inet IgnoreRhosts yes UseDNS no ListenAddress x.x.x.x TCPKeepAlive yes #VerifyHostKeyDNS no #UseRoaming no

Часть настроек понятна – например Port 22 привязывает сервис SSH к указанному номеру порта, который можно при необходимости изменить – как минимум, чтобы боты-подбиратели-паролей не стучались, а ListenAddress явно указывает, на каких L3-адресах принимать запросы на подключение (ограничение актуально в случае нескольких адресов и/или сетевых интерфейсов, либо в сценарии “у хоста могут появляться на ходу новые сетевые интерфейсы, и это не значит, что на них надо ждать SSH-подключений”). Другие же настройки менее очевидны.

AddressFamily inet говорит о том, что мы будем ждать подключений только по IPv4. Если у вас используется IPv6 и подключения к SSH-серверу возможны по нему – добавьте AddressFamily inet,inet6.

TCPKeepAlive yes будет нужен, чтобы на сетевом уровне определять отключившихся пользователей и прекращать их сеансы. Выключение этого механизма, которое иногда рекомендуется “для экономии трафика” (слёзы, а не экономия) приведёт к ситуации, когда ssh не сможет в ряде случаев понять, что пользователь не просто неактивен, а уже никогда не сможет продолжить работу в данной сессии. Поэтому включаем.

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

UseDNS no будет нужна, чтобы отключить проверку PTR-записи у подключающегося абонента – помимо того, что во внутренней сети, да и при подключении из внешних тоже наличие PTR совершенно необязательно, данная мера лишь замедляет подключение, а уровень безопасности не поднимает – максимум, что делает – пишет в журнал warning про “подключающийся не сказал своё настоящее FQDN-имя”. Хотя возможна ситуация, когда проверка эта включена, а DNS на узле не работает (например, указывает на неправильный IP-адрес DNS-сервера) – в этом случае возможен сценарий, что подключиться к узлу не получится. Но это совсем не “защитная мера” а, скорее, ещё одна причина отключать эту проверку, т.к. из-за неё, получается, растёт количество задействованных подсистем, а следовательно падает общая надёжность работы системы.

VerifyHostKeyDNS no отключает механизм SSHFP, который практически не используется в сетях, а вот запросы на тему “а есть ли такая экзотическая запись в вашем DNS” – отправляются. Конечно, если у вас в сети SSHFP используется, то отключать его не надо. Это по своей логике клиентская настройка, но почему-то иногда встречаются мысли “включить её на сервере”. Я её добавил в этот список и закомментировал, чтобы подчеркнуть данный момент – не нужно в настройках сервера эту опцию указывать.

UseRoaming no выключает поддержку роуминга – экспериментального расширения OpenSSH, которое должно было обрабатывать сценарии вида “начал админить из одного места, потом перешёл в другое и продолжил оттуда”. По факту функционал этот оказался никому не нужен и никаких прорывных нововведений не добавил, а вот проблемы безопасности – вплоть до уязвимостей с PoC – принёс. Поэтому в явном виде отключаем. Как и предыдущий параметр – клиентский, т.е. здесь приведён потому что опять же в ряде гайдов пишется “выключите везде, и на клиенте, и на сервере”. Это не так, только на клиенте.

Как подключиться по SHH

Для подключения к удаленному серверу необходима специальная программа. В *nix-подобных операционных системах подобная программа установлена по умолчанию. Для Windows необходимо установить стороннюю программу, например, скачать Putty. После установки программы запустите Putty ().

В поле «Host Name (or IP address)» введите IP адрес удаленного сервера и нажмите кнопку «Open»

Обратите внимание, что «Connection type» (Тип подключения) должен быть установлен SSH. Откроется SSH консоль, где необходимо ввести имя пользователя и вводе пароля никакие символы не будут отображаться

Запоминаем пароль с помощью ssh-agent

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

Для добавления ключей в список для использования во время работы на компьютере используем сервис ssh-agent.

Проверим состояние ssh-agent:

ps -C ssh-agent
= вывод команды =
 PID TTY TIME CMD
 4564 ? 00:00:00 ssh-agent

Теперь нам надо добавить нужный ключ командой:

ssh-add /home/user/.ssh/rsa_sevo44
= вывод команды =
Enter passphrase for /home/user/.ssh/rsa_sevo44: вводим пароль
Identity added: /home/user/.ssh/rsa_sevo44 (/home/user/.ssh/rsa_sevo44)

После перезагрузки данную процедуру придется повторить!

Посмотреть добавленные ключи можно командой:

ssh-add -l
= вывод команды =
1024 SHA256:A9d+2cz6M1GK482oOxf/zweqt9B18WPox04m+Deczgc /home/user/.ssh/rsa_sevo44 (RSA)

Для удаления всех ключей применим опцию -D:

ssh-add -D
= вывод команды =
All identities removed.

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

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

Задача. На удаленном компьютере 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

Использование секретного ключа для подключения по SSH

Этот раздел посвящен настройке SSH-клиентов для аутентификации по RSA-ключам на сетевом оборудовании (или другом оборудовании, при условии, что оборудование и ПО поддерживает аутентификацию по публичным ключам). Мы рассмотрим настройку использования публичного ключа в самых популярных программах: SecureCRT и PuTTY.

SecureCRT

В окне настроек SSH есть список Authentication. В нём необходимо увеличить приоритет PublicKey до самого высокого — сделать верхним в списке.

Затем перейдите в параметры PublicKey и выберите файл приватного ключа. Самый верхний переключатель позволяет использовать глобальные настройки секретного ключа или сеансовые настройки — другой секретный ключ (ключ не по умолчанию) — только для этого подключения.

Настраиваем глобальный публичный ключ: в меню Options → Global options → Категория SSH2.

PuTTY

В настройках SSH (Connection → SSH → Auth) в поле “Private key file for authentication” укажите файл Putty Private Key (*.ppk):

MAC OS X

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

• Подключение с нестандартным ключом (non-default key), указанным вручную: artemiy-2:~ ArtemiySP$ ssh -i ~/Documents/python/r4 The authenticity of host ‘10.31.73.29 (10.31.73.29)’ can’t be established. RSA key fingerprint is SHA256:fxOLFKU6YGyIqisrIh2P0O52Rr6Wx/wsSAcHsTz8fo0. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added ‘10.31.73.29’ (RSA) to the list of known hosts. CSR-4#
• Подключение с нестандартным ключом (non-default key), указанным вручную: artemiy-2:~ ArtemiySP$ ssh -i ~/Documents/python/r5 The authenticity of host ‘10.31.73.30 (10.31.73.30)’ can’t be established. RSA key fingerprint is SHA256:4l67C4Il4pTaqYT4vrtWr0aY7rPmNWKsjRv2zlYtQIU. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added ‘10.31.73.30’ (RSA) to the list of known hosts. MGTU#exit Connection to 10.31.73.30 closed.Ошибка примера

  Я не смог сделать снимок с запросом пароля — пароль записался в открытую сессию пользователя. Для запроса пароля в MAC OS X — необходимо разлогиниться и залогиниться снова.

• Подключение с ключом по умолчанию (default key – система сама найдет и использует Default public key): artemiy-2:~ ArtemiySP$ ssh The authenticity of host ‘10.31.73.31 (10.31.73.31)’ can’t be established. RSA key fingerprint is SHA256:2/ysACJQw48Q8S45ody4wna+6nJspcsEU558HiUN43Q. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added ‘10.31.73.31’ (RSA) to the list of known hosts. PR#exit Connection to 10.31.73.31 closed. artemiy-2:~ ArtemiySP$

Как упростить работу с SSH на MAC OS X:

• Создаём SSH Aliases.
• В SSH Aliases сразу задаём пользователей.
• Сразу прописываем местонахождение ключей.

Местонахождение Aliases и преднастроенная конфигурация SSH указаны в файле ~/.ssh/config (/Users//.ssh/config). Заполняется таким образом:

host r4 Hostname 10.31.73.29 Port 22 User r4 IdentityFile ~/Documents/python/r4 host r5 Hostname 10.31.73.30 Port 22 User r5 IdentityFile ~/Documents/python/r5 host r6 Hostname 10.31.73.31 Port 22 User r6 Примечание: у меня некорректно настроено подключение по умолчанию (как правильно, я не знаю), потому что подключение к хосту R6 (10.31.73.31) выполняется очень долго. Рекомендуется указать сразу указать путь к ключу по умолчанию.

Пример подключения по ssh используя публичные ключи и файл config:

artemiy-2:Documents ArtemiySP$ ssh r5 MGTU#exit Connection to 10.31.73.30 closed by remote host. Connection to 10.31.73.30 closed. artemiy-2:Documents ArtemiySP$ ssh r4 CSR-4#exit Connection to 10.31.73.29 closed by remote host. Connection to 10.31.73.29 closed. artemiy-2:Documents ArtemiySP$ ssh r6 PR#exit Connection to 10.31.73.31 closed. artemiy-2:Documents ArtemiySP$ ssh r6 PR#

Putty – SSH авторизация по сертификатам

Генерируем ключи с помощью ssh-keygen

Для начала необходимо сгенерировать ключи с помощью команды

ssh-keygen

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

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

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

В конце ssh-keygen покажет куда сохранены открытый и закрытый ключи, отпечаток ключа и рандомную картинку ключа.

SSH авторизация по сертификатам через Putty

Теперь необходимо установить открытый ключ на наш сервер. Используем для этого ssh-copy-id

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

Утилита используемая для доставки ключей на удалённые хосты. Можно применить её на текущий хост указав localhost вместо имени или адреса сервера к которому подключаемся

ssh-copy-id adminguideru@localhost

Если ssh отпечаток системе не знаком, она попросит подтвердить намерения подключения. Пишем yes. Когда утилита запросит пароль от учётной записи в которую мы пытаемся скопировать ключи, вводим его.

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

ssh adminguideru@localhost

Если авторизация прошла успешно, мы увидим как запустится консоль сервера. Так как в данном случае мы подключаемся с текущего сервера на него же, какого-либо практического смысла, кроме как для теста, это действие не имеет.. Просто введите exit чтобы разорвать данное “виртуальное” ssh подключение и вывалиться в свою исконную сессию.

Ключи SSH. Или метод Identity/Pubkey

При использовании метода идентификации Identity/Pubkey исключается использования статических паролей. Чтобы каждый раз не набирать пароли, которые можно перехватить с помощью “keylogger’а”, вы будете хранить на диске несколько ключей, которые и будут использоваться для проверки подлинности.

Вот некоторые из положительных моментов этого типа аутентификации:

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

Тест на практике

Прежде всего, нам нужен пакет OpenSSH версии 8.2 на клиентской и серверной машинах. И здесь кроется основная проблема с этим решением на момент написания этого материала (май 2020). Поскольку 8.2 — это новейшая версия, выпущенная в феврале 2020 года, во многих ОС пока еще используются предыдущие версии.

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

По состоянию на май 2020 только несколько популярных дистрибутивов Linux имеют версию OpenSSH 8.2 в своих репозиториях. Среди них Fedora 32, Ubuntu 20.04 LTS и Kali Linux.

Настройка безопасности SSH – Заключение

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

sudo cp /etc/ssh/sshd_ /etc/ssh/sshd_config

Ну или ручками найдя в нём ошибку.

Проверяем что на настраиваемые хосты пускает по сертификату через Putty. Если настраивалось межсерверное взаимодействие, проверяем что под рутом каждого из хостов пускает на другие хосты. Радуемся. Отныне вероятнее всего напакостить вам по SSH сможете только вы сами.