由于/dev/urandom的不存在，Linux - SSH连接被拒绝

Question

今天，我们的一台生产机器(亚马逊EC2)坏了，我无法打开这个实例，因为我无法进入SSH，连接被拒绝，我不知道该做什么，过了一段时间后，我能够提出实例-(好的，简短和甜蜜)。

我不知怎么找出了导致/dev/urandom文件丢失的根本原因，因此，SSH无法启动。我必须在重新启动时创建这个文件，我通过在一个现有的启动(init)脚本中添加几行代码来创建它，并且可以让服务器启动并运行，这意味着我可以将SSH放到这个框中。

我需要以下方面的专家意见，请不要犹豫，给我更多的信息：

1. 我是否应该保留我在init-script文件中编写的代码行？
2. 丢失/dev/urandom文件的原因是什么？
3. 我该如何避免将来出现这种情况呢？

谢谢。

更新：

对于那些想知道我写了什么的人：

#!/bin/bash
cd /dev ; /sbin/MAKEDEV urandom ; /etc/init.d/ssh start

Answer 1

我建议把代码保留在适当的位置。我知道这听起来很愚蠢，但你的/dev/urandom完全消失了这一事实确实很奇怪，而且可能会再次发生。修改代码以发出日志消息，如果将来需要重新创建设备文件，则不能忽略这些消息。

您的/dev/urandom没有很好的理由被删除。所希望的绝对最好的方法是配置一个工具，如puppet或chef，将其配置为从tarball编写一个文件目录，并首先作为展开tarball的一部分完全清除该目录。(我认为这种使用是对工具的严重错误配置。)但是作为root运行的任何进程都具有删除文件的权限，因此它几乎可以是任何东西。

您可以将auditd配置为监视/dev/目录中的文件创建、删除和重命名。将规则放置到/etc/audit/audit.rules中以配置持久监视：

-w /dev/ -p wa

有关配置审计监视列表的详细信息，请参阅auditctl(8)；它是相当可配置的，您可能需要将配置调优到您的系统，以便“标准”事件不会干扰您的审计日志。

另一个选项是使用immutable程序在文件上设置chattr(1)属性。有可能的是，任何可能删除该文件的程序或工具都可能不会在删除文件之前删除immutable属性。

Answer 2

通常，在升级OS时会注意到类似的问题，并且由于某些原因，升级中断了。在AWS (EC2)中，不应该升级它们提供的内核。你最近有没有尝试升级你的操作系统？最好找到丢失/dev/urandom的实际原因并修复它。在此之前，将代码留在init脚本中。让我们知道是怎么回事。