Stoat自托管服务器安全加固实战：防火墙与SSH密钥配置指南

1. 项目概述：为什么Stoat自托管需要安全加固

如果你正在运行一个Stoat自托管实例，无论是用于团队内部的文档协作、知识库管理，还是作为个人项目的中心化工具，那么“安全”这个词，应该时刻悬在你的心头。Stoat作为一个功能强大的自托管平台，一旦部署在公网或内网中，它就不再仅仅是一个应用，而是一个承载着数据、访问权限和业务流程的关键节点。我见过太多因为初期配置疏忽，导致服务器被扫描、被入侵，甚至数据被加密勒索的案例。安全加固不是可选项，而是自托管服务的生存底线。

本次要聊的核心，就是围绕Stoat自托管环境的两道最基础、也最关键的防线：防火墙与SSH密钥登录。防火墙是你的城堡外墙，它决定了谁可以敲门、敲哪扇门；而SSH密钥登录则是你进入城堡的唯一、且无法复制的钥匙，彻底告别了容易被暴力破解的“密码锁”。网络上关于“检查更新时出错: 无法连接到 internet。如果使用防火墙,请将 microsoftedgeupdate.exe加入允许列表中”这类问题，本质上就是防火墙规则配置不当的典型表现。我们将从实战出发，一步步构建一个既安全又不影响正常业务访问的环境。

2. 安全加固的整体思路与核心原则

在动手修改任何配置之前，我们必须先建立一个清晰的安全模型。安全不是一堆命令的堆砌，而是一个有层次、有重点的防御体系。对于Stoat自托管服务，我们的防御思路可以概括为“最小权限、纵深防御、持续监控”。

最小权限原则是基石。这意味着，任何服务、任何用户、任何网络连接，都只被授予完成其功能所必需的最低权限。例如，Stoat的Web服务可能只需要开放80（HTTP）和443（HTTPS）端口，那么防火墙就应该严格封锁其他所有不必要的端口。SSH服务，我们则完全禁用密码登录，只允许密钥认证，并且将登录用户限制在必要的管理账户。

纵深防御是指不依赖单一的安全措施。即使防火墙被意外配置错误（比如错误地放行了SSH的密码登录），我们还有SSH密钥认证这道屏障。即使某道屏障被突破，系统其他部分（如文件权限、服务运行账户）也能提供额外的保护。我们的配置将体现这一点。

持续监控则关乎运维习惯。加固不是一劳永逸的，你需要定期查看认证日志（/var/log/auth.log或/var/log/secure）、防火墙日志，关注是否有异常的登录尝试或端口扫描。很多热词如“山石防火墙”、“深信服防火墙”提到的双机热备、透明模式等高级功能，在大型企业网络中很重要，但对于我们个人或中小团队的自托管场景，首先把基础的单机防护做扎实，其性价比最高。

基于这些原则，我们的加固路径非常明确：首先，配置系统防火墙，精确控制网络流量；其次，彻底改造SSH服务，用密钥替代密码，并收紧访问策略。这两步完成，你的Stoat服务器就具备了抵御绝大多数自动化攻击脚本的能力。

3. 防火墙配置：构建精准的网络访问控制

防火墙是你的第一道，也是最重要的网络边界防线。这里我们以最普遍使用的iptables的后继者ufw（Uncomplicated Firewall）为例，因为它对新手更友好，且足以应对大多数场景。当然，如果你熟悉firewalld（CentOS/RHEL系列）或直接使用iptables，原理是相通的。

3.1 初始状态检查与策略重置

在开始之前，务必先确认当前防火墙状态，并建立一个干净的起点。

# 查看ufw当前状态和规则 sudo ufw status verbose # 如果ufw处于激活状态，但规则混乱，可以先禁用并重置（谨慎操作！这会清空所有规则） sudo ufw disable sudo ufw reset

