不建议利用ssh的hostbasedauthentication实现内网服务器互信加固，因其存在不验证用户身份、主机名易伪造、信任文件权限难管控三大缺陷，反而引入高危风险。
不建议利用SSH的HostbasedAuthentication实现内网服务器互信加固。
它名义上是“主机级互信”，实际却因设计缺陷成为高危入口，不是加固手段，而是安全短板。
以下三点说明为什么它不适合用于互信加固：
不验证用户身份，只认主机名或IP
HostbasedAuthentication依赖客户端主机的公钥+服务端信任列表（如/etc/hosts.equiv、~/.shosts），但完全跳过用户私钥校验。只要攻击者控制了一台被信任的主机（哪怕只是普通用户权限），就能以任意本地用户身份冒充登录目标服务器。主机名极易被伪造
服务端通过反向DNS（PTR）查出客户端IP对应的主机名，再正向解析验证一致性。但内网中DNS常由不可信设备托管，/etc/hosts也可被本地用户篡改——这意味着攻击者只需在客户端修改/etc/hosts或劫持DNS响应，就能让服务端误判为“可信主机”。信任文件权限敏感、清理困难
/etc/hosts.equiv、~/.rhosts、/etc/ssh/shosts.equiv等文件一旦权限宽松（如组可写）、内容含通配符或FQDN，就构成信任链失控风险。运维中常遗漏清理历史测试条目，形成隐蔽后门。
真正适合内网互信的加固方式是：
✅ 密钥对单向认证 + 严格主机密钥校验
使用ssh-keygen -t ed25519生成高安全性密钥，配合ssh-copy-id部署；客户端配置StrictHostKeyChecking yes和预置的KnownHostsFile，彻底规避中间人弹窗与误点“yes”。✅ OpenSSH CA 签发主机与用户证书（推荐中大型环境）
统一由内网CA签发主机证书（用于服务端身份）和用户证书（绑定UID/Groups），服务端启用TrustedUserCAKeys和HostCertificate，实现集中管控与自动轮换。✅ PAM + IP白名单 + 登录上下文限制
结合pam_access.so限制仅允许特定网段的主机发起Hostbased类请求（即使启用也极小范围），再叠加AllowGroups ssh-trusted-hosts做二次过滤，并关闭IgnoreRhosts yes防绕过。
若当前环境已启用HostbasedAuthentication，应立即执行：
- 检查并确保
/etc/ssh/sshd_config中：HostbasedAuthentication no IgnoreRhosts yes
- 删除所有
find / -name ".rhosts" -o -name ".shosts" -o -name "hosts.equiv" 2>/dev/null - 重载服务：
sudo systemctl reload sshd
本质上，HostbasedAuthentication是上世纪90年代遗留机制，在现代零信任架构下已无加固价值。用它替代密钥管理，相当于用门禁卡复制器代替指纹锁——看似省事，实则自毁防线。
