[pavel.odintsov]

Првоериться очень просто:

ssh whoami.filippo.io

 

У себя выправил два косяка :(

[ipaddr.ru]

Спасибо, что напомнил. Видел на днях, да забыл совсем.

[vlad11]

Актуальная тема!

[KaraVan]

А что это за хост такой? Почему именно на нем проверять?

 

[Andrei]

Просто добавить "UseRoaming no" в /etc/ssh/ssh_config ?

[Ivan_83]

А что такого актуального?

Оно же только для клиентов, обычный апдейт решает проблему.

[pavel.odintsov]

Ну что за параноя, это узел известного исследователя безопасности: https://blog.filippo.io/ssh-whoami-filippo-io/

[MMM]

а я еще думал, чего это за обновления на ssh прилетели...

топикстартеру спасибо.

[vlad11]

Просто добавить "UseRoaming no" в /etc/ssh/ssh_config ?

 

Это вы про последнюю уязвимость?

А этот узел проверяет и на старые.

Например, отображает публичный ключ. Это предпоследняя уязвимость ssh :)

[Ivan_83]

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

 

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

 

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

[tokra]

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

[pavel.odintsov]

Проблема в том, что вы не понимаете масштаба проблемы. Я, например, могу использовать знание о вашем публичном ключе, чтобы понять что он некриптостойки либо был сгенерирован на дебияне где "мейнтенеры" решили оптимизировать криптографию.

 

Чем это чревато для вас? Что я получу доступ на все машины, к которым у вас доступы в течение пары дней.

[tokra]

Проблема в том, что вы не понимаете масштаба проблемы. Я, например, могу использовать знание о вашем публичном ключе, чтобы понять что он некриптостойки либо был сгенерирован на дебияне где "мейнтенеры" решили оптимизировать криптографию.

 

Чем это чревато для вас? Что я получу доступ на все машины, к которым у вас доступы в течение пары дней.

 

Продемонстрируйте на практике.

 

Следующие, те кто, последние пару лет как, не генерят связку ssh-keygen -t rsa -b 2048 ( а сейчас и 4096) с заданием пароля - сами себе злобные буратино.

 

Ну и никто не отменял привязку доступа только с разрешенных ip, вот такая параноя.

Изменено 18 января, 2016 пользователем tokra

[pavel.odintsov]

Что демонстрировать? :) Инцидент, когда ключи в дебияне генерировались не простые, а разлагаемые за 3 минуты на множители? Это давно достояние общественности и исследований и без меня не счесть.

 

Вот, пожалуйста: https://github.com/blog/63-ssh-keys-generated-on-debian-ubuntu-compromised

[tokra]

Если пошла такая пьянка, куда серьезнее проблема в том, что opeтssh юзает libcrypto при сборке, который часть openssl, а в последнем дыр понаходили за последний год - мама не горюй. Так что, если будут эксплуатировать уязвимость, то явно не в игры с открытым ключем и решением обратного преобразования односторонних функций. Хотя да, никто не отменял что генерировтаь надо связку с как можно более длинным ключом ( выше я уже писал), ну и плюс паранойя с доступ только с разрешенных ip. Ну и вообще по красоте - это запертить доступ в рута с публичных ip.

 

Что демонстрировать? :) Инцидент, когда ключи в дебияне генерировались не простые, а разлагаемые за 3 минуты на множители? Это давно достояние общественности и исследований и без меня не счесть.

 

Вот, пожалуйста: https://github.com/blog/63-ssh-keys-generated-on-debian-ubuntu-compromised

 

Мда, если с 2008 года ничего не изменилось там и никто не перегененрировал свои ключи, то это печально.

Изменено 18 января, 2016 пользователем tokra

[Ivan_83]

Проблема в том, что вы не понимаете масштаба проблемы. Я, например, могу использовать знание о вашем публичном ключе, чтобы понять что он некриптостойки либо был сгенерирован на дебияне где "мейнтенеры" решили оптимизировать криптографию. Чем это чревато для вас? Что я получу доступ на все машины, к которым у вас доступы в течение пары дней.

Бред же.

Как ты имея ПК узнаешь куда я с ним хожу?

А по поводу того что он не криптостойкий - тут засекречивание ключа не сильно поможет.

 

 

Если пошла такая пьянка, куда серьезнее проблема в том, что opeтssh юзает libcrypto при сборке, который часть openssl, а в последнем дыр понаходили за последний год - мама не горюй.

Акстись!

1. У меня лично он собирается с libressl.

2. Заявление человека не понимающего в крипте :)

ссш использует криптоалгоритмы и не более, а все проблемы были с TLS. Более того, последние версии опенссш могут быть собраны вообще без *ssl либы, тогда там будет только чача20 и ед25519.

[pavel.odintsov]

Почему бред? Для чего придуман ssh - для защиты от атак man in the middle. Если я встану в разрез вашей сети и стану тем самым man in the middle - я сначала получу кривые серты косвенным образом, получу приватную часть ключа факторизацией и далее буду смотреть весь трафик плейн текстом :)

[Ivan_83]

Потому что мечтать не вредно.

Уже тех сертификатов что ты собрался факторизировать нет или практически нет.

[pavel.odintsov]

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

[pavel.odintsov]

Вот, опять же, хорошая статья на тему сабжа: https://blog.benjojo.co.uk/post/auditing-github-users-keys

[tokra]

 

 

 

Если пошла такая пьянка, куда серьезнее проблема в том, что opeтssh юзает libcrypto при сборке, который часть openssl, а в последнем дыр понаходили за последний год - мама не горюй.

Акстись!

1. У меня лично он собирается с libressl.

2. Заявление человека не понимающего в крипте :)

ссш использует криптоалгоритмы и не более, а все проблемы были с TLS. Более того, последние версии опенссш могут быть собраны вообще без *ssl либы, тогда там будет только чача20 и ед25519.

 

У Вас, лично, может собираться с чем угодно, но никто не отменял тот факт, что есть дистрибутивы в которых, по дефолту, он собирается с библиотеками от openssl. В том же gentoo, который у меня под рукой, в дефолте он юзает dev-libs/openssl:0[static-libs(+)

 

Я не говорю, что я специалист в безопасности, но, я сделал акцент, что openssh собирается с библиотками от openssl, в котором в последнее время находили много уязвимостей, это как бы куда важнее, чем проблема с доступностью публичных ключей

Изменено 19 января, 2016 пользователем tokra