"Erreur de montage (126): clé requise non disponible" avec CIFS et Kerberos
Mon application doit monter en toute sécurité un partage Isilon à l'aide de CIFS et Kerberos. Ma tentative mount renvoie: Required key not available:
mount -t cifs //fileserver.example.com/client123/files/mnt/client123/files -o nom d'utilisateur = acoder, mot de passe = XXXXXX, sec = krb5
Réponse:
mount error(126): Required key not available
Refer to the mount.cifs(8) manual page (e.g. 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 & Configuration
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 ticket:
# klist | grep "Ticket cache:"
Ticket cache: FILE:/tmp/krb5cc_0
Qu'est-ce qui pourrait causer l'erreur "Required key not available"?
EDIT: J'ai activé le débogage dans CIFS et tenté à nouveau de monter le partage. Voici cette sortie:
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 noyau en réponse à la demande de montage - n'a pas pu obtenir de ticket Kerberos pour le serveur CIFS et générer à partir de celui-ci la clé nécessaire pour l'authentification sur le serveur (il irait dans le trousseau de clés du noyau du fil client). cifs.upcall se connecte à daemon.debug; vérifiez d'abord ces messages. Il s’agit généralement de /var/log/daemon, mais vous devrez peut-être ajuster votre configuration syslog pour inclure les messages de niveau débogage. Sur mon système, ils ressemblent à ceci:
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 montage comme celle-ci:
$ Sudo mount -t cifs -o user=acoder,cruid=acoder,sec=krb5 ...
Le paramètre cruid indique cifs.upcall au nom du compte sur lequel ce montage a lieu. Il recherchera d’abord les caches des identifiants Kerberos («ccaches») appartenant à ce compte (/tmp/krb5cc_*) pour voir si ce compte est connecté et dispose des informations d’identification actuelles (par exemple, s’il s’agit d’une personne et qu’elle a rempli kinit); vous pouvez voir cela en action dans le journal ci-dessus, où il «considère» divers ccaches. Si cela échoue, il essaie d'associer un keytab. Les versions précédentes utilisaient simplement le clavier par défaut du système, ce qui signifie que les clés du client principal devaient y aller (généralement /etc/krb5.keytab). Les versions ultérieures ont un indicateur -K que vous pouvez utiliser pour déployer des keytabs par utilisateur à cette fin, ce qui est évidemment préférable sur un système multi-utilisateurs. Notez que vous n’avez pas besoin du mot de passe dans la commande mount; le keytab fournit cette information.
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
Quoi qu'il en soit, il y a beaucoup de variables. commencez par le journal de débogage cifs.upcall et poursuivons à partir 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 royaume et son principal hôte n'est pas pertinent ici.)
En supposant que vous ayez posté tout le contenu de votre krb5.keytab, il semble manquer la clé de l'hôte. Pour réussir l'authentification au nom 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 avec, puis ajouterait l'utilisateur au même keytab.
Quoi qu’il en soit, il existe de nombreuses façons de le faire, mais vous devez vous assurer que votre clavier (ou clés) a les deux clés, de sorte qu’il puisse obtenir les deux tickets.