Как добавить dsa в sshd linux

Как настроить sshd на прием паролей и ключей dsa одновременно?

Да это, вроде бы, и так стандартное поведение. Прислали ключ — хорошо. Не прислали — давай пароль проверять.

dmiceman ★★★★★
( 24.09.17 17:41:43 MSK )

Так вроде одна возможность не отменяет другую, если ключ совать при соединении не будешь, то пароль спросит, а если надо задать разные параметры, то у sshd в конфиге можно задавать параметры после строки match user или group, что-то такое. Я это использую чтобы определить файл с ключами для пользователей у которых нет home.

anonymous
( 24.09.17 17:47:50 MSK )
Ответ на: комментарий от anonymous 24.09.17 17:47:50 MSK

В sshd 7 версии dsa выключили по умолчанию(((. А нужен именно dsa

Как добавить dsa в sshd linux

В данной инструкции мы рассмотрим настройку подключения к удалённому серверу/VPS с Unix и Windows систем.

1) Заходим в домашний каталог и находим директорию .ssh или создаём, если её нет. Выставляем права 600.

# touch ~/.ssh
# chmod 600 ~/.ssh
# cd ~/.ssh 

2) Генерируем ключ:

# ssh-keygen -t dsa -b 1024 -f ~/.ssh/auth_key

• -t dsa — тип ключа
• -b 1024 — длина ключа
• -f ~/.ssh/auth_key — директория хранения ключа и его название. auth_key — приватный ключ, auth_key.pub — публичный

Фразу-пароль можем пропустить.

auth_key — будет храниться на сервере/компьютере с которого мы будем выполнять подключение.

auth_key.pub — публичный ключ, размещаем на сервере к которому будем подключаться, в папке пользователя (пример: /home/user/.ssh)

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

Сделать это можно следующей командой:

# ssh -i ~/.ssh/auth_key user@192.168.0.1

• ~/.ssh/auth_key — путь к ключу на нашем компьютере
• user — имя пользователя под которым подключаемся и в директорию которого мы загрузили публичный ключ.
• 192.168.0.1 — сервер к которому подключаемся.

Подтверждаем вход — Enter.

Windows:

Для создания ключа и подключения к серверу нам понадобиться 2 программы:

• PuTTY— SSH клиент
• PuTTYGen— Утилита, предназначенная для генерации RSA и DSA ключей.

Скачать их можно на официальном сайте

1) Генерируем ключи.

Запускаем PuTTYGen, внизу выбираем тип и длину ключа, нажимаем «Генерировать»:

2) Сохраняем личный и публичный(открытый) ключи.

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

3) Настраиваем сервер к которому будем проводить подключение.

Сначала подключаемся «как обычно» по логину и паролю. В домашнем каталоге пользователя создаем(если нет) директорию .ssh и устанавливаем права 600.

# touch ~/.ssh
# chmod 600 ~/.ssh
# cd ~/.ssh 

Теперь создадим файл:

# touch authorized_keys
# chmod 600 authorized_keys
# vi authorized_keys

И в него вставим сгенерированный публичный(открытый) ключ из окна PuTTYGen > «Открытый ключ для вставки. «.

Сохраняем изменения в файле и отключаемся от сервера.

4) Настраиваем PuTTY и подключаемся по ключу.

Открываем PuTTY > Соединение > SSH > Аутентификация > Указываем путь к приватному(личному) ключу.

Далее сохраняем настройки подключения и подключаемся к серверу.

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

Подключение по логину и паролю через PuTTY:

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

Для этого у нас должны быть host (ip-сервера), имя пользователя, пароль пользователя.

1) Открываем PuTTY и вставляем имя хоста в соответствующую строку, после чего подключаемся к серверу:

2) Далее поочередно вводим логин (имя пользователя) и пароль.

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

Также, могут быть полезны статьи:

21.3. Настройка клиента OpenSSH

Чтобы подключиться к серверу OpenSSH с клиентского компьютера, на этом компьютере вы должны установить пакеты openssh-clients и openssh .

21.3.1. Использование команды ssh

Команда ssh является безопасной заменой команд rlogin , rsh и telnet . Она позволяет вам регистрироваться и выполнять команды на удалённом компьютере.

Регистрация на удалённом компьютере с помощью ssh похожа на использование telnet . Чтобы зарегистрироваться на удалённом компьютере с именем penguin.example.net, введите следующую команду в приглашении оболочки:

