“Erreur de assembly (126): clé requirejse non disponible” avec CIFS et Kerberos

Mon application doit monter un partage Isilon en toute sécurité en utilisant CIFS et Kerberos. Ma tentative de mount retourne: La Required key not available :

mount -t cifs //fileserver.example.com/client123/files / mnt / client123 / files -o nom d’utilisateur = acoder, password = XXXXXX, sec = krb5

Réponse:

 mount error(126): Required key not available Refer to the mount.cifs(8) manual page (eg man mount.cifs)

Voici les entrées correspondantes de /var/log/messages

 Sep 16 16:33:49 clientbox kernel: CIFS VFS: Send error in SessSetup = -126 Sep 16 16:33:49 clientbox kernel: CIFS VFS: cifs_mount failed w/return code = -126

Contexte & Config

J’ai ajouté un keytab en utilisant:

 /usr/bin/ktutil addent -password -p [email protected] -k 1 -e rc4-hmac addent -password -p [email protected] -k 1 -e aes256-cts wkt /etc/krb5.keytab

Vérifié avec klist -kte :

 [acoder@clientbox]# klist -kte Keytab name: FILE:/etc/krb5.keytab KVNO Timestamp Principal ---- ----------------- -------------------------------------------------------- 1 09/16/15 16:24:32 [email protected] (arcfour-hmac) 1 09/16/15 16:25:46 [email protected] (aes256-cts-hmac-sha1-96)

Voici request-key.conf :

 #OP TYPE DESCRIPTION CALLOUT INFO PROGRAM ARG1 ARG2 ARG3 ... #====== ======= =============== =============== =============================== create user debug:* negate /bin/keyctl negate %k 30 %S create user debug:loop:* * |/bin/cat create user debug:* * /usr/share/keyutils/request-key-debug.sh %k %d %c %S negate * * * /bin/keyctl negate %k 30 %S create cifs.spnego * * /usr/sbin/cifs.upcall %k create dns_resolver * * /usr/sbin/cifs.upcall %k

Cache de tickets:

 # klist | grep "Ticket cache:" Ticket cache: FILE:/tmp/krb5cc_0

Quelle pourrait être à l’origine de l’erreur “Clé requirejse non disponible”?

EDIT: J’ai activé le débogage dans CIFS et j’ai tenté de remonter le partage. Voici ce qui sort:

 fs/cifs/cifsfs.c: Devname: //fileserver.example.com/client123/files flags: 0 fs/cifs/connect.c: prefix path /files fs/cifs/connect.c: Username: acoder fs/cifs/connect.c: file mode: 0x1ed dir mode: 0x1ed fs/cifs/connect.c: CIFS VFS: in cifs_mount as Xid: 8 with uid: 0 fs/cifs/connect.c: UNC: \\fileserver.example.com/client123/files ip: 1.2.3.4 fs/cifs/connect.c: Socket created fs/cifs/connect.c: sndbuf 19800 rcvbuf 87380 rcvtimeo 0x1b58 fs/cifs/connect.c: CIFS VFS: in cifs_get_smb_ses as Xid: 9 with uid: 0 fs/cifs/connect.c: Demultiplex PID: 22937 fs/cifs/connect.c: Existing smb sess not found fs/cifs/cifssmb.c: secFlags 0x9 fs/cifs/cifssmb.c: Kerberos only mechanism, enable extended security fs/cifs/transport.c: For smb_command 114 fs/cifs/transport.c: Sending smb: smb_len=78 fs/cifs/connect.c: RFC1002 header 0xbc fs/cifs/transport.c: cifs_sync_mid_result: cmd=114 mid=1 state=4 fs/cifs/cifssmb.c: Dialect: 2 fs/cifs/asn1.c: OID len = 7 oid = 0x1 0x2 0x348 0x1bb92 fs/cifs/asn1.c: OID len = 6 oid = 0x1 0x3 0x5 0x1 fs/cifs/asn1.c: OID len = 7 oid = 0x1 0x2 0x348 0xbb92 fs/cifs/asn1.c: OID len = 10 oid = 0x1 0x3 0x6 0x1 fs/cifs/asn1.c: Need to call asn1_octets_decode() function for not_defined_in_RFC4178@please_ignore fs/cifs/cifssmb.c: negprot rc 0 fs/cifs/connect.c: Security Mode: 0x3 Capabilities: 0x8000e2fc TimeAdjust: 0 fs/cifs/sess.c: sess setup type 4 fs/cifs/cifs_spnego.c: key description = ver=0x2;host=fileserver.example.com;ip4=1.2.3.4;sec=krb5;uid=0x0;creduid=0x0;user=acoder;pid=0xXXXXX fs/cifs/sess.c: ssetup freeing small buf ffff8804359b02701 CIFS VFS: Send error in SessSetup = -126 fs/cifs/connect.c: CIFS VFS: leaving cifs_get_smb_ses (xid = 9) rc = -126 fs/cifs/connect.c: CIFS VFS: leaving cifs_mount (xid = 8) rc = -126 CIFS VFS: cifs_mount failed w/return code = -126

