主页 / unix / 问题

问题[kerberos](unix)

Martin Hope
user84207
Asked: 2024-05-28 07:17:50 +0800 CST
  • 6

我在将 Kerberos 密钥导出和导入 openafs 时遇到了麻烦。

我的第一个问题是，当使用addprinc和ktadd命令时kadmin.local，加密密钥类型-e选项似乎被忽略。例如，当我尝试添加 type 的键时，似乎会添加des-cbc-crc:v4type 的键：aes256-cts-hmac-sha1-96

kadmin.local:  ktadd -e des-cbc-crc:v4 -k /tmp/afs.ktab afs
Entry for principal afs with kvno 4, encryption type aes256-cts-hmac-sha1-96 added to keytab WRFILE:/tmp/afs.ktab.
Entry for principal afs with kvno 4, encryption type aes128-cts-hmac-sha1-96 added to keytab WRFILE:/tmp/afs.ktab.

同样的情况也发生在 addprinc 上，我尝试指定-e DES-CBC-CRC:md5密钥类型，但这似乎被忽略了，最终得到了一个aes128-cts-hmac-sha1-96密钥：

$ kadmin.local
Authenticating as principal root/[email protected] with password.
kadmin.local:  addprinc -policy service -randkey -e DES-CBC-CRC:md5 afs
WARNING: policy "service" does not exist
Principal "[email protected]" created.
kadmin.local:  getprinc afs
Principal: [email protected]
Expiration date: [never]
Last password change: Mon May 27 18:22:21 EDT 2024
Password expiration date: [never]
Maximum ticket life: 0 days 10:00:00
Maximum renewable life: 7 days 00:00:00
Last modified: Mon May 27 18:22:21 EDT 2024 (root/[email protected])
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 2
Key: vno 1, aes256-cts-hmac-sha1-96
Key: vno 1, aes128-cts-hmac-sha1-96
MKey: vno 1
Attributes: REQUIRES_PRE_AUTH
Policy: service [does not exist]
kadmin.local:

此外，当我尝试使用 导入此密钥时asetkey，我收到一条不可读的错误消息：

sudo asetkey add 4 /tmp/afs.ktab afs
asetkey: unknown RPC error (-1765328203) for keytab entry with Principal [email protected], kvno 4, DES-CBC-CRC/MD5/MD4

阅读asetkey联机帮助页时，我看到强烈建议不要使用des-cbc-crc密钥类型并使用rxkad-k5扩展名：

A modern AFS cell should be using the rxkad-k5 extension, or risks terribly insecure operation (complete cell compromise for $100 in 1 day).  The
       keys used for rxkad-k5 operation are stored in the KeyFileExt.  Cells not using the rxkad-k5 extension (i.e., stock rxkad) use keys of the des-cbc-
       crc encryption type, which are stored in the KeyFile.

进一步阅读，KeyFileExt手册页说尝试添加rxkad-k5键需要指定一个krb5 encryption type number，它与字符串标识符不同：

Using asetkey(8) to add rxkad-k5 keys to the KeyFileExt also requires specifying a krb5 encryption type number.
       Since the encryption type must be specified by its number (not a symbolic or string name), care must be taken to determine the correct encryption
       type to add.

我被很多相关的问题困扰着：

  1. 为什么kadmin似乎忽略我指定的加密类型？

  2. 如何确定我的 openafs 是否正在使用该rxkad-k5扩展？我通过apt-cache search rxkad-k5和搜索了 debian 软件包，rxkad但什么也没找到。

  3. 由于aes256-cts-hmac-sha1-96看起来像一个字符串标识符，我如何确定此加密的“krb5 加密类型编号”以便通过 asetkey 导入它？

  4. 我注意到openafs-krb5是来自的一个单独的包openafs-{fileserver,dbserver,client}。有没有推荐的方法来管理 debian 上的 openafs 身份验证而无需设置 kerberos？

  5. 我发现akeyconvert声称可以帮助导入密钥from the krb5 keytab format to the KeyFileExt format。我应该使用akeyconvert它来将密钥转换afs.keytab为 openafs 吗？

kerberos
Martin Hope
Seeker
Asked: 2023-11-25 02:06:34 +0800 CST
  • 6

我遇到了将 Linux 服务器加入 Active Directory 域时自动创建的密钥表条目的问题。首先说一下我的流程：

  1. 安装所需的 Linux 软件包yum install realmd pam sssd adcli oddjob oddjob-mkhomedir samba-common-tools krb5-workstation
  2. 在 Active Directory 中创建计算机对象并添加相关 SPN 条目 (servicePrincipalName)
  3. 执行域加入realm join -v EXAMPLE.COM -U domainUser

