Comments 34
В 99% случаев администраторы отвечают на подобный вопрос «yes».Неверное обобщение, пока не подтверждено фактами, а следовательно статью можно удалять.
С начала статьи ждал, как будет отрабатываться предупреждение о том, что ключ поменялся.
В 99% случаев администраторы отвечают на подобный вопрос «yes»
>_< надеюсь, что хоть немного меньше эта цифра на самом деле)
Автор, вероятно, судит по себе.
Ни один нормальный *nix-сисадмин просто так подобное сообщение не оставит.
Я лишь призываю всех, и "нормальных" и "ненормальных" *nix-сисадминов использовать ключи, а не пароли, что повышает безопасность сетевой инфраструктуры. А, надеяться на то, что в Вашей организации все сисадмины "нормальные" — изначально неправильная политика информационной безопасности.
Автор, вероятно, судит по себе.
Ни один нормальный *nix-сисадмин просто так подобное сообщение не оставит.
Уже -дцатый человек в комментариях пишет, что согласен с автором.
ОК, пусть будет по вашему — ни один «нормальный».
Только вот, видимо, нормальных и есть 1%.
Какая разница каким именно словом обозначить человека? Нормальный или нет?
Суть то не меняется — львинная доля не соблюдает правил безопасности.
Но в случае когда администратор первый раз заходит на новый сервер, или когда у администратора новый ПК, эта цифра вполне приближается к 99%.
В статье описывается некое подобие сниффера, который находит все действующие SSH-сессии в сети. Т.е. теоретически это дело можно автоматизировать, собирать данные и проксировать только новые компьютеры, появившиеся в сети 10 минут назад.
Есть еще неочевидные подводные камни человеческого фактора — можно совместить атаку на важный сервер (DoS) вместе с MitM-атакой на ssh (ну или просто захватить чужой ip-адрес)
Системный администратор заметит:
1) важный сервер внезапно вообще перестал работать
2) у важного сервера сменился ключ и существующий пароль больше не подходит
ИМХО, не очень опытный администратор с долей вероятности >50%:
1) Забудет о том что это в сети мог появиться левый ип-адрес
2) Попадет под прессинг начальства
3) Начнет вводить все возможные логины и пароли, в т.ч. от других серверов, до победного конца.
4) Разбор полетов и выявление подмены IP-адреса будет проводиться сильно позже, если вообще будет.
5) Коллекция логинов и паролей уже собрана, профит.
The authenticity of host '192.168.1.4 (192.168.1.4)' can't be established.
ED25519 key fingerprint is SHA256:kn+iT7WwgO6Wlh0xN4KQXB8P/JaHLcRx04gYTvNdjCM.
Are you sure you want to continue connecting (yes/no)?
Это только в том случае если не разу не подключался к этой машине, если уже было подключение, то ssh матернется и не даст подключиться.
Да, но PuTTY предложит принять новый ключ. Да, и когда на Вас орет начальник и просит срочно почистить файловую систему на сервере, так как бизнес "встал", а тут какие-то "глюки начинаются" и не получается подключиться к серверу, многие отдадутся эмоциям и могут выполнить ssh-keygen -f "/home/user/.ssh/known_hosts" -R ...
вот где-то приблизительно поэтому у меня и существует стереотип о том, что Linux-администратор, пользующийся Windows не может являться профессионалом в этой области
стереотип
Я не просто так написал это слово.
Т.е. я отдаю себе отчёт о том, что это не всегда истинно. Но этот штамп помогает моментально составлять мнение (которое, к слову, всё же часто оказывается истинным) о профессиональных качествах собеседника. Естественно, я не держусь за него и при более детальном общении сужу о человеке по его реальным навыкам.
Но статистически этот мой штамп очень часто реально помогает морально подготовиться к тому, чего стоит ожидать от собеседника и меньше нервничать во время дискуссий.
Не могу поверить, что я попадаю в уникальные 1% администраторов, которые видя подобное не выясняют по какой причине поменялся ключ хоста? Это действительно поведение большинства?
The authenticity of host '192.168.1.4 (192.168.1.4)' can't be established.
Данное сообщение выводится только если вы никогда не подключались к данному хосту, т.е. в файле known_hosts нет о нем записи.
Если же у известного хоста публичный ключ сменился, ssh-клиент откажется подключаться:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
3e:ee:ee:ee:ee:ee:ee:ee:ee:ee:e6:72:df:c4:ee:ee.
Please contact your system administrator.
Add correct host key in /home/user/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/user/.ssh/known_hosts:1
remove with: ssh-keygen -f "/home/user/.ssh/known_hosts" -R eee.eee
ECDSA host key for eee.eee has changed and you have requested strict checking.
Host key verification failed.
Т.е. нужно предпринять ручные действия (или удалить строку в файле known_hosts, или командой ssh-keygen -f) для подключения.
Правда это касается ssh-клиента на линуксе, не знаю как себя поведет putty в данной ситуации.
Тем не менее абсолютно согласен с выводом статьи о запрете авторизации по паролям.
Все верно. PuTTY, насколько я помню, просто предложит принять новый ключ.
к слову,
1) это справедливо практически для всех ОС. И все варианты "бсди", и макось, и прочие. С некоторых пор даже в этой вашей windows можно после пары пассов руками :)
2) putty есть и для линукса и для других ОС. Но более нужным от этого не становится, да :)
В 99% случаев администраторы отвечают на подобный вопрос «yes».
Это где 99% админов жмут yes не задумываясь когда клиент говорит, что не может установить аутентификацию хоста? В такой ситуации даже я, будучи совсем начинающим админом, сначала задумался, потом понял, в чем дело, а потом ещё и загуглил, чтобы уж наверняка.
Вы о чем?
Вы, видимо, не понимаете, о чем речь в статье. Я устанавливаю фейковый SSH-сервер в свой собственный дистрибутив для пентеста и прекрасно понимаю, что будет делать install.sh и зачем именно я это делаю. В тексте несколько раз сказано, что я использую Kali Linux, а это Debian-based дистрибутив.
Обратите внимание на "Для arp-spoofing-а используется ettercap, а для сниффинга сетевых пакетов tshark.
Оба инструмента по умолчанию входят в дистрибутив Kali Linux." и на строку приглашения в code-тегах (root@kalix64:~)
И тут я бы разделил его на три группы: одна не понимает, но делает, другая не понимает, но не делает, а третья разбирается самостоятельно и или делает, или нет.
К сожалению для нашего мира, первых очень много, к сожалению для вас, вторых тоже много, но не очень, к сожалению для всех, последних мало.
на самом деле нет
Насколько хорошо защищены ваши SSH-сессии?