Насколько хорошо защищены ваши SSH-сессии?

[chupasaurus]

В 99% случаев администраторы отвечают на подобный вопрос «yes».

Неверное обобщение, пока не подтверждено фактами, а следовательно статью можно удалять.

[k0ldbl00d]

В 99% случаев они нажимают Yes когда только что установили ОС (или запустили контейнер в облаке). В остальном, когда вдруг ни с того ни с сего появился запрос об изменившемся fingerprint — это как раз таки сигнал тревоги, и вот тут процент значительно меньше. По крайней мере, я надеюсь что это так.

[pwrlnd]

«В 99% случаев это не системные администраторы».

[printercu]

С начала статьи ждал, как будет отрабатываться предупреждение о том, что ключ поменялся.

В 99% случаев администраторы отвечают на подобный вопрос «yes»

>_< надеюсь, что хоть немного меньше эта цифра на самом деле)

[pyrk2142]

Около года назад встречал на Хабре утверждение, что очень много администраторов отправляют приватные ключи вместе с публичными, когда кто-то спрашивает ключ. Просто не думают о том, что они делают. А тут надо только согласиться.

[BOPOHA]

Автор, вероятно, судит по себе.
Ни один нормальный *nix-сисадмин просто так подобное сообщение не оставит.

[antgorka]

Я лишь призываю всех, и "нормальных" и "ненормальных" *nix-сисадминов использовать ключи, а не пароли, что повышает безопасность сетевой инфраструктуры. А, надеяться на то, что в Вашей организации все сисадмины "нормальные" — изначально неправильная политика информационной безопасности.

[8jwnk]

Автор, вероятно, судит по себе.
Ни один нормальный *nix-сисадмин просто так подобное сообщение не оставит.

Уже -дцатый человек в комментариях пишет, что согласен с автором.

ОК, пусть будет по вашему — ни один «нормальный».
Только вот, видимо, нормальных и есть 1%.

Какая разница каким именно словом обозначить человека? Нормальный или нет?
Суть то не меняется — львинная доля не соблюдает правил безопасности.

[Shurrrman]

Нет, ну я прекрасно понимаю, при каких условиях ключ может поменяться. И когда он меняется после очевидных моих действий — в чём проблема. Если «сам» поменялся — то признак задуматься

[andrzzc]

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

Есть еще неочевидные подводные камни человеческого фактора — можно совместить атаку на важный сервер (DoS) вместе с MitM-атакой на ssh (ну или просто захватить чужой ip-адрес)
Системный администратор заметит:
1) важный сервер внезапно вообще перестал работать
2) у важного сервера сменился ключ и существующий пароль больше не подходит
ИМХО, не очень опытный администратор с долей вероятности >50%:
1) Забудет о том что это в сети мог появиться левый ип-адрес
2) Попадет под прессинг начальства
3) Начнет вводить все возможные логины и пароли, в т.ч. от других серверов, до победного конца.
4) Разбор полетов и выявление подмены IP-адреса будет проводиться сильно позже, если вообще будет.
5) Коллекция логинов и паролей уже собрана, профит.

[iSergios]

Да, к сожалению описанная атака неосуществима без человеческого фактора.

Может все-таки к счастью?

[iborzenkov]

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 матернется и не даст подключиться.

[antgorka]

Да, но PuTTY предложит принять новый ключ. Да, и когда на Вас орет начальник и просит срочно почистить файловую систему на сервере, так как бизнес "встал", а тут какие-то "глюки начинаются" и не получается подключиться к серверу, многие отдадутся эмоциям и могут выполнить ssh-keygen -f "/home/user/.ssh/known_hosts" -R ...

[mva]

вот где-то приблизительно поэтому у меня и существует стереотип о том, что Linux-администратор, пользующийся Windows не может являться профессионалом в этой области

[Wedmer]

Спорное утверждение. Работать никсовым админом и жить в никсах — несколько разные, но пересекающиеся множества.

[mva]

стереотип

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

Но статистически этот мой штамп очень часто реально помогает морально подготовиться к тому, чего стоит ожидать от собеседника и меньше нервничать во время дискуссий.

[Wedmer]

Прошу прощения, слово выпало во время чтения.

[saboteur_kiev]

«В 99% случаев администраторы отвечают на подобный вопрос «yes».»

Не могу поверить, что я попадаю в уникальные 1% администраторов, которые видя подобное не выясняют по какой причине поменялся ключ хоста? Это действительно поведение большинства?

[saboteur_kiev]

Фух, судя по каментам, я не уникален, все в порядке.

[chmod]

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 в данной ситуации.

Тем не менее абсолютно согласен с выводом статьи о запрете авторизации по паролям.

[antgorka]

Все верно. PuTTY, насколько я помню, просто предложит принять новый ключ.

[saboteur_kiev]

Не совсем просто. Оно выведет варнинг, в котором большими буквами напишет, что уже сохраненный ключ не совпадает с ключом хоста, и это потенциально security breach.

А потом уже предложит Yes, No, Cancel
Причем в конце еще раз напомнит, что «Hitting Cancel is the ONLY guaranteed safe choise».

[mva]

к слову,
1) это справедливо практически для всех ОС. И все варианты "бсди", и макось, и прочие. С некоторых пор даже в этой вашей windows можно после пары пассов руками :)
2) putty есть и для линукса и для других ОС. Но более нужным от этого не становится, да :)

[Ctacfs]

В 99% случаев администраторы отвечают на подобный вопрос «yes».

Это где 99% админов жмут yes не задумываясь когда клиент говорит, что не может установить аутентификацию хоста? В такой ситуации даже я, будучи совсем начинающим админом, сначала задумался, потом понял, в чем дело, а потом ещё и загуглил, чтобы уж наверняка.

[antgorka]

Добавил UPD в текст, дабы прекратить спор на эту тему

[maxzhurkin]

А почему часть команд характерны для Debian (и про это ничего не сказано), а часть вообще противоречат всем рекомендациям по установке ПО?

[antgorka]

Вы о чем?

[maxzhurkin]

apt есть только в Debian и «дочках», а всякие ./install.sh будет использовать только тот, кто пользуется системой первый и последний раз, то есть, тот, кто ей пользоваться не должен.

[antgorka]

Вы, видимо, не понимаете, о чем речь в статье. Я устанавливаю фейковый SSH-сервер в свой собственный дистрибутив для пентеста и прекрасно понимаю, что будет делать install.sh и зачем именно я это делаю. В тексте несколько раз сказано, что я использую Kali Linux, а это Debian-based дистрибутив.

[maxzhurkin]

Нет, в тексте, конечно, неоднократно упоминается Kali Linux, но нигде явно не говорится, что в статье все команды приведены именно для этого дистрибутива.

[antgorka]

Обратите внимание на "Для arp-spoofing-а используется ettercap, а для сниффинга сетевых пакетов tshark.
Оба инструмента по умолчанию входят в дистрибутив Kali Linux." и на строку приглашения в code-тегах (root@kalix64:~)

[maxzhurkin]

Да, многократно говорится, что те или иные инструменты входят в состав Kali Linux, однако это нисколько не противоречит моим словам.

[maxzhurkin]

Плюс к тому: вы-то понимаете, что делает install.sh, а вот ваш читатель — не факт.
И тут я бы разделил его на три группы: одна не понимает, но делает, другая не понимает, но не делает, а третья разбирается самостоятельно и или делает, или нет.
К сожалению для нашего мира, первых очень много, к сожалению для вас, вторых тоже много, но не очень, к сожалению для всех, последних мало.

[vitaliy2]

Каждый день выскакивает эта фигня, всегда жму Yes.

^{на самом деле нет}