在加入过程中，该过程会自动创建一个 krb5.keytab 文件，其中的条目与计算机对象的 SPN 条目直接匹配。因此，如果 SPN 具有[email protected]条目，则加入过程会创建[email protected]密钥表条目。 问题是，如果 SPN 的名称中包含大写的服务类型，则密钥表生成过程不会考虑服务类型的大小写，而是强制密钥表条目具有小写的服务类型。因此，如果 SPN 为HTTP /Se [email protected]，则密钥表生成器会强制其为http / [email protected]，在域加入过程中。为了使我正在使用的应用程序正常工作，这些需要匹配（均为大写）。

我的目标是拥有一个与 SPN（大写服务类型）匹配的密钥表条目，据我所知，我有两个选择

  1. 修复realm join流程以保持服务类型的大小写相同，或者
  2. 在 keytab 文件中创建我自己的 keytab 条目  

我对这两个选项都有问题。对于第一个选项，我找不到任何可以更改的加入过程。对于第二个选项，我找到了两个可以使用的应用程序来创建我自己的条目。这些应用程序是 kadmin 和 ktutil。kadmin 给我一个错误“所需的 KADM5 主体缺失...”（我不知道如何修复）。ktutil 选项也可以使用，只不过它需要将相同的密码应用于这个新的 keytab 条目，该密码由其他 keytab 条目使用；但是，该密码由 Active Directory 管理，无法获取。

有没有其他人以前遇到过这个问题，并有关于如何将密钥表条目的服务类型保持大写的解决方案？

谢谢！

kerberos
Martin Hope
elbarna
Asked: 2019-12-01 15:38:49 +0800 CST
  • 2

虽然被称为弱加密类型，但我想知道如何在 Samba 4.11 上启用 des-cbc-md5，在​​此文档中说明：

des-cbc-md5（默认禁用）

des-cbc-md5 可以通过在用户级别启用 DES 来启用，但这通常被认为不安全，这就是默认禁用它的原因。"

“在用户级别”是什么意思？我试图编辑文件/var/lib/samba/private/kdc.conf，但如果 des-md5-cbc 包含在支持的 enctypes 行中，samba 将不会重新启动。

kerberos samba4
Martin Hope
elbarna
Asked: 2019-03-03 05:32:58 +0800 CST
  • 1

我想挂载一个 nfs4 kerberized 共享。我在centos7上，kerberos服务器是Freeipa，客户端是centos7。问题是我的配置适用于 nfs3，但不适用于 nfs4。首先我把我的配置

/etc/出口

/export         10.2.0.0/24(ro,no_subtree_check,fsid=0,)
/export/public      10.2.0.0/24(ro,no_subtree_check,async,root_squash,nohide,sec=sys)
/export/private     10.2.0.0/24(ro,no_subtree_check,async,root_squash,nohide,sec=krb5p)

/etc/nfsmount.conf

   [ NFSMount_Global_Options ]
    Defaultvers=4
    Defaultproto=tcp
    mountport=4001
    Port=2049

/etc/krb5.conf

#File modified by ipa-client-install

includedir /etc/krb5.conf.d/
includedir /var/lib/sss/pubconf/krb5.include.d/

[libdefaults]
  default_realm = MYREALM.FAKE
  dns_lookup_realm = true
  dns_lookup_kdc = true
  rdns = false
  dns_canonicalize_hostname = false
  ticket_lifetime = 24h
  forwardable = true
  udp_preference_limit = 0
  default_ccache_name = KEYRING:persistent:%{uid}


[realms]
  MYREALM.FAKE = {
    pkinit_anchors = FILE:/var/lib/ipa-client/pki/kdc-ca-bundle.pem
    pkinit_pool = FILE:/var/lib/ipa-client/pki/ca-bundle.pem

  }


[domain_realm]
  .myrealm.fake = MYREALM.FAKE
  myrealm.fake = MYREALM.FAKE
  centos1.myrealm.fake = MYREALM.FAKE

我得到我的钥匙

echo mypassword|kinit myuser

klist 报告 ok

现在，尝试在没有 kerberos+nfs4 的情况下挂载“public”

mount -t nfs  centos1:/public /mnt/ -vvv
mount.nfs: timeout set for Sat Mar  2 14:23:05 2019
mount.nfs: trying text-based options 'mountport=4001,port=2049,vers=4.1,addr=10.2.0.77,clientaddr=10.2.0.77'

没关系

现在没有 kerberos+nfs3 的“公众”

