一、协议层加固：阻断非必要通信
SSH协议默认使用22端口，但长期暴露该端口易成为攻击目标。通过协议层优化，可有效降低端口暴露风险。
1. 端口迁移与伪装
关闭安全入口后，建议将SSH服务从默认的22端口迁移至高位随机端口（如1024-65535范围内未被占用的端口）。此操作需同步修改客户端连接配置，例如将连接命令从ssh user@IP改为ssh -p 新端口 user@IP。端口迁移的实质是通过修改SSH服务配置文件（如/etc/ssh/sshd_config中的Port参数）实现的，其核心价值在于打破攻击者对默认端口的扫描习惯。
进一步地，可结合端口伪装技术，在防火墙规则中配置对22端口的响应策略。例如，使用iptables或nftables将22端口的入站流量重定向至无效服务，或直接丢弃。此操作需谨慎评估业务依赖性，确保不会影响其他服务的正常通信。
2. 协议版本限制
SSH协议存在v1和v2两个版本，其中v1因存在加密漏洞已被淘汰。在加固过程中，需确保服务端仅启用v2版本。通过修改sshd_config文件中的Protocol参数为2，可强制禁用v1。此操作可有效阻断利用v1漏洞的中间人攻击和会话劫持尝试。
3. 连接超时与重试限制
攻击者常通过自动化工具对SSH端口发起高频连接请求，以暴力破解密码或密钥。通过设置连接超时和重试限制，可显著增加攻击成本。例如，在sshd_config中配置LoginGraceTime 30s将登录超时时间缩短至30秒，同时设置MaxAuthTries 3限制每个用户的最大认证尝试次数。此策略可快速终止异常连接，减少服务端资源占用。
二、认证层加固：提升身份验证强度
SSH服务的核心安全风险源于弱认证机制。关闭安全入口后，需通过多因素认证、密钥管理等手段强化身份验证流程。
1. 禁用密码认证，强制使用密钥对
密码认证易受字典攻击和暴力破解影响，而密钥对认证通过非对称加密技术提供更高的安全性。在sshd_config中设置PasswordAuthentication no并启用PubkeyAuthentication yes后，用户需使用私钥文件（需妥善保管）和对应公钥（需提前部署至服务端~/.ssh/authorized_keys文件）完成认证。此操作需同步向用户提供密钥生成与管理指南，例如使用ssh-keygen工具生成RSA或ECDSA类型密钥，并强调私钥文件的权限设置（如chmod 600 ~/.ssh/id_rsa）。
2. 多因素认证（MFA）集成
对于高安全需求场景，可在密钥认证基础上叠加动态令牌或时间同步令牌（如Google Authenticator）。其实现原理为：用户登录时需提供私钥和由令牌生成的动态验证码，服务端通过验证两者匹配性完成认证。此方案需依赖PAM（Pluggable Authentication Modules）模块扩展，具体配置需参考对应系统的PAM文档。
3. 认证失败日志监控
通过分析SSH服务的认证日志（通常位于/var/log/auth.log或/var/log/secure），可及时发现异常登录行为。建议配置日志分析工具（如Fail2Ban或Logwatch）实时监控认证失败事件，当同一IP在短时间内触发多次失败尝试时，自动将其加入防火墙黑名单。例如，Fail2Ban可通过解析日志中的Failed password关键词，动态生成iptables规则阻断攻击源。
三、访问控制层加固：精细化流量管理
通过限制SSH端口的访问来源和权限，可进一步缩小攻击面。
1. 基于IP的访问限制
在防火墙层面，仅允许特定IP或IP段访问SSH端口。例如，使用iptables规则iptables -A INPUT -p tcp --dport 新端口 -s 信任IP -j ACCEPT，将访问权限限制为内部网络或已知运维IP。对于动态IP场景，可结合VPN或跳板机方案，将SSH访问流量统一收敛至可控节点。
2. 网络层隔离与分段
通过VLAN或安全组（如Linux的Network Namespace）将SSH服务部署在独立网络区域，与其他业务服务隔离。例如，将SSH端口绑定至管理专用网卡，并禁止该网卡与其他业务网卡的通信。此策略可防止攻击者通过横向移动渗透至其他服务。
3. 用户权限最小化
即使通过SSH登录成功，用户仍需遵循最小权限原则。建议通过用户组管理限制普通用户的命令执行权限，例如使用sudo配置细粒度权限（如仅允许执行特定系统管理命令）。同时，定期审计用户账户，及时清理长期未使用的账户和过期密钥。
四、运维层加固：持续监控与响应
安全加固并非一次性任务，需通过持续监控和快速响应机制保障长期安全性。
1. 定期安全审计
定期检查SSH服务配置文件（如sshd_config）是否被意外修改，验证端口、认证方式等关键参数是否符合安全策略。同时，审计authorized_keys文件中的公钥列表，确保无未授权密钥注入。
2. 异常行为告警
配置系统监控工具（如Prometheus+Grafana）实时跟踪SSH端口的连接数、认证失败率等指标。当指标超过阈值时，触发告警通知运维人员。例如，设置认证失败率阈值为5次/分钟，超过后立即通过邮件或短信告警。
3. 应急响应流程
制定SSH端口被攻破后的应急响应流程，包括隔离受影响主机、分析攻击路径、修复漏洞、恢复服务等步骤。建议定期演练应急流程，确保团队熟悉操作步骤。
五、高级防护方案（可选）
对于高安全需求场景，可进一步探索以下方案：
- SSH证书认证：通过CA签发的证书替代传统密钥对，实现集中化密钥管理。
- 端口敲门（Port Knocking）：用户需按特定顺序访问一组关闭端口后，SSH端口才会开放，增加攻击难度。
- 双因素网关：在SSH服务前部署专用认证网关，用户需先通过网关认证（如动态令牌）后才能访问SSH端口。
结语
关闭宝塔安全入口后，SSH端口的加固需从协议、认证、访问控制、运维四个层面构建防御体系。通过端口迁移、密钥认证、IP限制、日志监控等手段，可显著降低端口暴露风险。同时，持续的安全审计和应急响应机制是保障长期安全性的关键。开发者应根据实际业务需求和安全等级，灵活选择加固策略，平衡安全性与易用性。
