SSH 连接的安全认证流程：怎样保障账户不被盗用

SSH安全认证流程核心是不传输敏感凭证、不依赖单点信任、分阶段验证：先通过known_hosts确认服务端主机密钥防中间人攻击；再用非对称加密，由服务端发随机挑战、客户端用本地私钥解密并签名验签，确保私钥永不离设备；服务端须禁用密码登录、限制用户与认证方式；密钥需高强度生成、严格权限管控并定期轮换。

SSH 连接的安全认证流程，核心在于**不传输敏感凭证、不依赖单点信任、分阶段验证身份**。账户不被盗用，不是靠“密码够复杂”，而是靠整套机制的设计逻辑——从连接建立到登录完成，每一步都在堵住常见攻击路径。

服务端身份先确认：防中间人攻击

客户端第一次连服务器时，服务端会立刻发送自己的主机密钥（HostKey）指纹，比如 SHA256:xxxxxx。客户端检查本地 ~/.ssh/known_hosts 是否存过这个指纹：

• 如果存在且匹配，说明这台服务器“还是原来那台”，继续下一步
• 如果不存在，终端会警告：“无法建立主机真实性”，要求你手动确认（输入 yes）才写入；此时若弹出陌生指纹，极可能是中间人劫持
• 如果指纹突变（比如重装系统后没更新 known_hosts），连接会被拒绝或报警——这不是故障，是安全保护在起作用

用户身份靠非对称加密验证：私钥永不离开本地

公钥认证不是“把密码加密发过去”，而是“让服务器考你一道只有私钥能解的题”：

• 服务端从 ~/.ssh/authorized_keys 拿出你的公钥，生成一个随机数，用它加密后发给客户端
• 客户端用本地私钥解密，再结合会话ID算出一个签名值，发回服务端
• 服务端用同一公钥和原始随机数验签——对得上，人才在；对不上，立刻拒之门外
• 整个过程私钥不出设备，密码不走网络，暴力破解、嗅探、重放都失效

服务端配置必须收紧：关掉所有“方便但危险”的后门

再强的协议，配错了也白搭。关键配置项必须落实：

• PasswordAuthentication no：彻底禁用密码登录，杜绝弱口令和撞库风险
• PermitRootLogin no：禁止 root 直连，强制用普通用户 + sudo
• AllowUsers user1 user2：只允许可信用户名登录，缩小攻击面
• AuthenticationMethods publickey 或 publickey,keyboard-interactive：明确指定认证方式顺序，避免降级到密码
• 搭配 MaxAuthTries 3 和防火墙 fail2ban，让暴力尝试连三次就封 IP

密钥本身要管住：强度、存储、轮换一个都不能少

密钥不是一劳永逸的“万能钥匙”：

• 生成用 ssh-keygen -t ed25519 -a 100，别用老旧的 rsa1024
• 私钥文件权限必须是 600（chmod 600 ~/.ssh/id_ed25519），否则 SSH 客户端直接拒绝加载
• 用 ssh-agent 管理解密后的私钥，避免每次输密码；但 agent 会话需设超时（ssh-add -t 4h）
• 定期轮换密钥（如每90天），旧公钥及时从所有服务器的 authorized_keys 中删除