"Required key not available" signifie que cifs.upcall – exécuté par le kernel en réponse à la demande de assembly – n’a pas pu obtenir de ticket Kerberos pour le serveur CIFS et à partir de cela générer la clé nécessaire à l’authentification sur le serveur ( aller dans le trousseau de kernel du thread client). cifs.upcall connecte à daemon.debug ; vérifiez d’abord ces messages. Il s’agit généralement du /var/log/daemon , mais vous devrez peut-être ajuster votre configuration syslog pour inclure des messages au niveau du débogage. Sur mon système, cela ressemble à ça:

 Aug 19 20:00:26 client.example.com cifs.upcall: [daemon.debug] key description: cifs.spnego;0;0;3f000000;ver=0x2;host=server.example.com;ip4=10.12.0.6;sec=krb5;uid=0x0;creduid=0x2cec;user=res;pid=0x1997 Aug 19 20:00:26 client.example.com cifs.upcall: [daemon.debug] ver=2 Aug 19 20:00:26 client.example.com cifs.upcall: [daemon.debug] host=server.example.com Aug 19 20:00:26 client.example.com cifs.upcall: [daemon.debug] ip=10.12.0.6 Aug 19 20:00:26 client.example.com cifs.upcall: [daemon.debug] sec=1 Aug 19 20:00:26 client.example.com cifs.upcall: [daemon.debug] uid=0 Aug 19 20:00:26 client.example.com cifs.upcall: [daemon.debug] creduid=11500 Aug 19 20:00:26 client.example.com cifs.upcall: [daemon.debug] user=res Aug 19 20:00:26 client.example.com cifs.upcall: [daemon.debug] pid=6551 Aug 19 20:00:26 client.example.com cifs.upcall: [daemon.debug] find_krb5_cc: considering /tmp/krb5cc_5601 Aug 19 20:00:26 client.example.com cifs.upcall: [daemon.debug] find_krb5_cc: /tmp/krb5cc_5601 is owned by 5601, not 11500 Aug 19 20:00:26 client.example.com cifs.upcall: [daemon.debug] find_krb5_cc: considering /tmp/krb5cc_5702 ...

Normalement, vous utiliseriez une commande de assembly comme ceci:

 $ sudo mount -t cifs -o user=acoder,cruid=acoder,sec=krb5 ...

Le paramètre cruid indique à cifs.upcall au nom de quel compte ce assembly se produit. Il recherchera d’abord les caches d’informations d’identification Kerberos (“ccaches”) appartenant à ce compte ( /tmp/krb5cc_* ), pour voir si ce compte est connecté et dispose des informations d’identification actuelles (s’il s’agit d’une personne et si kinit ) ; Vous pouvez voir cela en action dans le journal ci-dessus où il “considère” divers ccaches. Si cela échoue, il essaie de kinit avec un keytab. Les versions précédentes utilisent simplement le keytab par défaut du système, ce qui signifie que les clés du principal du client doivent y aller (généralement /etc/krb5.keytab ). Les versions ultérieures ont un indicateur -K vous pouvez utiliser pour déployer des keytabs par utilisateur pour cela, de toute évidence sur un système multi-utilisateurs. Notez que vous n’avez pas besoin du mot de passe dans la commande mount; le keytab fournit ces informations.

Une autre chose à vérifier est que la configuration Kerberos sur le client permet d’obtenir un ticket CIFS pour que le serveur réussisse. Par exemple:

 $ kinit [email protected] ... type your password $ klist ... see your TGT $ kvno cifs/[email protected] $ klist ... see CIFS ticket

De toute façon, il y a beaucoup de variables; Commencez par le cifs.upcall débogage cifs.upcall et partez de là.

(Notez que la première réponse est confuse et erronée; vous devez l’ignorer. Il n’est pas nécessaire de joindre l’hôte client au domaine, et son principal hôte n’est pas pertinent ici.)

En supposant que vous ayez publié l’intégralité du contenu de votre krb5.keytab , il semble qu’il manque la clé de l’hôte. Afin d’obtenir une authentification réussie pour le compte d’un utilisateur, votre serveur a besoin à la fois d’un utilisateur et d’un ticket de service. Le moyen le plus simple serait de joindre le serveur au domaine via sssd / samba (ce qui remplirait votre keytab, puis appendait l’utilisateur au même keytab).

Quoi qu’il en soit, il y a plusieurs façons de faire, mais vous devez vous assurer que votre keytab (ou keytabs) a les deux clés, de sorte qu’il puisse recevoir les deux tickets.