Fedora35下JGSS initSecContext失败：无法找到Kerberos TGT

核心问题定位 #

从日志和代码来看，导致initSecContext失败的主要原因有三个：

1. JAAS配置的发起方标识错误：日志显示isInitiator false，客户端作为GSS上下文的发起方，必须将该参数设为true，否则JAAS无法正确处理发起方的凭证逻辑。
2. GSS操作未关联JAAS登录凭证：代码中创建GSSContext时，没有绑定JAAS登录后得到的Subject，导致GSSAPI无法访问JAAS获取的凭证，只能尝试从系统默认位置查找，最终找不到TGT。
3. Fedora 35的KCM缓存兼容性：Fedora默认使用KCM（基于密钥环的凭证缓存），而Java Kerberos实现需要显式指定缓存类型，否则无法识别KCM中的TGT。

具体修复步骤 #

1. 修正JAAS配置文件（/etc/kafka/jaas.conf） #

确保JaasClient条目配置正确，明确设置发起方标识和缓存类型：

JaasClient {
    com.sun.security.auth.module.Krb5LoginModule required
    useTicketCache=true
    ticketCache="KCM:1000"
    isInitiator=true
    principal="client@TEST.COM";
};

也可以通过环境变量export KRB5CCNAME=KCM:1000来指定缓存，避免硬编码UID。

2. 修改代码，绑定JAAS Subject到GSS操作 #

JAAS登录后的凭证存储在Subject中，必须通过Subject.doAs将GSS逻辑包裹，让GSSAPI能访问到这些凭证：

// JAAS登录成功后，替换原GSS相关代码为：
Subject subject = lc.getSubject();
try {
    Subject.doAs(subject, (PrivilegedExceptionAction<Void>) () -> {
        // 创建GSS上下文
        String ops = "";
        GSSContext context = null;
        try {
            Oid krb5Oid = new Oid("1.2.840.113554.1.2.2");
            ops = "new OID";
            GSSManager manager = GSSManager.getInstance();
            ops = "createName";
            GSSName serverName = manager.createName(principal, null);
            ops = "createContext";
            context = manager.createContext(serverName, krb5Oid, null, GSSContext.DEFAULT_LIFETIME);
            context.requestMutualAuth(true);
            context.requestConf(true);
            context.requestInteg(true);
        } catch (GSSException e) {
            error(String.format("GSS internal error (%s):", ops), e, ERR_GSS);
        }
        System.out.println("Context created");

        // 上下文建立循环（补充原代码缺失的收发逻辑）
        byte[] token = new byte[0];
        while (!context.isEstablished()) {
            try {
                token = context.initSecContext(token, 0, token.length);
                System.out.println("Token generated");
                // 发送token到服务器
                if (token != null && token.length > 0) {
                    outStream.writeInt(token.length);
                    outStream.write(token);
                    outStream.flush();
                    // 接收服务器返回的token
                    int tokenLen = inStream.readInt();
                    token = new byte[tokenLen];
                    inStream.readFully(token);
                }
            } catch (GSSException e) {
                error(String.format("GSS internal error (%s):", "initSecContext"), e, ERR_GSS);
            }
        }
        return null;
    });
} catch (PrivilegedActionException e) {
    error("Privileged action failed:", e.getException(), ERR_GSS);
}

原代码缺少token的收发逻辑，这也是上下文无法建立的潜在问题，必须补充。

3. 确保Java识别KCM缓存 #

运行程序前设置环境变量：

export KRB5CCNAME=KCM:1000
java tsn.jaas.gssClient

或者在代码中添加：

System.setProperty("java.security.krb5.ccname", "KCM:1000");

4. 清理冗余配置 #

代码中同时设置了java.security.auth.login和java.security.auth.login.config，保留其中一个即可：

System.setProperty("java.security.auth.login.config", "/etc/kafka/jaas.conf");

额外排查思路 #

• 检查/etc/krb5.conf中的default_ccache_name是否为KCM:%{uid}，确保系统默认缓存类型为KCM。
• 执行kinit -c KCM:1000重新获取TGT，确认缓存写入正常。
• 开启Java Kerberos debug日志：运行时添加-Dsun.security.krb5.debug=true参数，查看凭证查找的详细过程。

内容的提问来源于stack exchange，提问作者Pascal Jakobi