Рейтинг:0

ssh-keyscan для known_hosts не дает результатов

флаг gb
A L

Когда я выполняю:

ssh-keyscan-H 172.22.56.2

Я получаю следующий вывод:

# 172.22.56.2:22 SSH-2.0-RomSShell_4.31
# 172.22.56.2:22 SSH-2.0-RomSShell_4.31
# 172.22.56.2:22 SSH-2.0-RomSShell_4.31
# 172.22.56.2:22 SSH-2.0-RomSShell_4.31
# 172.22.56.2:22 SSH-2.0-RomSShell_4.31

Если я попытаюсь:

ssh-keyscan -H 172.22.56.2 >> ~/.ssh/known_hosts

Не будучи знакомым с ssh-keyscan, но полагая, что вывод, который я получил, был ... не тем, что я искал, я также пробовал варианты -t, например:

ssh-keyscan -H -t rsa 172.22.56.2 >> ~/.ssh/known_hosts

Все результаты одинаковы. Права доступа к файлу:

-rw-r--r-- 1 имя пользователя имя пользователя 886

«Имя пользователя» — это то, что запускает приведенные выше команды. Это оставляет меня со следующими вопросами:

  1. Что означает мой вывод ssh-keyscan? Я бы ожидал здесь что-то вроде строки |1|weofijgojw = sshkey.
  2. Почему в ~/.ssh/known_hosts ничего не записывается? Нет никаких признаков проблем, о которых мне сообщили / команда принимает

Заранее спасибо за любую информацию!

ОБНОВЛЕНИЕ 1:

пользователь@имя_хоста:~$ ssh пользователь@172.22.56.2
Не удалось согласовать порт 22 172.22.56.2: не найден подходящий метод обмена ключами. Их предложение: diffie-hellman-group1-sha1

user@hostname:~$ ssh [email protected] -oKexAlgorithms=+diffie-hellman-group1-sha1
Не удалось согласовать порт 22 172.22.56.2: соответствующий тип ключа хоста не найден. Их предложение: ssh-dss

user@hostname:~$ ssh [email protected] -oKexAlgorithms=+diffie-hellman-group1-sha1 -oHostKeyAlgorithms=+ssh-dss
Не удалось согласовать с портом 22 172.22.56.2: соответствующий шифр не найден. Их предложение: 3des-cbc

user@hostname:~$ ssh [email protected] -oKexAlgorithms=+diffie-hellman-group1-sha1 -oHostKeyAlgorithms=+ssh-dss -oCiphers=+3des-cbc

Подлинность хоста «172.22.56.2 (172.22.56.2)» не может быть установлена.
Отпечаток ключа DSA — SHA256:HwdMfb3k5KwrwQkFIRe6ZXilbObYhNzLbwb0zvk2n8U.
Вы уверены, что хотите продолжить подключение (да/нет/[отпечаток пальца])? ^ С

user@hostname:~$ ssh-keyscan -H 172.22.56.2
# 172.22.56.2:22 SSH-2.0-RomSShell_4.31
# 172.22.56.2:22 SSH-2.0-RomSShell_4.31
# 172.22.56.2:22 SSH-2.0-RomSShell_4.31
# 172.22.56.2:22 SSH-2.0-RomSShell_4.31
# 172.22.56.2:22 SSH-2.0-RomSShell_4.31

Добавление «-vv» относится только к приложению ssh, а не к ssh-keyscan, поэтому я не нашел в этом ничего полезного.

Технически, на первоначально поставленные вопросы были даны ответы, но это больше связано с отсутствием у меня полноты видения вопроса - кажется, на данный момент настоящий вопрос таков:

  • Почему ssh-keyscan не возвращает результатов, когда ssh на тот же хост выдает приглашение ключа SSH?

Должен ли я открыть новый вопрос или просто изменить исходное представление? Спасибо!