注意：ufw reset命令会删除所有已定义的规则，并将防火墙策略恢复为默认（拒绝所有入站，允许所有出站）。请确保你在服务器本地控制台操作，或者在确信有其他访问方式（如云平台控制台）的情况下进行，避免将自己锁在服务器外面。

3.2 放行必需的服务端口

Stoat作为Web服务，必须开放HTTP（80）和HTTPS（443）端口。此外，SSH端口（默认为22）也必须开放，否则你将无法远程管理服务器。但开放SSH端口的同时，我们必须配合后续的SSH加固。

# 允许SSH连接（默认端口22）。这是我们的管理通道，必须先放行。 sudo ufw allow ssh # 或者明确指定端口 # sudo ufw allow 22/tcp # 允许HTTP和HTTPS流量，这是Stoat服务本身对外提供的。 sudo ufw allow 80/tcp sudo ufw allow 443/tcp

这里有一个关键细节：ufw allow ssh命令实际上读取的是/etc/services文件中ssh对应的端口号（通常是22）。显式指定端口和协议（/tcp）是更清晰、不易出错的做法，尤其是在你自定义了SSH端口的情况下。

3.3 实施默认的“拒绝所有入站”策略

这是防火墙安全配置的核心。默认拒绝所有传入连接，然后只明确允许我们需要的，这完美体现了“最小权限”原则。

# 设置默认策略：拒绝所有传入，允许所有传出。 sudo ufw default deny incoming sudo ufw default allow outgoing

设置这个策略后，任何未被上述allow规则明确许可的入站连接都会被直接丢弃。这能有效防止服务器上其他未知服务（或因误安装而开启的服务）暴露在网络上。

3.4 启用防火墙并验证规则

配置好基本规则后，就可以激活防火墙了。激活前，请再次确认SSH端口已正确放行。

# 启用防火墙 sudo ufw enable # 再次查看状态，确认规则已生效 sudo ufw status numbered

status numbered参数会为每条规则编号，这在后续需要删除或调整某条特定规则时非常方便。输出应该类似于：

Status: active To Action From -- ------ ---- [ 1] 22/tcp ALLOW IN Anywhere [ 2] 80/tcp ALLOW IN Anywhere [ 3] 443/tcp ALLOW IN Anywhere [ 4] 22/tcp (v6) ALLOW IN Anywhere (v6) [ 5] 80/tcp (v6) ALLOW IN Anywhere (v6) [ 6] 443/tcp (v6) ALLOW IN Anywhere (v6)

3.5 高级规则与故障排查思路

基础的端口放行只是开始。在实际运营中，你可能需要更精细的控制。

场景一：限制SSH访问源IP如果你的办公网络有固定IP，强烈建议将SSH访问限制在该IP段，这能极大减少暴露面。

# 假设你的办公IP是 203.0.113.100 sudo ufw delete allow ssh # 先删除之前允许所有IP的SSH规则 sudo ufw allow from 203.0.113.100 to any port 22 proto tcp

场景二：应对“无法连接到Internet”类问题正如热词中提到的“检查更新时出错”，很多系统服务或应用（如Windows Update、某些Linux包管理器）需要访问外部网络。ufw默认allow outgoing已经放行了所有出站连接，所以通常不是防火墙阻止。问题往往出在入站响应的规则上。

对于一些使用复杂协议或需要动态端口的服务，简单的端口放行可能不够。这时需要检查该服务的文档，看它是否需要开放特定的入站端口。更常见的情况是，服务器本身作为客户端去访问外部服务（如拉取Docker镜像、访问API），这属于出站流量，默认是允许的。如果出站被阻，可能是你错误地设置了default deny outgoing。排查命令：

# 查看是否有拒绝出站的规则 sudo ufw status | grep DENY # 或者使用更详细的查看方式 sudo ufw show added

防火墙规则调试：如果你配置后某个服务不正常，可以暂时、有选择地添加日志规则来观察。

