在CentOS服务器上仅使用密码或密钥登录SSH，依然可能因为弱口令、撞库或私钥泄露导致被入侵。双因素身份验证（2FA）通过叠加动态口令，让登录过程必须具备“知道的东西”和“拥有的东西”两类凭证，从而显著提升访问安全性。本文以CentOS 7/8为例，演示如何借助Google Authenticator实现SSH双因素验证。
一、双因素身份验证的基本原理
双因素身份验证是指结合两种不同类别的认证因子：第一类是知识因子，例如账号密码；第二类是持有因子，例如手机上的动态口令或硬件U盾。在SSH登录场景中，用户输入密码后，系统还会通过PAM（可插拔认证模块）调用TOTP（基于时间的一次性口令）校验逻辑，要求输入6位每隔30秒变化的数字。
这种机制的核心在于，即便攻击者在公网扫到开放22端口并掌握了你的密码，由于没有绑定在你手机里的密钥种子，也无法生成正确的动态码。CentOS使用的PAM框架允许我们在不修改SSH程序本身的情况下，插入额外的认证步骤，这也是Linux服务器落地2FA的通用做法。
二、安装与基础配置
首先需要在CentOS上安装Google Authenticator的PAM模块和命令行工具。使用yum或dnf均可完成，命令如下：
# 安装EPEL源（若未配置） yum install -y epel-release # 安装Google Authenticator PAM模块 yum install -y google-authenticator
安装完成后，对需要开启2FA的普通用户执行初始化。以当前用户身份运行google-authenticator命令，工具会交互式生成密钥并展示二维码。
# 为当前用户生成TOTP配置 google-authenticator # 交互过程关键选择 Do you want me to update your "/home/user/.google_authenticator" file? (y/n) y Do you want to disallow multiple uses of the same authentication token? y By default, tokens are good for 30 seconds... Do you want to enable time skew? n ...
执行后，终端会显示一个secret key和二维码，使用Google Authenticator、FreeOTP等App扫码绑定。生成的配置文件<code>.google_authenticator</code>保存在用户家目录，权限应为600，防止其他用户读取。
三、修改PAM与SSH服务配置
要让SSH在密码之后追加动态码校验，需要编辑两个地方：一是PAM的sshd配置，二是sshd主配置文件。先修改<code>/etc/pam.d/sshd</code>，在文件末尾追加一行。
# 在 /etc/pam.d/sshd 末尾添加 auth required pam_google_authenticator.so
然后编辑<code>/etc/ssh/sshd_config</code>，确保以下参数设置正确，使SSH使用PAM且支持键盘交互认证。
# /etc/ssh/sshd_config 关键项 UsePAM yes ChallengeResponseAuthentication yes # 若希望密码和动态码在同一提示下输入，可保持默认 # 若希望先密码后动态码分两步，可设置： # AuthenticationMethods publickey,password publickey,keyboard-interactive
修改完毕后重启sshd服务使配置生效。注意在测试阶段务必保留一个已有会话，避免配置错误导致无法登录。
# CentOS 7 systemctl restart sshd # CentOS 8 systemctl restart sshd.service
四、登录验证与常见问题
重新打开终端尝试SSH连接，输入密码后系统会提示<code>Verification code:</code>，此时填入App中的6位动态码即可登入。如果配置为公钥加2FA，则先完成密钥握手，再要求动态码。
ssh user@192.168.0.1 Password: Verification code: Last login: ...
常见故障包括：手机时间与服务器不同步导致令牌失效，可用<code>ntpdate</code>校准；SELinux阻止PAM读取家目录文件，可临时设permissive模式排查；以及root用户未生成.google_authenticator文件却强制开启2FA，造成root无法登录。建议先对非root账号开启，确认无误后再决定是否覆盖root。
五、软件令牌与硬件密钥的对比
除了手机App生成的TOTP，也可以使用支持U2F的硬件密钥（如YubiKey）配合pam_u2f模块实现2FA。两者对比如下：
| 方案 | 部署成本 | 抗钓鱼能力 | 适用场景 |
|---|---|---|---|
| TOTP软件令牌 | 低，免费App即可 | 中，依赖用户不截图密钥 | 个人服务器、小团队 |
| U2F硬件密钥 | 高，需购买设备 | 高，基于挑战应答防中间人 | 企业内网、高安全需求 |
TOTP方案胜在零成本且易于批量推广，适合大多数CentOS运维场景；硬件密钥则更能抵御高级钓鱼，但需考虑丢失备用问题。实际落地时可要求关键账号同时使用两类因子做冗余。
六、运维建议
开启双因素后，仍应保留SSH端口访问白名单、fail2ban防暴破等配套手段。2FA不是银弹，而是纵深防御的一环。定期审计<code>.google_authenticator</code>文件权限，并在员工离职时及时删除对应配置，避免凭证残留。
对于批量服务器，可通过配置管理工具（Ansible等）统一下发PAM配置与用户密钥模板，减少人工逐台操作。这样既能保证CentOS访问安全策略一致，也方便后续平滑升级认证模块版本。