Ginnungagap avatar
флаг gu
Есть ли у целевого хоста ключ хоста RSA?
dave_thompson_085 avatar
флаг jp
@Ginnungagap: OpenSSH с версии 6.1 9 лет назад пробовал по крайней мере 2 алгоритма, и вывод здесь показывает, что он пробовал 5! OP: строки `#` просто сообщают, что это _пытается_ получить ключ; если это удастся да с `-H`, вы получите строку в форме `|1|base64|base64 algorithmname base64`, и, поскольку вы этого не сделали, это означает, что сервер не предлагает никакого ключа, который понимает ваш OpenSSH, поэтому есть нечего писать в ваш файл known_hosts. `ssh -vv` должен показывать в `debug2: алгоритмы ключа хоста:`, что предлагает сервер.
A L avatar
флаг gb
A L
@dave_thompson_085 - ты, Дэйв! Не будучи очень ssh saavy, дополнительный вопрос для вас, если вы не возражаете - когда я пытаюсь ssh [email protected] - я получаю сообщения об ошибках, что шифры/и т. д. не поддерживаются, однако, если я предоставлю устаревшие параметры с -o (KexAlgo/ciphers/hostkeyAlgo) - мне дается отпечаток пальца RSA с приглашением принять да/нет. Ty за объяснение # вывода - я предполагал что-то подобное!
dave_thompson_085 avatar
флаг jp
Какие устаревшие варианты? (Вверх по течению) OpenSSH по-прежнему предлагает алгоритм ssh-rsa при подключении по умолчанию (т. как ssh-rsa, так и более новый/лучший rsa-sha2-* (который использует один и тот же _key_ rsa) с версии 8.1 в 2019-10. Какой вы используете, и был ли он исправлен или перенастроен?
A L avatar
флаг gb
A L
@ dave_thompson_085 - ага - я на самом деле выделил проблему из-за того, что ssh-keyscan не имеет этих устаревших параметров по умолчанию ...знаете ли вы способ указать те же необязательные устаревшие параметры в моем недавнем обновлении для ssh-keyscan? Должен ли я перефразировать свои вопросы вокруг этого или задать новый вопрос?
Michael Hampton avatar
флаг cz
Как видите, удаленное устройство предлагает только _слабые_ устаревшие алгоритмы обмена ключами и шифры. Очень странная штука для [коммерческого предложения](https://www.allegrosoft.com/product/iot-edge-device/romsshell/) сегодня. Сегодня они не включены по умолчанию в современном ssh и, как уже упоминалось, в конечном итоге будут полностью удалены. Странно, что компания назвала это «безопасным», но я полагаю, что, вероятно, видел и хуже. Что это за устройство, и можете ли вы заменить его чем-то, что действительно имеет некоторую безопасность?
A L avatar
флаг gb
A L
@MichaelHampton - Согласен, в данном случае это коммутаторы / маршрутизаторы / точки доступа Cisco десятилетней (или более старой) давности - и во многих случаях они настолько плохи или еще хуже. С точки зрения безопасности, наши текущие системные шаблоны включают современное оборудование, которое ssh-keyscan не имеет проблем с запросом, этот вопрос был для старого парка, с которым я борюсь. Короче говоря, есть план поэтапного отказа от них, но есть тысячи, которые я хотел бы автоматизировать в промежуточный период, и это является основным препятствием для этого в настоящее время. Нет ли способа передать устаревшие параметры в ssh-keyscan?
Michael Hampton avatar
флаг cz
Вероятно, есть. Вы проверяли справочную страницу?
A L avatar
флаг gb
A L
да, я использую: https://man.openbsd.org/ssh-keyscan.1, а мой исходный источник для устаревших опций даже для подключения обычного SSH-приложения находится здесь: https://www.openssh. com/legacy.html - ничто в аргументах приложений не указывает на то, что они могут быть предоставлены ... но я хотел получить отзывы сообщества на случай, если я что-то упустил / неправильно прочитал!
dave_thompson_085 avatar
флаг jp
**АХ! DSA!** Да, ssh-keyscan не пытается использовать DSA по умолчанию, даже до того, как OpenSSH объявил его устаревшим (7.0 IIRC).`ssh-keyscan -t dsa` может помочь получить ключ (даже 8.6 устанавливает DHG1 для kx _in scan_, но мне кажется, что 7.4 up не установит 3des). Но для того, чтобы на самом деле _подключиться_ к `ssh` (или `scp` и т. д.), вам понадобятся все варианты, которые вы нашли.
A L avatar
флаг gb
A L
@dave_thompson_085 - Хорошо, круто - это приятно знать! Я буду работать, чтобы проверить это в своей лаборатории, а пока вы хотите опубликовать отдельный ответ, чтобы я мог отметить/принять? Это была очень надоедливая проблема, с которой, я уверен, столкнутся другие специалисты по сетевой автоматизации, и я хотел бы получить формальный ответ на нее. Если я завершу тестирование / подтвержу до того, как увижу что-либо опубликованное здесь, я напишу его сам, но предпочел бы отдать вам должное, где это необходимо! Спасибо за вашу помощь.
Рейтинг:1
флаг jp

(Из комментариев плюс обновление)

Проблема в том, что целевое устройство действительно хромает и судя по всему (по диагностике ssh) поддерживает только старые и в основном устаревшие параметры SSH, которые не нравятся последнему OpenSSH.

Во-первых, у него есть только ключ DSA (также пишется как DSS в SSH). ssh-keyscan по умолчанию никогда не запрашивал ключ DSA, хотя набор типов, которые он запрашивал, варьировался и в основном включал Другие добавлены новые типы; поэтому при запуске без опций показывает 5 попытки -- чтобы получить типы ключей, которых нет на устройстве.Эту часть можно исправить, указав -t дса.

Во-вторых, он поддерживает только группу DH 1 для KEX и 3des-cbc для шифрования. Хотя ssh больше не считает группу 1 безопасной и нуждается в -oKexАлгоритмы= вариант его использования, ssh-keyscan заставляет то, что выглядит все KEX группы. Однако это не изменяет ssh по умолчанию для шифров, поэтому ssh-keyscan в OpenSSH 7.4 все равно должно произойти сбой. Если вы понизите версию ниже 7.4, я верю ssh-keyscan -t dsa буду работать. Конечно, понижение версии плохо для безопасности, поэтому вы должны делать это только на пустой обезьяне, такой как виртуальная машина или контейнер, который затем отбрасывается.

В качестве альтернативы, как вы обнаружили, ssh может быть данным параметры, чтобы принять эти старые параметры, чтобы он мог получить ключ хоста и добавить его в известные_хосты. Если вы хотите просто избежать взаимодействия, т.е. автоматизировать, используйте -oStrictHostKeyChecking=нет (или же принять-новый в версии 7.6 и выше), чтобы сделать это без запроса. Если вы не хотите, чтобы новый ключ помещался непосредственно в файл, также используйте -oUserKnownHostsFile= поместить его в другое место -- хотя, как только вы это сделаете, на самом деле единственное, что можно сделать с новым файлом, это добавить его в известные_хосты как ssh было бы, так зачем заморачиваться?

A L avatar
флаг gb
A L
ты или это! Я добавлю для всех, кто приходит сюда и разочарован использованием ansible инвентаризации вышеизложенного - ANSIBLE НЕ ИСПОЛЬЗУЕТ OPENSSH системы!! Он использует libssh или paramiko для сетевых устройств. Таким образом, вышеизложенное полезно только для автоматизации сети, если вы создаете другие вещи для работы с данными.

Ответить или комментировать

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