id: Гость   вход   регистрация
текущее время 12:35 29/03/2024
Автор темы: Гость, тема открыта 26/04/2014 18:04 Печать
Категории: криптография, инфобезопасность, протоколы, операционные системы
https://www.pgpru.com/Форум/UnixLike/УсилениеSSH-соединения
создать
просмотр
ссылки

Усиление SSH-соединения


Многие пользуются SSH-соединением для защиты передаваемых данных и паролей, но думается, немногие уделяют внимание его тонкой настройке.
Извиняюсь за возможно простой вопрос, который для меня все же неочевиден, к тому же гугль не слишком помог.
Прошу и предлагаю собрать здесь все рецепты по усиления криптостойкости SSH-соединения, доступные "из коробки".


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


Например, в http://books.google.com.ua/boo.....yBits%201024&f=false описан параметр
ServerKeyBits 1024
но тут же есть приписка, что это только для 1-й версии. А если не 1-й, тогда как?
И каковы пределы это битности?
И т.д. – в конфигах есть множество параметров и в то же время по ним нет рекомендаций.


В-общем, предлагаю объединить здесь все методы, повышающие криптостойкость SSH-соединения.


 
На страницу: 1, 2, 3 След.
Комментарии
— Гость (30/05/2014 12:50)   <#>
Любое крипто строится на том, что есть публичная часть алгоритма/протокола и секретная.

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



Таким темпами подбор по словарю занимает слишком много времени. При регулярном просмотре журнала такая атака будет пресечена в самом начале.

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

Если диапазон адресов расширится, то ждать когда попадётся нужный? по-моему это непрактично и ненадёжно.

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

Для защиты дополнительного сервера возникает та же проблема, что для основного. Или надеяться что его не заметят, но это, как вы подметили, игра в прятки.

В такой ситуации можно просто покрыть SSH-трафик другим протоколом с аутентификацией, например SSL с клиентским сертификатом. Минус в дополнительном оверхеде, связанном с шифрованием. Хотя в ранних версиях stunnel вроде можно было отключить шифрование соединения, в новых не проверял. Но более последовательным является наверное применение SOCKS-сервера. Это чистый слой аутентификации и ПО предназначенное именно для данной цели, с развитыми средствами контроля доступа.

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

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

Всё это предназначено как раз для поддержания доверенного канала, изначально созданного надёжным способом. Хотя в принципе вы наверное правы, надёжность такой конструкции низка.
— unknown (30/05/2014 12:55)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Хуже, если из-за какого-то сбоя в /dev/random попадут одни и те же потоки случайных данных дважды. Rngd это своими статтестами не отловит.
— Гость (30/05/2014 14:27)   <#>

Я имел в виду криптографию в обобщённом смысле. Замените слово крипто на слово криптопротокол, например. Смысл должен быть понятен: если секретность пароля/ключа недостаточно, надо сам протокол фиксить, а не секретить его остальные открытые части. Конечно, это максима, которую строго не обосновать, но мысль довольно распространённая, многие считают её правильной.
— Гость (30/05/2014 19:58)   <#>
Тут обсуждается не идеальное ПО, а конкретная реализация – OpenSSH, и меры для повышения её уровня защищённости. По моему мнению (которое попытался обосновать), логин отличный от root защищённость повышает, хотя возможно и не по канону. Такой способ относится скорей к административным мерам, а не криптографии. С другой стороны, даже в теоретическом плане существование единой точки отказа тоже имеет свои риски. Всегда лучше наличие дополнительных барьеров, особенно когда они не вносят заметных неудобств.
— popoom_pee_doo (13/09/2014 00:27)   <#>
Спасибо за советы!

Подскажите, куда это прописывать? В /etc/ssh_config? Система Debian.
— Гость (13/09/2014 14:34)   <#>
/etc/ssh/sshd_config
На страницу: 1, 2, 3 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3