mount -t nfs  centos1:/export/public /mnt/ -vvv
mount.nfs: timeout set for Sat Mar  2 14:26:41 2019
mount.nfs: trying text-based options 'vers=4.1,addr=10.2.0.77,clientaddr=10.2.0.77'
mount.nfs: mount(2): No such file or directory
mount.nfs: trying text-based options 'addr=10.2.0.77'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying 10.2.0.77 prog 100003 vers 3 prot TCP port 2049
mount.nfs: prog 100005, trying vers=3, prot=17
mount.nfs: trying 10.2.0.77 prog 100005 vers 3 prot UDP port 20048

没关系

现在是 kerberos+nfs3 的“私有”

mount -t nfs  centos1:/export/private /mnt/ -vvv
mount.nfs: timeout set for Sat Mar  2 14:28:05 2019
mount.nfs: trying text-based options 'vers=4.1,addr=10.2.0.77,clientaddr=10.2.0.77'
mount.nfs: mount(2): No such file or directory
mount.nfs: trying text-based options 'addr=10.2.0.77'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying 10.2.0.77 prog 100003 vers 3 prot TCP port 2049
mount.nfs: prog 100005, trying vers=3, prot=17
mount.nfs: trying 10.2.0.77 prog 100005 vers 3 prot UDP port 20048

没关系。

问题是如果我尝试使用 nfs4

mount -t nfs4  centos1:/private /mnt/ -vvv
mount.nfs4: timeout set for Sat Mar  2 14:29:54 2019
mount.nfs4: trying text-based options 'vers=4.1,addr=10.2.0.77,clientaddr=10.2.0.77'
mount.nfs4: mount(2): Operation not permitted
mount.nfs4: Operation not permitted

我也从其他客户端尝试过，同样的错误 Ipa 服务器报告

Mar 02 14:29:12 freeipa.realm.fake krb5kdc[611](info): AS_REQ (8 etypes {18 17 20 19 16 23 25 26}) 10.2.0.77: NEEDED_PREAUTH: [email protected] for krbtgt/[email protected], Additional pre-authentication required
Mar 02 14:29:12 freeipa.realm.fake krb5kdc[611](info): closing down fd 11
Mar 02 14:29:12 freeipa.realm.fake krb5kdc[611](info): AS_REQ (8 etypes {18 17 20 19 16 23 25 26}) 10.2.0.77: ISSUE: authtime 1551533352, etypes {rep=18 tkt=18 ses=18}, [email protected] for krbtgt/[email protected]
Mar 02 14:29:12 freeipa.realm.fake krb5kdc[611](info): closing down fd 11

为什么 nfs kerberized 仅适用于 nfs3？我试过禁用firewalld和selinux：同样的事情。

nfs kerberos
Martin Hope
MountainX
Asked: 2018-01-30 20:31:51 +0800 CST
  • 0

到目前为止，我看到的每个有效 Kerberos 领域名称的示例都是“example.com”形式的。我读过的所有页面都没有给出实际的命名规则。

命名规则是什么？

必须使用 TLD 或点加扩展名来命名 Kerberos 领域吗？

或者，一个 Kerberos 领域可以用一个单词命名而没有任何点加扩展名吗？

kerberos
Martin Hope
Kevin
Asked: 2018-01-16 11:08:30 +0800 CST
  • 4

为了简短起见，我最近建立了一个 RHEL 7 服务器并将其注册到 FreeIPA。所有其他注册的服务器都可以仅使用主机名就可以毫无问题地相互 SSH，使用 gssapi-with-mic 进行身份验证，但这似乎配置错​​误，并回退到密码身份验证。具体来说，它似乎是在尝试使用短主机名与远程服务器的 FQDN，除非我明确 ssh 到 FQDN。

如果我使用 FQDN SSH，即

ssh remote-hostname.domain.com

一切正常。如果我不这样做，即

ssh remote-hostname

系统提示我输入密码。启用 ssh 调试会提供以下内容：

debug3: authmethod_is_enabled gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
Server host/[email protected] not found in Kerberos database

nslookup 正确地给出了服务器的 FQDN：

[kevin@local-hostname ~]$ nslookup remote-hostname
Server:     x.x.x.x
Address:    x.x.x.x#53

Name:   remote-hostname.domain.com
Address: x.x.x.x

本地服务器的域似乎设置正确：

[kevin@local-hostname ~]$ hostname
local-hostname
[kevin@local-hostname ~]$ hostname -f
local-hostname.domain.com

我有点难为从这里去哪里。有人能告诉我为什么 sshing 到远程主机名可能不起作用吗？不幸的是，我是 Kerberos 的新手，除了验证新服务器上的 /etc/krb5.conf 文件是否与其他工作服务器上的文件匹配之外，我真的不知道去哪里找。

ssh kerberos