SSH, переставший работать из сценария, работающего над командной строкой (Мерзавец)

Некоторая информация..

Из соображений безопасности, начиная с версии 2.0.46 непечатаемых и других специальных символов в %r, %i и %o оставляют с помощью \xhh последовательности, где гд обозначает шестнадцатеричное представление необработанного байта.

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

Обновление: Я говорил с апачским разработчиком, он уверил меня, что шестнадцатеричное число-> является 1 путем encrpytion дизайном.. Так регистрируя это к диску, вероятно, просто трата пространства :D

Надеюсь, это поможет..

0
задан 16 January 2013 в 00:56
2 ответа

Внутри "голого" server вы должны отредактировать файл ~ / .ssh / known_hosts пользователя, запустившего ловушку.

Пример строки ~ / .ssh / known_hosts:

192.168.1.9 ssh-rsa AAAB3NzaC1yc2EAAAADAQABAAABAQDM5bg362+EqiRioaVO5f7L7a4NK94yHI6HXQCdge7WvmN9AFVhruXs31JUooxTD0tMe3nE0zDIt9fBcoIXNYjd2auCrRdT/2kvNg12aqhJpoxKeArekjQ10xmyjkDGQr6DUTzW7TOX55aucDbftO1chQ6+wG7mpvkE6N0J9HsQvJrjb3LO9JlEDCYFp2sSx3OxvCl33pEMk7zVhHftqP8hmZnQF8Y2/dO/nK/UawJVOVzyvImzvOhBFqKYgVIKajtjH/yodf9R1tOALqP9QQVBA9zJOLhc4q6Rcj3QVb+o6mv3Zl5QudZP6ATcFeKZPzEEUrqHbeQiZ2Ce72AUtD+7

Вы должны удалить строку, которая идентифицирует сервер, к которому вы пытаетесь подключиться, а затем, ПЕРЕД повторным запуском вашего скрипта, выполните "sshuser @ destination "с вашим пользователем, чтобы ключ хоста целевого сервера для вашего файла known_hosts. Примерно так:

localhost% ssh user @ destination Подлинность хоста «назначение (10.0.0.1)» не может быть установлена. Отпечаток ключа RSA - 51: a4: 73: ef: 6d: b6: 40: c1: a2: 1f: ba: 33: a0: 64: c0: f8. Вы уверены, что хотите продолжить подключение (да / нет)? да
Предупреждение: «Пункт назначения» (RSA) постоянно добавлен в список известных хостов.

1
ответ дан 4 December 2019 в 21:30

Ответ Пабло Монтепагано правильный, но он очень конкретен и не обязательно затрагивает причину или какое-то периферийное понимание.

Найдите это в другом ответе здесь: https://serverfault.com/questions/132970/can-i-automatically-add-a-new-host-to-known-hosts/807363#807363

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

----------------- Ответы только на услышанные ссылки были осуждены, самомодерирование -------------

Итак, я искал простой способ обойти неизвестное ручное взаимодействие хоста при клонировании репозитория git, как показано ниже:

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 fingerprint ...

Итак, это штука 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 hostname >> ~ / .ssh / known_hosts

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

0
ответ дан 4 December 2019 в 21:30

Теги

Похожие вопросы