SSH：对象、配置与机制

客户端配置、主机信任与用户密钥

SSH 连接需要先确认服务器身份，再确认用户是否获准登录。入门先掌握 Host 配置、主机密钥与用户密钥的区别，随后学习跳板和转发；维护重点是可信绑定、最小授权与撤销。

两种不同的身份验证

SSH身份验证有两个方向：客户端先验证主机密钥对应可信服务器，服务器再验证用户公钥或其他凭据对应允许的账户。加密连接本身不能消除首次连接时的中间人风险。主机信任失败应停止连接并通过独立渠道核对指纹，不能先删除known_hosts再把新密钥当成正确答案。

配置优先级与别名

SSH配置优先级通常按命令行、用户配置、系统配置取值，多数参数采用首次取得值，多个IdentityFile等参数有累加规则。把具体Host放前面，通配默认放后面。别名可映射HostName、User和Port；检查配置时也要留意Include、Match exec和ProxyCommand，它们可能执行外部程序，应先审阅配置。

权限与客户端边界

SSH私钥权限应限制为专用账户访问；POSIX文件模式与Windows ACL是不同机制，不能复制chmod当成Windows原生修复。GUI工具与OpenSSH也可能使用不同密钥格式、代理与配置。先确认客户端实际读取的文件，再查权限，避免把密钥复制到更多目录。

练习与参考解答

练习：客户端提示主机密钥变化，但管理员确认用户公钥仍在authorized_keys。能否把StrictHostKeyChecking改成no继续？需要分别向谁索取哪类材料？

参考解答

不能，用户授权没有证明服务器身份。向可信资产/控制台负责人索取该主机端口的新主机公钥与指纹、轮换原因；再向目标账户管理员核对用户公钥授权。前者核验后才更新对应known_hosts条目，不能用网络采集结果自行背书。

认证、ProxyJump 与转发边界

先明确客户端配置、两端主机公钥与用户授权，再对照配套示例理解主机校验、用户认证和转发目标。

固定主机身份

StrictHostKeyChecking设为yes时要求主机身份已经可信，未知或变化会拒绝。known_hosts保存主机到公钥的绑定，非默认端口常使用方括号主机加端口形式。ssh-keyscan只能采集当前网络返回的公钥，不能代替独立渠道核验指纹；预置文件必须来源可信并记录变更责任人。

选择用户密钥

IdentitiesOnly限制客户端使用配置指定的身份，配合IdentityFile避免代理中大量密钥导致认证尝试耗尽。公钥部署到服务器并不意味着登录一定成功，还受账户、AuthorizedKeysFile、文件权限和服务端策略约束。私钥不传给跳板机，公钥不等同秘密但其授权位置仍要审计。

跳板与端到端验证

ProxyJump先连接跳板，再建立到目标主机的TCP转发；客户端仍需验证最终目标主机身份。目标Host配置通常不会自动应用给跳板，所以两端都需要独立配置用户与密钥。跳板能观察连接元数据，也能拒绝转发；通过跳板不等于获得目标账户权限。

代理转发的信任边界

ForwardAgent让远端使用本地代理完成签名，即使私钥字节不直接传走，远端被攻陷仍可能滥用签名能力。默认禁用，优先ProxyJump，确需转发时限制生命周期、目标和确认。不要把代理转发当成免复制密钥的无条件安全方案。

授权公钥的约束

authorized_keys可对特定公钥附加restrict、来源限制或固定命令，减少取得该密钥后的能力。固定命令的输入仍须验证，限制交互shell也不天然限制所有转发。服务端Match块、PermitOpen和AllowTcpForwarding要一起审查；配置语法可读不等于授权组合正确。

练习与参考解答

练习：跳板主机密钥已核验，ProxyJump能到达目标，但目标主机密钥未知。可以把跳板的known_hosts绑定复用给目标吗？只设ForceCommand能否限制所有转发？

参考解答

不能，跳板与目标是两份独立身份绑定，目标非默认端口要记录其对应主机/端口和公钥。ForceCommand只约束会话命令，TCP与Unix socket转发还需分别控制；本例明确设置AllowTcpForwarding与AllowStreamLocalForwarding，不能将固定命令当成转发禁令。