ServerKeyBits 1024 — это размер эфемерного DH-ключа для протокола первой версии. Эту версию вообще можно отключить. С другой стороны, ключи размером больше 1024 бит для протокола второй версии могут тормозить, поэтому есть смысл перейти для DH на эллиптику и задать максимальный размер эллиптической кривой, например KexAlgorithms ecdh-sha2-nistp521. Более новые версии ssh поддерживают кривые не от НИСТа, а от DJB (Бернштейна), по мере продвижения поддержки имеет смысл перейти на них.

Можно задать фиксированный список хэшей и шифров. Посмотрите в man, в каких опция они встречаются и задайте максимальные параметры: SHA-2-512 И AES-CTR-256.

Вообще, почти все эти параметры (точнее часть, которая запускается для эфемерного сеанса) есть смысл задавать на стороне клиента, а не сервера: вы будете согласовывать с сервером соединение по выбраному вами стойкому протоколу, а если уж кто-то крадёт ваш ключ и пароль для его расшифровки, вам будет всё равно — по стойкому протоколу он осуществляет сеансы взлома вашего сервера или нет. К тому же на стороне клиента безопаснее экспериментировать с параметрами конфигов без риска остаться без связи с сервером.

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

Настройте вход только по ключам без возможности войти напрямую по паролю. Это уже как раз потребует смены конфигов и на сервере. При этом сами ключи используются только для аутентификации при входе и подтверждения параметров DH, они не используются непосредственно для шифрования, поэтому их максимальный размер не критичен, что позволяет не завязываться в самих ключах на эллиптику. Можно задать ключ с максимально разумным размеров (RSA-4096).

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

На реальном сервере, даже по сравнению с виртуальным, в отличие от непредсказуемого пользовательского десктопа, с энтропией тоже не очень хорошо. Если сервер не виртуальный, а на реальном железе, то есть смысл поэкспериментировать с HAVEGE^[link2]. Это относится не только к SSH, а к любым криптооперациям вообще.

Рекомендации ходить под пользователем ведут корнями в старинные инструкции 90-ых годов, где основной вектор угроз — подбор пароля по сети.
Раз вы всё равно будете потом повышать привелегии до рута, принципиального разделения между root'ом и обычным пользователем не будет. В частности, компрометация этого пользователя даст злоумышленнику доступ и к root-аккаунту.

Битность RSA ключа влияет на аутентификацию, а не шифрование.

Защита от расшифровки заключается в повышении битности DH-ключа, что разумно осуществимо только путём перехода на сеансовую эллиптику с максимальным размеров кривой.

Ну и выбором симметричных алгоритмов с максимальным размером ключа. Это всё прописывается на стороне клиента.

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

Раз вы всё равно будете потом повышать привелегии до рута, принципиального разделения между root'ом и обычным пользователем не будет.

При сканировании SSH-серверов самый распространённый логин это root. Когда логин неизвестен, его нужно подобрать. Для нестандартного имени это аналогично подбору пароля, при том что количество попыток в единицу времени ограничивается настройками сервера.

Другая причина – невозможность установки трояна в автоматическом режиме. Нужно ждать когда будет вход с правами root.

>Разве выбор алгоритма при аутентификации (RSA или DSA) влияет на битность сеансового ключа?
Аутентификация не влияет. Влияет тип эллиптической кривой в KexAlgorithms.

Костыльно очень. Вдруг что-то сбойнёт и в файл что-то не запишется? Или запишется что-то не то? Дважды запишется по-ошибке одно и тоже?

Не знаю, есть ли команда или способ для генерации ключа сервера на стороне именно аутентифицированого клиента с последующим забросом сгенерированного ключа на этот сервер. Если есть, то надо воспользоваться таким способом.

>На стороне клиента собирать энтропию и кроном регулярно добавлять в файл.
Хорошую энтропию посылаем через канал с плохой энтропией? И храним, пусть и временно, но в простом файле?

При установлении аутентификации только по ключам это всё получается не имеет значения.

По поводу random-устройств^[link11]:

Writing to /dev/random or /dev/urandom will update the entropy pool with the data written, but this will not result in a higher entropy count. This means that it will impact the contents read from both files, but it will not make reads from /dev/random faster.

echo "Initializing random number generator..."
           random_seed=/var/run/random-seed
           # Carry a random seed from start-up to start-up
           # Load and then save the whole entropy pool
           if [ -f $random_seed ]; then
               cat $random_seed >/dev/urandom
           else
               touch $random_seed
           fi
           chmod 600 $random_seed
           poolfile=/proc/sys/kernel/random/poolsize
           [ -r $poolfile ] && bytes=`cat $poolfile` || bytes=512
           dd if=/dev/urandom of=$random_seed count=1 bs=$bytes

Т.о., после старта виртуалки в неё можно вкачать энтропии по SSH, а затем переконнектится по SSH заново, надеясь, что из предыдущего сеанса извлечь вкачиваемые в /dev/{u}random данные будет сложнее. Но вообще — это шаманство. Нужен Entropy Broker^[link12].

А вот ещё чьё-то простенькое скриптоподелие, похожее на то, что предлагалось в этой теме изначально — entropyservice^[link13]:

Allow low entropy machines (eg Virtual Machines) to collect data from another host with high entropy (eg a real computer) via SSH, then stir it in to the kernel's random pool using rngd

Хотя, хотелось бы иметь разработки на формально обоснованных протоколах для этой задачи.

Т.е., в /dev/{u}random можно напрямую записывать данные безо всяких вспомогательных демонов, они там сами похэшируются и переинициализируют пул энтропии.

после старта виртуалки в неё можно вкачать энтропии по SSH, а затем переконнектится по SSH заново, надеясь, что из предыдущего сеанса извлечь вкачиваемые в /dev/{u}random данные будет сложнее.

Нужен Entropy Broker

хотелось бы иметь разработки на формально обоснованных протоколах для этой задачи

Это понятно, что скриптами и даже эвристически обоснованными программами можно по шифрпанковски всё нагородить. Я подразумеваю, что нужен спецпротокол доказуемо безопасной трансляции энтропии с расчётом Resilience Leakage Entropy, Bounded Retrieval Model, Leakage Oracle и пр. За авторством кого-нибудь, наподобие Евгения Додиса^[link14].

Теоретически сложный вопрос. В том же rngd выставляется лимит в процентах на подкачку данных из определённого источника, чтобы он полностью не доминировал в создании пула энтропии.

Разумно.

Брутфорсить пароль — это ещё ладно, но неужели вы всерьёз рассматриваете ещё и брутфорс ключа?

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

Про rngd: вы предлагаете напрямую пополнять пул /dev/random, чтобы увеличить его скорость? Т.е. проигнорировать все страховки и проверки на уровне ОС?

We want the trust in Tor to come from the fact that we are open source and transparent, and that we do Real Science. Everything in Tor is built upon decades of public research. We don't want trust in Tor to come from us doing secret defenses and looking into a crystal ball and guessing what the most devastating imaginary attacks might be, and developing broken pretend defenses against imaginary attacks that probably don't work in reality.

There are plenty of other tools that will sell you magical secret sauce to defend against everything from the future and beyond. We don't do that, because there's another name for that magical secret sauce: Snake Oil.

Любое крипто строится на том, что есть публичная часть алгоритма/протокола и секретная.

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

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

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

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