多因素认证（MFA）与自动化运维天然冲突，应避开MFA场景：Azure优先用托管标识（Connect-AzAccount -Identity），混合云用服务主体+证书认证，SSH需禁用PAM组合认证或白名单豁免，严禁sshpass、禁用MFA、Expect模拟等伪免交互方式。
多因素认证（MFA）本身与“免交互”存在天然冲突——它依赖人工参与（如点击验证、输入验证码、批准推送通知）。因此，自动化运维脚本中不能也不应绕过或模拟MFA交互。真正可行的方案是：避开MFA触发场景，改用无需人工介入的身份机制。
优先使用托管标识（推荐 Azure 场景）
在 Azure 自动化中，MFA 强制已于 2025 年 9 月起生效于用户账户登录（Connect-AzAccount -Credential）。但托管标识完全不受影响：
- 系统分配托管标识：部署在 VM、函数、逻辑应用等资源上后，直接运行
Connect-AzAccount -Identity即可登录，零凭据、零交互、零 MFA - 用户分配托管标识：在 Microsoft Entra 中统一创建和授权，再绑定到多个服务实例，权限集中管控，生命周期独立
- 所有访问都通过 Azure 自动签发的短期令牌完成，无需密码、无需 MFA、无需轮换密钥
改用服务主体 + 证书认证（通用云/企业环境）
当托管标识不可用（如本地数据中心、混合云），可用服务主体配合证书实现免交互且规避 MFA：
- 创建服务主体时，上传 PEM 或 PFX 格式证书（非密码），该证书私钥由脚本安全加载
- PowerShell 示例：
Connect-AzAccount -ServicePrincipal -CertificateThumbprint "xxx" -ApplicationId "yyy" -TenantId "zzz" - 证书可存于 Azure Key Vault 或本地受控目录，配合文件权限（如
chmod 600）限制访问 - 证书不触发 MFA，且比密码/密钥更难泄露（无明文凭据，支持硬件加密模块 HSM）
SSH 场景：密钥认证天然免 MFA
SSH 协议本身不内置 MFA，但部分企业 SSH 服务器会集成 PAM 模块强制二次验证。此时需确认并调整服务端策略：
- 确保目标主机的
/etc/ssh/sshd_config中未启用AuthenticationMethods publickey,keyboard-interactive等组合认证 - 若必须保留 MFA，应将自动化节点加入白名单（如通过
Match User或 IP 段跳过 PAM 检查） - 客户端始终使用
ssh -i /path/to/private_key，避免任何密码提示路径
绝对避免的“伪免交互”做法
以下方式看似绕过 MFA，实则严重危害安全，不应在生产环境中使用：
- 用
sshpass硬编码密码或 MFA 一次性码——密码明文出现在脚本或进程参数中，极易被ps aux或日志捕获 - 禁用 MFA 策略为自动化账号开后门——违背最小权限原则，放大攻击面
- 用 Expect 模拟人工输入验证码或点击推送——不可靠、易失效、违反合规要求（如 ISO 27001、等保2.0）
安全的自动化不是让 MFA “适应脚本”，而是让脚本“适配无 MFA 的安全身份”。托管标识和证书认证是当前最成熟、最符合云原生安全模型的选择。
