Он должен «просто работать». Несмотря на то, что виртуальная машина не имеет специального физического оборудования, она все еще имеет доступ к нескольким очень хорошим источникам случайности. Например, он может использовать TSC ЦП для измерения времени чтения с виртуальных дисков, что в конечном итоге приведет к сокращению времени физических дисков до миллиардной доли секунды. Эти тайминги зависят от турбулентного сдвига воздушного потока в жестком диске, который непредсказуем.
Аналогичная логика применима к сетевому трафику. Несмотря на то, что интерфейс виртуализирован, до тех пор, пока пакет исходит из физической сети (и не является локальным для бокса, скажем, исходящим из другой виртуальной машины), синхронизация пакета зависит от фазового сдвига между кварцевым генератором на сетевой карте. и кварцевый генератор, который управляет TSC. Это зависит от изменений температуры микроскопических зон в двух кристаллах кварца. Это тоже непредсказуемо.
Если по какой-то причине не работает, самое простое решение - написать программу для добычи энтропии и добавить ее в системный пул. Сетевой интерфейс - ваш самый надежный источник. Например, вы можете написать код для:
1) Запросить TSC.
2) Отправить DNS-запрос серверу, о котором известно, что он не находится на той же физической машине.
3) Запросить TSC, когда запрос завершен.
4) Повторите это несколько раз, накапливая все значения TSC.
5) Выполните безопасное хеширование для накопленных функций TSC.
6) Передайте выходные данные защищенной хеш-функции в энтропию системы. пул.
7) Следите за уровнем пула энтропии и ждите, пока он не станет низким. Когда это произойдет, вернитесь к шагу 1.
В Linux есть простые вызовы IOCTL для добавления энтропии в пул, проверки уровня пула и так далее. У вас, вероятно, есть rngd
, который может брать энтропию из канала и передавать ее в системный пул. Вы можете заполнить канал из любого источника, будь то запросы TSC или 'wget' из вашего собственного источника энтропии.
Yeah you can seed it, from:
http://manpages.ubuntu.com/manpages/jaunty/man4/random.4.html
You can just put that into /dev/urandom and it should seed the entropy pool. I was able to confirm this by:
root@mx01-ewr:/proc/sys/kernel/random# cat entropy_avail
128
root@mx01-ewr:/proc/sys/kernel/random# cat /dev/xvda >/dev/urandom &
[1] 16187 # just using this as a source of data, you could do ssh hostIP 'cat /dev/random' >... etc
root@mx01-ewr:/proc/sys/kernel/random# cat entropy_avail
1221
root@mx01-ewr:/proc/sys/kernel/random# cat entropy_avail
1398
Bonus if you make the ssh command go through a router so it generates entropy *:)
У меня тоже были проблемы с зависанием krb5_newrealm. Это хорошо сработало для меня, основываясь на приведенном выше ответе:
cat /dev/sda > /dev/urandom
Вы можете убить его, как только закончите с необходимостью в случайных данных. / dev / sda, вероятно, содержит больше данных, чем вам нужно.
Примечание: я не уверен, насколько случайные данные, сгенерированные таким образом, на самом деле являются случайными.
I use haveged on all my headless servers that perform cryptographic operations (e.g. TLS handshakes, kerberos, etc). It should be in most Ubuntu versions' package repository: http://packages.ubuntu.com/search?keywords=haveged&searchon=names&suite=all§ion=all
haveged uses the HAVAGE algorithm to extract entropy from the internal state of modern processors. Here's an indepth explanation: http://www.irisa.fr/caps/projects/hipsor/
You can check the randomness of generated entropy with the ent package. On my systems the generated entropy from haveged passed all randomness tests by ent
Это сработало для меня
Запуск krb5_newrealm внутри виртуальной машины может занять много времени (после с сообщением «Загрузка случайных данных»). Вы можете использовать следующий прием, чтобы немного ускорить процесс.
$ sudo aptitude install rng-tools -y
$ sudo rngd -r /dev/urandom -o /dev/random # don't do this in production!
размещено на http://fossies.org/linux/john/doc/Kerberos-Auditing-HOWTO.md
Ответ X86 - убедитесь, что ваша ВМ не поймает RdRand или RdSeed в ловушку. Вы доверяете своей ВМ многим вещам, это одна из них.
Достаточно свежий RNGd на процессоре Snady Bridge, будет (или может быть сказано) использовать RdRand или RdSeed, и неиспользованные RdRand или RdSeed получат энтропию в ВМ. /dev/random затем работает с реальным (не виртуальным) источником энтропии.
Это не случайно. Это прямо здесь, в документации архитектуры Intel.
Для аппаратного источника энтропии на основе устройств (т.е. использующего драйвер ядра для совместного использования) ВМ нужна для корректной виртуализации физического источника. Понятия не имею, делают ли они это и если да, то для каких устройств.
Если в вашем RNGd нет опции drng ниже, обновите его. Если ваше аппаратное обеспечение не имеет быстрого аппаратного RNG, вы обречены, и вы должны подумать об использовании другого аппаратного обеспечения в целях безопасности.
# rngd --help
Usage: rngd [OPTION...]
Check and feed random data from hardware device to kernel entropy pool.
-b, --background Become a daemon (default)
**-d, --no-drng=1|0 Do not use drng as a source of random number input**
(default: 0)
-f, --foreground Do not fork and become a daemon
-n, --no-tpm=1|0 Do not use tpm as a source of random number input
(default: 0)
-o, --random-device=file Kernel device used for random number output
(default: /dev/random)
-p, --pid-file=file File used for recording daemon PID, and multiple
exclusion (default: /var/run/rngd.pid)
-q, --quiet Suppress error messages
-r, --rng-device=file Kernel device used for random number input
(default: /dev/hwrng)
-s, --random-step=nnn Number of bytes written to random-device at a time
(default: 64)
-v, --verbose Report available entropy sources
-W, --fill-watermark=n Do not stop feeding entropy to random-device until
at least n bits of entropy are available in the
pool (default: 2048), 0 <= n <= 4096
-?, --help Give this help list
--usage Give a short usage message
-V, --version Print program version
Mandatory or optional arguments to long options are also mandatory or optional
for any corresponding short options.
Report bugs to Jeff Garzik <jgarzik@pobox.com>.