# 记录被拒绝的SSH连接尝试（日志在 /var/log/ufw.log） sudo ufw logging medium # 或者针对特定端口添加日志 sudo ufw insert 1 deny in proto tcp from any to any port 22 log

记住，调试完成后要清理临时的日志规则。

4. SSH密钥登录：告别密码，启用强认证

防火墙保护了网络层，而SSH加固则保护了访问控制层。密码登录容易受到暴力破解和密码泄露的威胁，而基于非对称加密的密钥对认证，在安全性上是质的飞跃。

4.1 生成SSH密钥对

密钥对由公钥和私钥组成。私钥保存在你的本地电脑上，必须严格保密；公钥则可以上传到服务器。整个认证过程基于数学难题，无法从公钥推导出私钥。

在本地客户端机器（你的电脑）上操作：

# 使用Ed25519算法，它比传统的RSA更安全、更快、密钥更短。 ssh-keygen -t ed25519 -C “your_email@example.com” -f ~/.ssh/stoat_server_key # 如果你使用的旧系统不支持Ed25519，可以使用RSA（至少4096位） # ssh-keygen -t rsa -b 4096 -C “your_email@example.com” -f ~/.ssh/stoat_server_key

执行命令后，它会提示你输入一个密钥的密码短语。这是一个额外的安全层，即使私钥文件被盗，没有这个短语也无法使用。建议设置一个强密码短语。

完成后，你会在~/.ssh/目录下得到两个文件：

  • stoat_server_key：私钥文件。权限必须是600 (-rw-------)。
  • stoat_server_key.pub：公钥文件。内容是一长串字符。

4.2 将公钥部署到服务器

现在需要将公钥内容添加到服务器上对应用户的~/.ssh/authorized_keys文件中。

方法一：使用ssh-copy-id（最简单）

# 确保你的本地私钥路径和名称与生成时一致 ssh-copy-id -i ~/.ssh/stoat_server_key.pub username@your_server_ip

这个命令会自动处理文件创建和权限设置。

方法二：手动部署（更可控）

  1. 在服务器上，以目标用户登录，确保~/.ssh目录存在且权限正确。
    mkdir -p ~/.ssh chmod 700 ~/.ssh
  2. 将本地公钥文件内容追加到authorized_keys。
    # 在你的本地机器上，复制公钥内容 cat ~/.ssh/stoat_server_key.pub # 然后登录服务器，将复制的内容粘贴到 ~/.ssh/authorized_keys 文件末尾 echo “粘贴你的公钥内容” >> ~/.ssh/authorized_keys
  3. 设置authorized_keys文件的权限。
    chmod 600 ~/.ssh/authorized_keys

实操心得：权限设置至关重要。~/.ssh目录权限必须是700(drwx------)，authorized_keys文件权限必须是600(-rw-------)。权限过松会导致SSH出于安全考虑拒绝使用密钥。

4.3 测试密钥登录

在修改SSH服务器配置之前，先测试密钥登录是否正常工作。打开一个新的终端窗口，尝试连接：

ssh -i ~/.ssh/stoat_server_key username@your_server_ip

如果系统直接提示你输入私钥的密码短语（而不是服务器的用户密码），并且登录成功，说明密钥部署成功。这一步测试至关重要，它能确保你在禁用密码登录后，还有一条可靠的通道进入服务器。

5. 服务器端SSH服务深度加固配置

密钥部署测试成功后，我们就可以大刀阔斧地修改SSH服务端配置，收紧安全策略了。配置文件通常位于/etc/ssh/sshd_config。

5.1 关键配置参数详解

在修改前，务必备份原文件：sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak。

然后使用sudo vim /etc/ssh/sshd_config或你喜欢的编辑器进行修改。找到并修改以下参数：

