/dev/random ЧРЕЗВЫЧАЙНО медленно в Ubuntu для Windows 10 (WSL)
Нет, это невозможно. Клиент sshявно закрывает каждый открытый файловый дескриптор больше 2:
/*
* Discard other fds that are hanging around. These can cause problem
* with backgrounded ssh processes started by ControlPersist.
*/
closefrom(STDERR_FILENO + 1);
Это почти первое, что происходит при запуске клиента (см. main()в исходном коде OpenSSH 8.0 , доступном здесь).
И /dev/random, и /dev/urandomв Linux являются криптографически безопасными генераторами псевдослучайных чисел. В старых версиях ядра Linux /dev/randomблокировался после инициализации до тех пор, пока не накапливалась достаточная дополнительная энтропия, а /dev/urandom— нет. Поскольку WSL2 — это виртуальная машина с реальным ядром Linux, она имеет ограниченный набор источников энтропии, из которых она может получать энтропию, и большую часть энтропии приходится полагаться на хост-систему. Однако, если при загрузке он получил достаточно энтропии, использование CSPRNG безопасно.
Похоже, что в вашей среде CSPRNG заполняется при загрузке из Windows, но повторно не заполняется с высокой скоростью. Это нормально, но это приведет к тому, что /dev/randomбудет блокироваться чаще, чем вам хотелось бы. В конечном счете, это проблема с настройкой WSL2.
WSL1, вероятно, не имеет этой проблемы, потому что в таком случае /dev/random, вероятно, не блокирует, а просто использует системный CSPRNG, например /dev/urandom. В более поздних версиях Linux /dev/randomблокируется только в том случае, если при загрузке не было накоплено достаточно энтропии для однократного заполнения CSPRNG; в противном случае он полностью эквивалентен /dev/urandom. Это решение было принято, потому что между двумя интерфейсами нет разумной разницы в безопасности при условии, что пул был правильно инициализирован.
Поскольку в этих случаях нет измеримой разницы, если /dev/randomблокирует и работает слишком медленно для вас, правильно будет использовать /dev/urandom, так как они являются выходом того же CSPRNG (, который на основе ChaCha20 ). Верхнее поведение Linux, скорее всего, будет использоваться по умолчанию в будущей версии WSL2, поскольку Microsoft в конечном итоге включит более новую версию Linux.
Я сам не проверял это в WSL2 Ubuntu, но некоторое время назад столкнулся с похожей проблемой на виртуальной машине CentOS 6. Установка и запуск службы havegedисправили мою проблему с медленным /dev/random. Может стоит попробовать.
Linux pools randomness for distribution by the /dev/random and /dev/urandom device interfaces. The standard mechanisms of filling the /dev/random pool may not be sufficient to meet demand on systems with high needs or limited user interaction. In those circumstances, haveged may be run as a privileged daemon to fill the /dev/random pool whenever the supply of random bits in /dev/random falls below the low water mark of the device.
https://manpages.ubuntu.com/manpages/focal/man8/haveged.8.html
В противном случае, как сказал @bk2204, /dev/urandom может быть вашей лучшей альтернативой.