我们最近将运行Fedora 2和Plesk 8.2.1的Web服务器移动到虚拟机上。 此后，qmail一直拒绝向某些服务器发送消息，在邮件日志中抱怨“TLS_connect_failed：_error：24064064：random_number_generator：SSLEAY_RAND_BYTES：PRNG_not_seeded”。 显然，这是一个OpenSSL问题，涉及从实际到虚拟硬件的切换。 有没有办法改变OpenSSL从哪里获取随机数据，或者至less告诉qmail退回到非安全协议SSL / TLS不起作用？
你有检查确保系统上存在/ dev / random和/ dev / urandom？ 我发现这个网站的指示，如果他们不重新创build他们。
除了确保相关设备存在（按照David Smith的回答），您需要确保池中实际存在一些熵。
cat /proc/sys/kernel/random/entropy_avail会告诉你它的当前级别。 如果没有足够的通过TLSstream（即encryption）发送邮件将阻塞（等待那里是足够的）或失败，除非你的邮件传输代理很乐意使用非阻塞的随机设备（作为其名字暗示不阻挡，但在理论上不太安全）。
熵池由内核随着时间的推移使用来自I / O操作引起的中断定时的数据来补充，但是如果机器（或VM）看不到太多的活动，池需要很长时间才能增长， I / O操作来收集时间。
在我们公司的一台小型机器上，我们只是作为一个SMTP中继的互联网网关，我们用exim解决这个问题。 为了解决这个问题，我简单地设置一个通过init运行的小脚本，通过运行pv --rate-limit 2m /home/4GigFile > /dev/null然后在一个循环中hibernate30秒， 您的虚拟机提供商不太可能喜欢这个解决scheme，因为它会在主机上施加不必要的额外I / O负载 – 您可能会放弃一个不那么激进的脚本来检查/proc/sys/kernel/random/entropy_avail如果发现的值小于1000，则只运行循环的任意I / O操作。
那里有一些脚本/工具可以让你从其他来源提取“随机”的值来提供熵池。 如果你很乐意给MTA一个不那么安全的熵源，你可以尝试使用rngd从“/ dev / urandom”中提供熵池，或者甚至只是把/dev/random链接到/dev/urandom但是有一些软件可能会足够彻底地检查它们，如果默认情况下configuration软件会对其熵源的质量产生偏执，那么这些软件就会失败。
编辑：
您只是间歇性地遇到这个问题，原因有两个：首先池可能在大部分时间被充分填充，其次qmail可能通过简单（未encryption）的stream与一些服务器通信作为后备（某些，可能很多，接收服务器将拒绝非encryption连接，所以在协商TLS连接失败时不能总是使用这种后退）。