使用deploy-rs修改远程主机SSH端口的最佳实践

背景介绍

在NixOS系统管理中，deploy-rs是一个强大的部署工具，它允许管理员通过声明式配置来管理远程服务器。在实际运维中，出于安全考虑，管理员经常需要将默认的SSH端口从22更改为其他端口，以减少自动化扫描和暴力攻击的风险。

问题分析

当使用deploy-rs修改SSH端口时，会遇到一个典型的"鸡生蛋蛋生鸡"问题：

1. 首先修改配置将SSH端口从22改为新端口（如12345）
2. 部署工具需要通过SSH连接到服务器应用这个变更
3. 但此时SSH端口已经改变，导致后续验证连接失败

这会导致部署过程中出现激活确认超时错误，最终系统会回滚变更，使得端口修改无法生效。

解决方案

方法一：使用--magic-rollback参数

最直接的解决方案是在部署时添加--magic-rollback false参数，这会禁用部署后的验证步骤：

nix run github:serokell/deploy-rs . -- --magic-rollback false

这种方法简单直接，但需要注意：

• 部署后需要立即手动测试新端口是否工作正常
• 后续所有部署都需要指定新的SSH端口

方法二：分阶段部署（推荐）

更安全的做法是采用分阶段部署策略：

1. 第一阶段：配置SSH同时监听新旧两个端口

   services.openssh.ports = [ 22 12345 ];
   

2. 使用默认端口22完成首次部署验证

3. 第二阶段：移除旧端口，仅保留新端口

   services.openssh.ports = [ 12345 ];
   

4. 在deploy-rs配置中添加SSH端口参数

   sshOpts = [ "-p" "12345" ];
   

5. 使用新端口完成最终部署

这种方法虽然步骤较多，但更加安全可靠，避免了服务中断风险。

技术原理

deploy-rs的工作流程包含几个关键阶段：

1. 构建阶段：在本地生成系统配置
2. 推送阶段：将配置传输到目标主机
3. 激活阶段：在目标主机上应用配置
4. 验证阶段：检查服务是否正常运行

当修改SSH端口时，验证阶段会因为连接参数不匹配而失败，触发系统的自动回滚机制。理解这个流程有助于我们找到合适的解决方案。

安全建议

1. 修改SSH端口后，建议同时配置防火墙规则，限制访问来源IP
2. 考虑结合SSH密钥认证和密码认证禁用等安全措施
3. 对于生产环境，建议在维护窗口期进行此类变更
4. 变更后务必测试所有自动化工具和监控系统是否适配新端口

总结

在NixOS生态中使用deploy-rs修改SSH端口时，管理员需要特别注意部署流程的特殊性。通过理解工具的工作原理，并采用分阶段部署策略，可以安全可靠地完成这一常见运维任务，同时提升系统安全性。