Усиление SSH-соединения
Многие пользуются SSH-соединением для защиты передаваемых данных и паролей, но думается, немногие уделяют внимание его тонкой настройке.
Извиняюсь за возможно простой вопрос, который для меня все же неочевиден, к тому же гугль не слишком помог.
Прошу и предлагаю собрать здесь все рецепты по усиления криптостойкости SSH-соединения, доступные "из коробки".
Конфигурация традиционна: есть локальный SSH-клиент и удаленный SSH-сервер на базе OpenSSH.
Соединение между ними устанавливается, как говорится, с пол-оборота.
А как сделать его более криптостойким, выжимая из их конфигов по-максимуму и одновременно исключая нестойкие варианты?
Например, в http://books.google.com.ua/boo.....yBits%201024&f=false описан параметр
ServerKeyBits 1024
но тут же есть приписка, что это только для 1-й версии. А если не 1-й, тогда как?
И каковы пределы это битности?
И т.д. – в конфигах есть множество параметров и в то же время по ним нет рекомендаций.
В-общем, предлагаю объединить здесь все методы, повышающие криптостойкость SSH-соединения.
Необходимость подбора логина не имеет отношения к криптографии, это дополнительный барьер, когда криптография при аутентификации не работает. Количество попыток входа в систему ограничено настройками сервера, можно их ещё больше затянуть. Например, следующие опции допускают только одну неудачную попытку за полчаса.
Таким темпами подбор по словарю занимает слишком много времени. При регулярном просмотре журнала такая атака будет пресечена в самом начале.
Если диапазон адресов расширится, то ждать когда попадётся нужный? по-моему это непрактично и ненадёжно.
Для защиты дополнительного сервера возникает та же проблема, что для основного. Или надеяться что его не заметят, но это, как вы подметили, игра в прятки.
В такой ситуации можно просто покрыть SSH-трафик другим протоколом с аутентификацией, например SSL с клиентским сертификатом. Минус в дополнительном оверхеде, связанном с шифрованием. Хотя в ранних версиях stunnel вроде можно было отключить шифрование соединения, в новых не проверял. Но более последовательным является наверное применение SOCKS-сервера. Это чистый слой аутентификации и ПО предназначенное именно для данной цели, с развитыми средствами контроля доступа.
Всё это предназначено как раз для поддержания доверенного канала, изначально созданного надёжным способом. Хотя в принципе вы наверное правы, надёжность такой конструкции низка.
комментариев: 9796 документов: 488 редакций: 5664
Я имел в виду криптографию в обобщённом смысле. Замените слово крипто на слово криптопротокол, например. Смысл должен быть понятен: если секретность пароля/ключа недостаточно, надо сам протокол фиксить, а не секретить его остальные открытые части. Конечно, это максима, которую строго не обосновать, но мысль довольно распространённая, многие считают её правильной.
Подскажите, куда это прописывать? В /etc/ssh_config? Система Debian.