При первом ssh -подключении к удалённому компьютеру вы увидите подобное сообщение:

The authenticity of host ‘penguin.example.net’ can’t be established. DSA key fingerprint is 94:68:3a:3a:bc:f3:9a:9b:01:5d:b3:07:38:e2:11:0c. Are you sure you want to continue connecting (yes/no)?

Введите yes для продолжения. При этом сервер будет добавлен в ваш список известных узлов ~/.ssh/known_hosts/ ), о чём говорит следующее сообщение:

Warning: Permanently added ‘penguin.example.net’ (RSA) to the list of known hosts.

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

ssh username @penguin.example.net

Вы можете использовать и такую запись: ssh -l username penguin.example.net .

Команда ssh может применяться для выполнения команд на удалённом компьютере без использования приглашения оболочки. При этом используется запись: ssh hostname command . Например, если вы хотите выполнить команду ls /usr/share/doc на удалённом компьютере penguin.example.net, введите в приглашении оболочки:

ssh penguin.example.net ls /usr/share/doc

Когда вы введёте правильный пароль, на экране появится содержимое удалённого каталога /usr/share/doc и вы вернётесь к приглашению своей локальной оболочки.

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

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

Здесь указывает исходный файл, включая путь к нему, например, /var/log/maillog . Параметр определяет назначение; это может быть новое имя файла, например /tmp/hostname-maillog . Если вы не укажите в начале пути удалённого каталога / , будет выбран путь относительно домашнего каталога пользователя username , обычно это /home/username/ .

Чтобы переслать локальный файл shadowman в домашний каталог вашей учётной записи на компьютере penguin.example.net, введите в приглашении оболочки следующее (подставьте вместо username ваше имя пользователя):

scp shadowman username @penguin.example.net:shadowman

При этом локальный файл shadowman скопируется в /home/ username /shadowman на компьютере penguin.example.net. Вы также можете опустить имя файла shadowman в конце команды scp .

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

Где обозначает исходный файл, включая путь, а — назначение, включая путь.

В качестве исходных файлов можно указать несколько файлов. Например, чтобы переслать содержимое каталога downloads/ в существующий каталог uploads/ удалённого компьютера penguin.example.net, введите в приглашении оболочки следующую команду:

