保护您的 SSH 服务器
5.00/5 (1投票)
任何系统管理员都知道，在设置他们的 Web 环境时，保护他们的云服务器是首要任务。 有很多技术，所以 Rackspace 云工程师介绍了他的顶级技术以供参考。
我在我最喜欢的 IRC 频道中看到的最常见的问题之一是：“我如何保护我服务器上的 sshd？” 没有单一的正确答案，但大多数系统管理员会结合多种技术，以便在尽可能少地给最终用户带来不便的情况下提供尽可能多的安全性。 有关云的更多信息，请访问 www.rackspace.com/cloud。
以下是我最喜欢的技术，按从最有效到最无效的顺序列出
SSH 密钥对
通过禁用基于密码的身份验证并需要 SSH 密钥对，您可以降低通过暴力攻击进行入侵的几率。 这也可以帮助您防止弱帐户密码，因为需要有效的私钥才能访问服务器。 但是，如果您允许用户使用 sudo，弱帐户密码仍然是一个大问题。
如果您不熟悉使用 SSH 密钥，有 很多 很棒的 指南 可以引导您完成这个过程。
防火墙
限制可以访问您的服务器的源 IP 地址（通过端口 22）既简单又有效。 但是，如果您经常去度假或您的家庭 IP 地址经常更改，这可能不是一种方便的限制访问方式。 通过您的防火墙获取具有可信访问权限的服务器将使此方法更易于使用，但您也需要 考虑该服务器的安全性。
iptables 规则看起来像这样
iptables -A INPUT -j ACCEPT -p tcp --dport 22 -s 10.0.0.20 iptables -A INPUT -j ACCEPT -p tcp --dport 22 -s 10.0.0.25 iptables -A INPUT -j DROP -p tcp --dport 22
使用非标准端口
我不喜欢 通过模糊性实现安全性，它对 SSH 来说效果不佳。 如果有人只是扫描子网以查找 SSH 守护程序，您可能不会被第一次看到。 但是，如果有人专门针对您，更改 SSH 端口根本无济于事。 他们会很快找到您的 SSH 标题并开始攻击。
如果您喜欢这种方法，只需调整您的 sshd_config 文件中的 Port 配置参数即可。
限制用户和组
如果您只有某些需要 SSH 访问您服务器的用户和组，设置用户或组限制可以帮助提高安全性。 考虑一台需要 SSH 访问开发人员和经理的服务器。 将此添加到您的 sshd_config 将仅允许这些用户和组访问您的 SSH 守护程序
AllowGroups developers AllowUsers jsmith pjohnson asamuels
请记住，未包含在 sshd_config 中的任何用户或组都将无法访问您的 SSH 服务器。
TCP 包装器
虽然 TCP 包装器 是经过实践检验的，但我认为它们有点过时。 我发现许多新的系统管理员在诊断服务器问题时可能不会想到 TCP 包装器，这可能会导致稍后需要进行调整时出现延迟。
如果您准备使用 TCP 包装器来限制 SSH 连接，请查看 Red Hat 的广泛文档。
fail2ban 和 denyhosts
对于那些希望在阻止暴力攻击方面采取更积极姿态的系统管理员，总有 fail2ban 或 denyhosts。 fail2ban 和 denyhosts 都会监视您的身份验证日志以查找重复的失败，但 denyhosts 只能与您的 SSH 守护程序一起使用。 您可以将 fail2ban 与其他应用程序（如 Web 服务器和 FTP 服务器）一起使用。
使用这些应用程序的唯一缺点是，如果有效用户意外地尝试多次身份验证失败，他们可能会被锁定一段时间。 如果您正处于服务器紧急情况中，这可能是一个大问题。
在 Google 上快速搜索将为您提供有关 fail2ban 配置 以及 denyhosts 配置 的说明。
端口敲门
尽管 端口敲门 是另一种经过实践检验的方法，可以防止未经授权的访问，但使用它可能会很烦人，除非您有愿意跳过额外障碍的用户。 端口敲门涉及在任意端口上“敲门”，然后允许 SSH 守护程序向发送原始敲门的用户公开。
Linux Journal 有一篇很棒的文章，解释了端口敲门的工作原理，并且还提供了一些示例配置。
结论
保护您的 SSH 守护程序的最佳方法是在您的服务器上应用多种方法。 衡量安全性和访问便利性并非易事，并且对于每个环境都会有所不同。 无论您选择哪种方法，请确保您的团队的其他成员对这些更改感到满意，并且能够有效地适应它们。