Назад | Перейти на главную страницу

ssh-keyscan - все еще поддерживается с помощью. Подлинность хоста «[имя хоста] ([IP-адрес])» не может быть установлена

Я пишу сценарий для удаленной установки rsync, и мне нужно добавить удаленный сервер в локальный файл known_hosts, чтобы при первом запуске сценария не отображались следующие запросы:

Подлинность хоста «[имя хоста] ([IP-адрес])» не может быть установлена. Отпечаток ключа RSA - это [отпечаток ключа]. Вы уверены, что хотите продолжить подключение (да / нет)?

Согласно Могу ли я автоматически добавлять новый хост в known_hosts? Я пробовал (со свежим файлом known_hosts):

ssh-keyscan -H [hostname],[ip_address] >> ~/.ssh/known_hosts
ssh-keyscan -H [ip_address] >> ~/.ssh/known_hosts
ssh-keyscan -H [hostname] >> ~/.ssh/known_hosts

Но это не работает, мне всегда предлагают принять отпечаток пальца.

Когда я позволяю ssh добавить это за меня, хеш ключа в файле know_hosts сильно отличается.

Что еще мне нужно сделать для устранения этой проблемы?

Попробуй это:

ssh-keyscan -t rsa [ip_address]

Возьмите результат и вставьте его в .ssh / known_hosts. Теперь, если вы хотите хешировать known_hosts, сделайте следующее:

ssh-keygen -H

редактировать: Вот единственное решение команды. Он использует имя хоста, IP-адреса и хэши.

ssh-keyscan -Ht rsa [hostname],[IP address] >> known_hosts

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

Однако я искал обыденный способ обойти неизвестное ручное взаимодействие хоста при клонировании репозитория git, как показано ниже, и это должно помочь в объяснении того, что происходит, и как вы можете избежать этой части сценария некоторых вещей, связанных с SSH:

brad@computer:~$ git clone git@bitbucket.org:viperks/viperks-api.git
Cloning into 'viperks-api'...
The authenticity of host 'bitbucket.org (104.192.143.3)' can't be established.
RSA key fingerprint is 97:8c:1b:f2:6f:14:6b:5c:3b:ec:aa:46:46:74:7c:40.
Are you sure you want to continue connecting (yes/no)?

Обратите внимание на отпечаток ключа RSA ...

Итак, это SSH, это будет работать для git через SSH и просто для вещей, связанных с SSH в целом ...

brad@computer:~$ nmap bitbucket.org --script ssh-hostkey

