MFA不参与网络层控制，仅在SSH认证阶段生效；安全组管控端口访问，SSH配置决定认证流程，MFA叠加验证，三者分层协同、顺序执行。
服务器多因素认证（MFA）本身不直接参与网络层的接入控制，它只在SSH认证阶段生效。要实现与SSH接入控制和安全组的“无缝联动”，关键不是让MFA去接管防火墙或网络策略，而是通过分层协同：安全组管“能不能连到22端口”，SSH配置管“连上了能不能登录”，MFA则管“登录时要不要再验一次”。三者职责分明、顺序执行，才能既安全又可靠。
安全组：第一道门禁，只放行可信来源
安全组是云平台或主机防火墙（如iptables/nftables）的策略抽象，作用于网络连接建立前。它应严格限制SSH端口（默认22）的入向访问：
- 禁止0.0.0.0/0全开放，仅允许可信IP段（如企业办公网出口、运维跳板机IP、CI/CD构建节点）
- 若使用动态IP或移动办公，可配合IP白名单服务（如Cloudflare Access、阿里云WAF IP黑白名单）做前置收敛
- 避免将MFA作为放宽安全组的理由——哪怕启用了MFA，也不该暴露22端口给公网扫描器
SSH服务配置：决定认证流程是否启用MFA
OpenSSH本身不内置MFA，需通过PAM（Pluggable Authentication Modules）桥接。真正的“联动”发生在/etc/ssh/sshd_config与/etc/pam.d/sshd的配合中：
- 必须开启UsePAM yes：否则PAM模块（如pam_google_authenticator.so或pam_duo.so）完全不加载
- ChallengeResponseAuthentication yes：启用交互式挑战（如输入验证码），这是TOTP类MFA的必要开关
- PasswordAuthentication yes 或 PubkeyAuthentication yes：MFA是叠加在第一因素之上的，不能单独存在；密钥用户同样需要MFA，除非显式配置跳过
- 若用Google Authenticator，需在/etc/pam.d/sshd开头添加：
auth [success=ok default=bad] pam_google_authenticator.so nullok
MFA模块配置：绑定用户级策略，支持差异化控制
MFA不是全局开关，而是按用户或组精细控制。例如：
- Google Authenticator支持 per-user 配置文件（~/.google_authenticator），管理员可为高权限账号强制启用，普通账号可选
- Duo支持在/etc/duo/pam_duo.conf中配置failmode=safe（认证失败时降级为仅密码）或failmode=secure（失败即拒登），并可通过groups=admins限定仅对特定Linux组生效
- 结合SSHD的Match块，可实现“从跳板机来的连接跳过MFA，其他来源必须MFA”：
Match Address 192.168.10.0/24
AuthenticationMethods publickey
Match All
AuthenticationMethods publickey,keyboard-interactive
日志与审计：让三者行为可追溯、可关联
真正体现“联动效果”的是统一审计能力：
- 安全组拒绝连接：记录在云平台控制台（如AWS VPC Flow Logs、阿里云安全组日志），显示REJECT或DROP
- SSH连接建立但认证失败：记录在/var/log/auth.log或journalctl -u sshd，含PAM模块返回码（如pam_google_authenticator(sshd:auth): Invalid verification code）
- 建议将三者日志接入同一SIEM系统（如ELK、Splunk），用源IP+时间戳+用户名做关联分析，快速识别“绕过安全组的横向移动”或“MFA绕过尝试”