scp downloads/* username @penguin.example.net:uploads/

Утилита sftp используется для создания защищенного, интерактивного сеанса FTP. Она похожа на ftp , за исключением того, что используется безопасное, зашифрованное соединение. Общий синтакстис команды: sftp username@hostname.com . Пройдя проверку подлинности, вы можете использовать тот же набор команд, что и с FTP. Список этих команд можно получить на странице man sftp . Чтобы прочитать страницу man, выполните в приглашении оболочки man sftp . Утилита sftp включена в состав пакета OpenSSH версии 2.5.0p1 и выше.

21.3.4. Создание пар ключей

Если вы не хотите вводить пароль при каждом подключении к удалённому компьютеру с помощью ssh , scp или sftp , вы можете создать пару ключей для авторизации.

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

Начиная с OpenSSH верии 3.0, файлы ~/.ssh/authorized_keys2 , ~/.ssh/known_hosts2 и /etc/ssh_known_hosts2 являются устаревшими. В протоколах SSH 1 и 2 используются файлы ~/.ssh/authorized_keys , ~/.ssh/known_hosts и /etc/ssh/ssh_known_hosts .

Red Hat Enterprise Linux 4 по умолчанию использует протокол SSH версии 2 и ключи RSA.

Подсказка

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

21.3.4.1. Создание пары ключей RSA для версии 2

Чтобы создать пару ключей RSA для версии 2 протокола SSH, следуйте следующим указаниям. OpenSSH, начиная с версии 2.9, по умолчанию использует этот протокол.

Чтобы создать пару ключей RSA, работающих с протоколом версии 2, введите в приглашении оболочки следующую команду:

ssh-keygen -t rsa

Согласитесь с предложенным расположением файла ~/.ssh/id_rsa . Введите секретную фразу, отличную от пароля вашей учётной записи и подтвердите её.

Открытый ключ сохраняется в файле ~/.ssh/id_rsa.pub . Закрытый ключ сохраняется в ~/.ssh/id_rsa.pub . Никогда не давайте свой закрытый ключ никому.

Измените разрешения на каталог .ssh , выполнив следующую команду:

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

Измените разрешения файла authorized_keys , выполнив следующую команду:

chmod 644 ~/.ssh/authorized_keys

Если вы используете GNOME, перейдите к разделу 21.3.4.4 Настройка ssh-agent в GNOME . Если вы не используйте систему X Window , перейдите к разделу 21.3.4.5 Настройка ssh-agent .

21.3.4.2. Создание пары ключей DSA для версии 2

Выполните следующие действия для создания пары ключей DSA для версии 2 протокола SSH.

Чтобы создать пару ключей DSA, работающих с протоколом версии 2, введите в приглашение оболочки следующую команду:

ssh-keygen -t dsa

Согласитесь с предложенным расположением файла ~/.ssh/id_dsa . Введите секретную фразу, отличную от пароля вашей учётной записи и подтвердите её.

Подсказка

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

Открытый ключ сохраняется в файле ~/.ssh/id_dsa.pub . Закрытый ключ сохраняется в ~/.ssh/id_dsa . Важно никогда и никому не давать свой закрытый ключ.

Измените разрешения на каталог .ssh с помощью следующей команды:

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

Измените разрешения файла authorized_keys , выполнив следующую команду:

chmod 644 ~/.ssh/authorized_keys

21.3.4.3. Создание пары ключей RSA для версии 1.3 и 1.5

Выполните следующие действия для создания пары ключей RSA для версии 1 протокола SSH. Если вы системы, который вы соединяете, используют только DSA, пара ключей для RSA версий 1.3 и 1.5 вам не нужна.

Чтобы создать пару ключей RSA (для версий протокола 1.3 и 1.5), введите в приглашении оболочки следующую команду:

ssh-keygen -t rsa1

Согласитесь с предложенным расположением файла ( ~/.ssh/identity ). Введите секретную фразу, отличную от пароля вашей учётной записи. Подтвердите секретную фразу, введя её снова.

Открытый ключ сохраняется в файле ~/.ssh/identity.pub . Закрытый ключ сохраняется в ~/.ssh/identity . Не давайте никому свой закрытый ключ.

Измените права доступа к своему каталогу .ssh и ключу, выполнив команды chmod 755 ~/.ssh и chmod 644 ~/.ssh/identity.pub .

Скопируйте содержимое ~/.ssh/identity.pub в файл ~/.ssh/authorized_keys на компьютер, к которому вы хотите подключиться. Если файл ~/.ssh/authorized_keys не существует, вы можете скопировать файл ~/.ssh/identity.pub в файл ~/.ssh/authorized_keys удалённого компьютера.

Программа ssh-agent может сохранять вашу секретную фразу, чтобы вам не понадобилось вводить её при каждом установлении соединения ssh или scp . Если вы работает в GNOME, вы можете воспользоваться программой, которое спросит у вас секретную фразу при входе в систему и сохранит её до выхода из GNOME (она включена в пакет openssh-askpass-gnome ). В этом случае вам не придётся вводить пароль или секретную фразу для каждого ssh или scp -соединения, установленного в течении этого сеанса GNOME. Если вы не используете GNOME, перейдите к разделу 21.3.4.5 Настройка ssh-agent .

Чтобы сохранить вашу секретную фразу в течение сеанса GNOME, выполните следующие действия:

Вам потребуется установить пакет openssh-askpass-gnome ; чтобы проверить, установлен ли он, выполните команду rpm -q openssh-askpass-gnome . Если он не установлен, установите его с компакт-дисков Red Hat Enterprise Linux, FTP-сайта (или зеркала) Red Hat или воспользуйтесь сетью Red Hat Network.

Выберите в Главном меню (Main Menu) (на панели) => Параметры (Preferences) => Дополнительные параметры (More Preferences) => Сеансы (Sessions) и перейдите на вкладку Программы, запускаемые при старте (Startup Programs) . Нажмите кнопку Добавить (Add) и введите /usr/bin/ssh-add в текстовом поле Команда, запускаемая при старте (Startup Command) . Задайте коэфициент приоритета, больший, чем у любой существующей команды, чтобы эта команда выполнялась последней. Подходящим значением приоритета для ssh-add будет 70 или выше. Чем выше коэффициент приоритета, тем ниже приоритет. Если у вас перечислены другие программы, это должна иметь наименьший приоритет. Нажмите Закрыть (Close) , чтобы выйти из программы.

Выйдите из системы и вернитесь в GNOME; другими словами, перезапустите X. После запуска GNOME на экране появляется диалог, предлагающий ввести вашу секретную фразу. Введите требуемую секретную фразу. Если вы создавали пары ключей DSA и RSA, вы будете вводить обе фразы. С этого момента вы не будете вводить пароль для того, чтобы использовать ssh , scp или sftp .

Программа ssh-agent может сохранять вашу секретную фразу, чтобы вам не понадобилось вводить её при каждом установлении соединения ssh или scp . Если вы не используете X Window System, выполните следующие действия в приглашении оболочки. Если вы используете GNOME, но не хотите, чтобы он спрашивал вас секретную фразу при регистрации (как описано в разделе 21.3.4.4 Настройка ssh-agent в GNOME ), эта процедура будет работать в окне терминала, например, XTerm. Если же вы используете X, но не GNOME, в окне терминала будет работать следующая процедура. Однако, ваша секретная фраза будет сохранена только в окне терминала; она не будет доступна глобально.

В приглашении оболочки выполните следующую команду:

exec /usr/bin/ssh-agent $SHELL

Затем введите команду:

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

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

Назад	Начало	Вперёд
Настройка сервера OpenSSH	Вверх	Дополнительные ресурсы

Более безопасное подключение к SSH с помощью DNSSEC

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

В реальной жизни почти никто не проверяет отпечаток SSH-ключа сервера не особенно задумываясь о возможности MiTM-атаках. С появлением DNS-записи SSHFP отпечаток ключа сервера можно хранить в DNS и проверять его подлинность с помощью DNSSEC. При этом не нужно даже подтверждать ключ при первом подключении. В статье разберем, как настроить запись SSHFP для своего SSH-сервера.

Сервер для тестов

Для начала нам потребуется сервер.В панели RuVDS реквизиты для SSH-доступа находятся сразу на карточке сервера. Сохраняем IP-адрес и пароль для подключения.

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

Для настройки SSHFP на IP-адрес сервера должен быть направлен домен, именно для этого домена мы будем настраивать DNS-записи.

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

В примерах мы будем рассматривать только пакет OpenSSH, так как это самый популярный вариант.

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

Файлы с ключами находятся здесь:

$ ls -la /etc/ssh/ssh_host_*_key* /etc/ssh/ssh_host_dsa_key /etc/ssh/ssh_host_dsa_key.pub /etc/ssh/ssh_host_ecdsa_key /etc/ssh/ssh_host_ecdsa_key.pub /etc/ssh/ssh_host_ed25519_key /etc/ssh/ssh_host_ed25519_key.pub /etc/ssh/ssh_host_rsa_key /etc/ssh/ssh_host_rsa_key.pub 

В этом списке есть сразу несколько ключей разного типа: dsa, rsa, ecdsa, ed25519. Это сделано для совместимости с разными SSH-клиентами. На этапе подключения клиент и сервер согласовывают, какой алгоритм ключа будет использоваться. Клиент может попросить сервер использовать другой алгоритм, если предложенный не поддерживается. Сервер посылает публичную часть своего ключа клиенту и пользователю предлагается проверить его отпечаток вручную.

Сервер посылает клиенту отпечаток публичного ключа в момент подключения

Если это первое подключение, клиенту будет показано сообщение с требованием проверить отпечаток ключа вручную:

The authenticity of host 'example.com (123.45.67.89)' can't be established. ECDSA key fingerprint is SHA256:7Q4nIqjuo/lSXWFkt9RaJYVHrT6LUAc6KWrdQ4/DDeA. Are you sure you want to continue connecting (yes/no/[fingerprint])? 

На этом этапе мы все обычно нажимаем Yes не задумываясь и отпечаток ключа сохраняется в файл ~/.ssh/known_hosts . Теперь если ключ на сервере изменится, клиенту будет показано сообщение о возможной MiTM-атаке. Предполагается, что в самый первый раз клиент выполнил проверку ключа самостоятельно и убедился, в его подлинности.

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

Храним отпечаток ключа в DNS. Что такое записи SSHFP

Как узнать, что предложенный сервером SSH-ключ действительно настоящий и это не MiTM-атака? Ведь для того чтобы зайти на сервер и проверить ключ нужно сперва ввести пароль. Но тогда атакующий сможет моментально взломать сервер и подменить все данные на нем, да так, что мы и не заметим подвоха. Поэтому нужен способ проверить подлинность ключа еще ДО реального подключения.

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

SSHFP позволяет проверить подлинность ключа сервера до подключения через DNS

SSHFP — тип записей DNS для хранения SSH-ключей. Отпечаток SSH-ключа помещается в DNS-сервер подобно TXT записи и подписывается ключом DNSSEC. То есть при первом подключении к серверу с использованием имени хоста, клиент сможет заранее узнать отпечаток ключа сервера через DNS, и если он совпадает с предложенным сервером, то подключаться без предупреждения.

Настройка DNSSEC

Для использования SSHFP потребуется доменное имя с настроенным DNSSEC. Есть множество публичных DNS-сервисов, которые предлагают панель управления DNS сразу с функцией DNSSEC. Самый популярный такой сервис — CloudFlare. Рассмотрим настройку на его примере. Для следующий действий домен должен быть делегирован NS-сервера Cloudflare.

▍Шаг 1 — сгенерировать ключ

Заходим в панель DNS —> Enable DNSSEC

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

▍Шаг 2 — добавление публичных ключей у регистратора

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

На примере ниже показано как соотносятся значения, показанные в панели CloudFlare со значениями в панели управления доменом у регистратора Uniregistry.

▍Шаг 3 — проверка добавленных DS-записей

После добавления DS-записей на стороне регистратора можно проверить корректность настроек. На стороне CloudFlare подписание DNS-записей будет активировано, только когда будет пройдена проверка корректности добавления DS-записей на стороне регистратора.

Ожидание добавления DS-записей

Через пару минут или часов, если записи были добавлены корректно, вы увидите такое сообщение. Это значит, что DNS-ответы теперь подписываются с помощью DNSSEC.

▍Шаг 4 — проверка работы DNSSEC

Теперь можно проверить работу DNSSEC на нашем домене с помощью онлайн-сервисов вроде dnssec-analyzer.verisignlabs.com. Все галочки должны быть зелеными.

Результат проверки DNSSEC

Добавление записей SSHFP

Сгенерируем SSHFP-записи на сервере. В нашем примере мы администрируем сервер с адресом myserver.com. Для этого доменного имени мы ранее настроили DNSSEC.

На сервере выполняем команду:

# Сгенерировать записи SSHFP из существующих SSH-ключей sudo ssh-keygen -r myserver.com myserver.com IN SSHFP 1 1 057ecce168ace29d5a0099e3b63df2850e4c8e20 myserver.com IN SSHFP 1 2 52cd6099a304b9b8f57f2cd914e96a1b7477eb2f88c98c602 myserver.com IN SSHFP 2 1 42d677482e4450ee515d3aac94d96302a99bd4ec myserver.com IN SSHFP 2 2 edda5fa445dc0da570c772a6df0d4012037e1a102840d29c4 . 

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

Теперь все эти записи нужно добавить в панели DNS, в нашем случае Cloudflare.

Добавление записи SSHFP в панели Cloudflare

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

dig SSHFP myserver.com 

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

Подключаемся к серверу

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

# Редактируем конфиг vi ~/.ssh/config VerifyHostKeyDNS yes 

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

# Подключаемся к серверу ssh -v root@myserver.com # DNS настроен неправильно, записей SSHFP нет debug1: kex: host key algorithm: ecdsa-sha2-nistp256 debug1: expecting SSH2_MSG_KEX_ECDH_REPLY . DNS lookup error: data does not exist # DNS настроен правильно, но системный резолвер # не поддерживает валидацию DNSSEC debug1: kex: host key algorithm: ecdsa-sha2-nistp256 debug1: expecting SSH2_MSG_KEX_ECDH_REPLY . debug1: found 8 insecure fingerprints in DNS debug1: matching host key fingerprint found in DNS # DNS настроен правильно, системный резолвер поддерживает DNSSEC debug1: kex: host key algorithm: ecdsa-sha2-nistp256 debug1: expecting SSH2_MSG_KEX_ECDH_REPLY . debug1: found 8 secure fingerprints in DNS debug1: matching host key fingerprint found in DNS debug1: ssh_rsa_verify: signature correct 

Если все настроено правильно, то при первом подключении к серверу не будет запрошена ручная проверка отпечатка ключа. Для этого также нужно, чтобы системный DNS-резолвер поддерживал валидацию DNSSEC.

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

• Блог компании RUVDS.com
• Информационная безопасность
• Серверная оптимизация
• Серверное администрирование