# 1. 禁止root用户直接登录。永远使用普通用户登录，再用sudo提权。 PermitRootLogin no # 2. 禁用密码认证，强制使用密钥认证。这是最关键的一步。 PasswordAuthentication no ChallengeResponseAuthentication no # 通常也关闭 # 3. 启用密钥认证 PubkeyAuthentication yes # 4. 指定允许登录的用户（可选但推荐）。将`username`替换为你的实际用户名。 AllowUsers username # 或者使用用户组 # AllowGroups sshusers # 5. 修改默认SSH端口（可选，但能减少自动化扫描）。将`2222`替换为你自定义的高位端口（如 23456）。 Port 2222 # 注意：修改端口后，防火墙规则和ssh客户端连接命令都需要相应调整。 # 6. 限制认证尝试次数和连接时间，防止暴力破解。 MaxAuthTries 3 ClientAliveInterval 300 ClientAliveCountMax 2 # 7. 禁用不安全的协议和加密算法。 Protocol 2 Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com

5.2 配置修改后的联动调整与测试

如果你修改了SSH端口（第5步）：

  1. 更新防火墙规则：必须在新端口上放行SSH。
    sudo ufw allow 2222/tcp # 并可以考虑删除旧的22端口规则（确保新端口测试成功后再删） # sudo ufw delete allow 22/tcp
  2. 更新客户端连接命令：以后连接需要使用-p参数。
    ssh -i ~/.ssh/stoat_server_key -p 2222 username@your_server_ip

每次修改sshd_config后，必须执行以下步骤：

  1. 检查配置文件语法是否正确：
    sudo sshd -t
    如果没有任何输出，表示语法正确。如果有错误，会提示错误行和原因，必须修正后才能继续。
  2. 重新加载SSH服务，使配置生效：
    sudo systemctl reload sshd # 或 sudo service ssh reload
    重要：使用reload而不是restart。reload会平滑重载配置，不会断开现有连接，更安全。

5.3 创建测试连接并最终验证

在退出当前SSH会话之前，务必打开一个新的本地终端窗口，用新的配置（尤其是新端口和密钥）测试登录。这是防止将自己锁在服务器外的最后一道保险。

# 在新的终端窗口测试连接 ssh -i ~/.ssh/stoat_server_key -p 2222 username@your_server_ip

成功登录后，你可以在原来的服务器会话里，最后验证一下配置：

# 查看SSH服务状态和监听端口 sudo systemctl status sshd sudo ss -tlnp | grep sshd # 输出应显示sshd正在监听你设置的端口（如2222）

确认一切正常后，你就可以安全地退出原来的SSH会话了。从此，你的服务器SSH入口将只接受指定用户的密钥认证，安全性得到极大提升。

6. 常见问题、排查技巧与日常维护实录

即使按照教程一步步操作，也可能会遇到问题。下面是我在多次部署中积累的常见问题排查清单和技巧。

6.1 SSH连接失败问题排查流程

当ssh命令失败时，不要慌张，按顺序检查以下环节：

  1. 网络连通性：ping your_server_ip是否通？如果不通，检查服务器状态、防火墙（云服务商的安全组/网络ACL）和本地网络。
  2. 防火墙规则：服务器本地防火墙是否放行了SSH端口？使用sudo ufw status确认。特别注意：如果你使用了云服务器（如AWS、阿里云、腾讯云），除了实例自身的防火墙，还需要在云平台的控制台配置安全组，入站规则允许你的IP访问SSH端口。这是新手最常踩的坑。
  3. SSH服务状态：服务是否在运行？sudo systemctl status sshd。
  4. 客户端密钥与路径：-i参数指定的私钥路径是否正确？私钥文件权限是否为600？尝试使用ssh -v参数输出详细日志，查看认证过程在哪一步失败。
  5. 服务器端公钥与权限：登录服务器（如果还有其他方式），检查对应用户的~/.ssh/authorized_keys文件内容是否正确、权限是否为600，其父目录~/.ssh权限是否为700。
  6. SSH配置：确认sshd_config中PubkeyAuthentication yes和PasswordAuthentication no设置正确，且没有因为语法错误导致整个配置文件失效。使用sudo sshd -t检查。
  7. 用户限制：检查AllowUsers或DenyUsers配置，是否包含了你的用户名。

