为什么需要 Kerberos 版的 NFS
sec=sys 模式下服务端无条件相信客户端报上来的 UID：只要网络可达、伪造请求的 UID，就能以别人身份读写共享。Kerberos 把这一步换成可验证的票据：客户端先向 KDC 证明自己是谁，服务端再用自己的 keytab 验证票据，最后通过 idmap 把 Kerberos 主体映射成本地 UID。它同时解决了「对端是谁」和「流量是否被篡改」两个问题。
基本信息
| 适用平台 | Linux NFSv4 服务端与客户端 + MIT Kerberos（或 AD 提供的 KDC） |
|---|---|
| 服务端要件 | rpc.gssd、rpc.svcgssd、nfs/<主机名> 主体与 keytab |
| 客户端要件 | kinit 可获取票据、rpc.gssd、nfsidmap 在运行 |
| 挂载参数 | sec=krb5、sec=krb5i 或 sec=krb5p |
| 关键前提 | 双向 DNS 解析正确、主机时钟偏差在阈值内 |
三种安全级别对照
| sec 值 | 提供的能力 | 适用场合 |
|---|---|---|
| krb5 | 身份认证 | 内网共享，只关心「谁在访问」 |
| krb5i | 认证加完整性校验 | 需要防止流量被篡改 |
| krb5p | 认证、完整性加全载荷加密 | 跨不可信网络访问数据 |
服务端与客户端要点
服务端与客户端要点
# 服务端导出必须显式声明 sec，否则客户端协商会回落到 sys
/data/secure *(rw,sync,sec=krb5p,root_squash)
# 服务端确认主体与 keytab（键表路径以实际发行版为准）
klist -k /etc/krb5.keytab | grep nfs
# 客户端取票据后再挂载，并确认协商到的安全模式
kinit -k -t /etc/krb5.keytab host/client01.example.com@EXAMPLE.COM
mount -t nfs -o vers=4.2,sec=krb5p 10.0.0.10:/data/secure /mnt/secure
cat /proc/mounts | grep secure身份映射检查
身份映射检查
mount -t nfs -o vers=4.2,sec=krb5 10.0.0.10:/data/secure /mnt/secure
ls -ln /mnt/secure # 若属主显示 nobody，说明 idmap 没映射到本地账号
nfsidmap -c # 清理映射缓存后重试，避免旧映射干扰判断
systemctl status rpc-gssd nfs-idmapd # 确认相关守护进程在运行服务端导出里的 sec 列表与客户端挂载参数必须覆盖到同一个安全级别。只写 sec=krb5p 而客户端请求 krb5，协商会失败；也不要把 sec 省略后依赖默认值，否则可能静默回落到 sys，加密等于没开。
keytab 里含服务端的长期密钥，泄露即等于任何主机都能冒充这台 NFS 服务器。文件权限要限制到只有相关守护进程可读，不要复制到业务目录或纳入普通代码备份。