ssh-keyscan для known_hosts не дает результатов
Когда я выполняю:
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, но веря в вывод, который я получил be .. не то, что я искал, я также пробовал варианты -t, например:
ssh-keyscan -H -t rsa 172.22.56.2 >> ~/.ssh/known_hosts
Все результаты одинаковы. Права доступа к файлу:
-rw-r--r-- 1 username username 886
«Имя пользователя» — это то, что запускает приведенные выше команды.Это оставляет меня со следующими вопросами:
- Что означает мой вывод ssh-keyscan? Я бы ожидал здесь что-то вроде строки |1|weofijgojw = sshkey.
- Почему в ~/.ssh/known_hosts ничего не записывается? Нет никаких признаков проблем, о которых мне сообщили / команда принимает
Заранее спасибо за любую информацию!
ОБНОВЛЕНИЕ 1:
user@hostname:~$ ssh user@172.22.56.2
Unable to negotiate with 172.22.56.2 port 22: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1
user@hostname:~$ ssh user@172.22.56.2 -oKexAlgorithms=+diffie-hellman-group1-sha1
Unable to negotiate with 172.22.56.2 port 22: no matching host key type found. Their offer: ssh-dss
user@hostname:~$ ssh user@172.22.56.2 -oKexAlgorithms=+diffie-hellman-group1-sha1 -oHostKeyAlgorithms=+ssh-dss
Unable to negotiate with 172.22.56.2 port 22: no matching cipher found. Their offer: 3des-cbc
user@hostname:~$ ssh user@172.22.56.2 -oKexAlgorithms=+diffie-hellman-group1-sha1 -oHostKeyAlgorithms=+ssh-dss -oCiphers=+3des-cbc
The authenticity of host '172.22.56.2 (172.22.56.2)' can't be established.
DSA key fingerprint is SHA256:HwdMfb3k5KwrwQkFIRe6ZXilbObYhNzLbwb0zvk2n8U.
Are you sure you want to continue connecting (yes/no/[fingerprint])? ^C
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?
Должен ли я открыть новый вопрос или просто изменить исходную заявку? Спасибо!
(Из комментариев плюс обновление)
Проблема в том, что целевое устройство действительно хромает и, по-видимому, (, как диагностировано ssh), поддерживает только старые и в основном устаревшие параметры SSH, которые не нравятся последнему OpenSSH.
Во-первых, он имеет только DSA (, также пишется как DSS в ключе SSH). ssh-keyscanпо умолчанию никогда не запрашивал ключ DSA, хотя набор типов, которые он запрашивал, варьировался и в основном включал другие новые типы, которые были добавлены; вот почему его запуск без опций показывает 5 попыток--получить типы ключей, которых нет у устройства. Эту часть можно исправить, указав -t dsa.
Во-вторых, он поддерживает только группу DH 1 для KEX и 3des-cbc для шифрования. Хотя sshбольше не считает группу 1 безопасной и для ее использования требуется опция -oKexAlgorithms=, ssh-keyscanзаставляет то, что выглядит как , все группы KEX. Тем не менее, это не изменяет sshпо умолчанию для шифров, поэтому ssh-keyscanв OpenSSH 7.4 по-прежнему должен давать сбой. Если вы понизите версию ниже 7.4, я думаю, что ssh-keyscan -t dsaбудет работать. Конечно, переход на более раннюю версию вреден для безопасности, поэтому вы должны делать это только на пустой обезьяне, такой как виртуальная машина или контейнер, который затем отбрасывается.
В качестве альтернативы, как вы обнаружили,sshможно дать -oопции для принятия этих старых опций, чтобы он мог получить ключ хоста и добавить его в known_hosts. Если вы хотите просто избежать взаимодействия, т. е. автоматизировать, используйте-oStrictHostKeyChecking=no(или accept-newв 7.6 up), чтобы сделать это без запроса. Если вы не хотите, чтобы новый ключ помещался непосредственно в файл, также используйте -oUserKnownHostsFile=, чтобы поместить его в другое место --, хотя, как только вы это сделаете, на самом деле единственное, что можно сделать с новым файлом, это добавить это к known_hostsточно так же, как ssh, так зачем беспокоиться?