6.2 密钥相关典型问题

  • 问题：连接时依然提示输入密码。
    • 排查：说明服务器未成功使用密钥认证。检查ssh -v日志，看是否尝试了公钥认证。重点检查服务器上authorized_keys文件的权限和内容格式（确保没有多余空格或换行）。
  • 问题：提示“Permission denied (publickey)”。
    • 排查：这是密钥认证失败的明确提示。按上述流程5、6仔细检查。一个常见原因是sshd_config中设置了AuthorizedKeysFile .ssh/authorized_keys，但路径不对，或者使用了%h等变量，而SELinux或目录权限导致无法读取。
  • 问题：每次连接都需要输入私钥密码短语，很麻烦。
    • 解决：可以使用ssh-agent来管理私钥。在本地会话中启动eval $(ssh-agent)，然后ssh-add ~/.ssh/stoat_server_key添加私钥并输入一次密码短语，之后在当前会话中连接就不再需要了。

6.3 防火墙与网络问题

  • 问题：修改SSH端口后，防火墙已放行，但依然无法连接。
    • 排查：首先确认sshd确实在监听新端口（sudo ss -tlnp | grep :2222）。其次，重启SSH服务后，ufw规则可能不会自动应用到新的监听套接字。这是一个容易被忽略的点。解决方法是在修改SSH端口并重启服务后，也重启一下ufw：sudo systemctl restart ufw。或者，更优雅的方式是使用ufw的app规则，但自定义端口时直接指定端口更简单。
  • 问题：服务器上的其他服务（如Stoat的Web界面）无法访问外部API或资源。
    • 排查：回忆我们的默认策略是allow outgoing，所以出站通常没问题。检查是否有为这个服务设置了特定的、限制性的出站规则？更可能是服务本身的代理配置或DNS问题。可以使用curl -v https://external-api.com在服务器上测试出站连接。

6.4 日常维护与监控建议

安全加固不是一次性任务。建议将以下检查纳入日常运维：

  1. 定期查看认证日志：sudo tail -f /var/log/auth.log | grep -i “failed\|invalid”。观察是否有大量的失败登录尝试，这可能是暴力破解的迹象。如果发现来自某个IP的持续攻击，可以用ufw直接封禁：sudo ufw deny from 攻击者IP。
  2. 更新系统与软件：定期运行sudo apt update && sudo apt upgrade（Debian/Ubuntu）或sudo yum update（RHEL/CentOS），及时修补安全漏洞。
  3. 备份sshd_config和ufw规则：配置稳定后，可以将它们备份到安全的地方。
    # 备份ssh配置 sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.backup.$(date +%Y%m%d) # 备份ufw规则（规则保存在 /etc/ufw/ 目录下，但更简单的方法是导出） sudo ufw status numbered > ~/ufw_rules.backup.$(date +%Y%m%d).txt
  4. 考虑使用Fail2ban：这是一个更高级的工具，它可以动态分析日志，自动将多次尝试失败的IP地址加入防火墙黑名单一段时间。对于暴露在公网的服务，Fail2ban是很好的补充。

完成以上所有步骤后，你的Stoat自托管服务器就拥有了一个坚实的安全基础。防火墙像一位严格的守门人，只允许必要的流量进入；而SSH密钥认证则像一把独一无二的物理钥匙，确保了只有你才能打开管理的大门。这套组合拳能有效抵御互联网上无休止的自动化扫描和低水平攻击，让你能更安心地专注于Stoat应用本身的业务价值。记住，安全是一个持续的过程，保持警惕，定期审查，你的自托管服务就能在风浪中稳健运行。