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

По поводу random-устройств:

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.

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

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 и пр. За авторством кого-нибудь, наподобие Евгения Додиса.

Теоретически сложный вопрос. В том же 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.