Starting Nmap 7.01 ( https://nmap.org ) at 2016-10-05 10:21 EDT
Nmap scan report for bitbucket.org (104.192.143.3)
Host is up (0.032s latency).
Other addresses for bitbucket.org (not scanned): 104.192.143.2 104.192.143.1 2401:1d80:1010::150
Not shown: 997 filtered ports
PORT    STATE SERVICE
22/tcp  open  ssh
| ssh-hostkey:
|   1024 35:ee:d7:b8:ef:d7:79:e2:c6:43:9e:ab:40:6f:50:74 (DSA)
|_  2048 97:8c:1b:f2:6f:14:6b:5c:3b:ec:aa:46:46:74:7c:40 (RSA)
80/tcp  open  http
443/tcp open  https

Nmap done: 1 IP address (1 host up) scanned in 42.42 seconds

Сначала установите nmap на свой ежедневный драйвер. Nmap очень полезен для определенных вещей, таких как обнаружение открытых портов и это - проверка отпечатков SSH вручную. Но вернемся к тому, что мы делаем.

Хорошо. Либо я скомпрометирован в нескольких местах и ​​на машинах, которые я проверил, либо происходит более правдоподобное объяснение того, что все, что я хреново, дори.

Этот «отпечаток пальца» - это всего лишь строка, сокращенная с помощью одностороннего алгоритма для удобства человека, при этом существует риск того, что несколько строк будут преобразованы в один и тот же отпечаток пальца. Бывает, их называют коллизиями.

Тем не менее, вернемся к исходной строке, которую мы можем увидеть в контексте ниже.

brad@computer:~$ ssh-keyscan bitbucket.org
# bitbucket.org SSH-2.0-conker_1.0.257-ce87fba app-128
no hostkey alg
# bitbucket.org SSH-2.0-conker_1.0.257-ce87fba app-129
bitbucket.org ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAubiN81eDcafrgMeLzaFPsw2kNvEcqTKl/VqLat/MaB33pZy0y3rJZtnqwR2qOOvbwKZYKiEO1O6VqNEBxKvJJelCq0dTXWT5pbO2gDXC6h6QDXCaHo6pOHGPUy+YBaGQRGuSusMEASYiWunYN0vCAI8QaXnWMXNMdFP3jHAJH0eDsoiGnLPBlBp4TNm6rYI74nMzgz3B9IikW4WVK+dc8KZJZWYjAuORU3jc1c/NPskD2ASinf8v3xnfXeukU0sJ5N6m5E8VLjObPEO+mN2t/FZTMZLiFqPWc/ALSqnMnnhwrNi2rbfg/rd/IpL8Le3pSBne8+seeFVBoGqzHM9yXw==
# bitbucket.org SSH-2.0-conker_1.0.257-ce87fba app-123
no hostkey alg

Итак, заранее у нас есть способ запросить форму идентификации у исходного хоста.

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

Теперь, чтобы использовать эту строку таким образом, чтобы не спрашивать о подлинности хоста ...

В этом случае файл known_hosts не использует записи в виде открытого текста. Вы узнаете хешированные записи, когда увидите их, они выглядят как хеши со случайными символами вместо xyz.com или 123.45.67.89.

brad@computer:~$ ssh-keyscan -t rsa -H bitbucket.org
# bitbucket.org SSH-2.0-conker_1.0.257-ce87fba app-128
|1|yr6p7i8doyLhDtrrnWDk7m9QVXk=|LuKNg9gypeDhfRo/AvLTAlxnyQw= ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAubiN81eDcafrgMeLzaFPsw2kNvEcqTKl/VqLat/MaB33pZy0y3rJZtnqwR2qOOvbwKZYKiEO1O6VqNEBxKvJJelCq0dTXWT5pbO2gDXC6h6QDXCaHo6pOHGPUy+YBaGQRGuSusMEASYiWunYN0vCAI8QaXnWMXNMdFP3jHAJH0eDsoiGnLPBlBp4TNm6rYI74nMzgz3B9IikW4WVK+dc8KZJZWYjAuORU3jc1c/NPskD2ASinf8v3xnfXeukU0sJ5N6m5E8VLjObPEO+mN2t/FZTMZLiFqPWc/ALSqnMnnhwrNi2rbfg/rd/IpL8Le3pSBne8+seeFVBoGqzHM9yXw==

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

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

Спасибо, что оставались со мной, готово. Я добавляю RSA-ключ bitbucket, чтобы я мог взаимодействовать с моими репозиториями git в неинтерактивном режиме как часть рабочего процесса CI, но все, что вы делаете, что хотите.

#!/bin/bash
cp ~/.ssh/known_hosts ~/.ssh/known_hosts.old && echo "|1|yr6p7i8doyLhDtrrnWDk7m9QVXk=|LuKNg9gypeDhfRo/AvLTAlxnyQw= ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAubiN81eDcafrgMeLzaFPsw2kNvEcqTKl/VqLat/MaB33pZy0y3rJZtnqwR2qOOvbwKZYKiEO1O6VqNEBxKvJJelCq0dTXWT5pbO2gDXC6h6QDXCaHo6pOHGPUy+YBaGQRGuSusMEASYiWunYN0vCAI8QaXnWMXNMdFP3jHAJH0eDsoiGnLPBlBp4TNm6rYI74nMzgz3B9IikW4WVK+dc8KZJZWYjAuORU3jc1c/NPskD2ASinf8v3xnfXeukU0sJ5N6m5E8VLjObPEO+mN2t/FZTMZLiFqPWc/ALSqnMnnhwrNi2rbfg/rd/IpL8Le3pSBne8+seeFVBoGqzHM9yXw==" >> ~/.ssh/known_hosts

Итак, вот как ты остаешься девственницей на сегодня. Вы можете сделать то же самое с github, следуя аналогичным указаниям в удобное для вас время.

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

НЕПРАВИЛЬНО ssh -oStrictHostKeyChecking = без имени хоста [команда]

НЕПРАВИЛЬНО ssh-keyscan -t rsa -H имя хоста >> ~ / .ssh / known_hosts

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