it-swarm.com.de

"Mount-Fehler (126): Erforderlicher Schlüssel nicht verfügbar" bei CIFS und Kerberos

Meine Anwendung muss eine Isilon-Freigabe mit CIFS und Kerberos sicher mounten. Mein mount-Versuch gibt Folgendes zurück: Required key not available:

mount -t cifs //fileserver.example.com/client123/files/mnt/client123/files -o Benutzername = Kennwort, Kennwort = XXXXXX, Sek. = krb5

Antwort: 

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

Hier sind entsprechende Einträge von /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

Hintergrund & Konfiguration

Ich habe ein Keytab hinzugefügt: 

/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

Überprüft mit klist -kte

[[email protected]]# 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) 

Hier ist 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

Ticket-Cache:

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

Was könnte den Fehler "Erforderlicher Schlüssel nicht verfügbar" verursachen?

BEARBEITEN: Ich habe das Debuggen in CIFS aktiviert und versucht, die Freigabe erneut bereitzustellen. Hier ist diese Ausgabe:

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 [email protected]_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
10
a coder

"Required key not available" bedeutet, dass cifs.upcall - das vom Kernel als Antwort auf die Mountanforderung ausgeführt wird - kein Kerberos-Ticket für den CIFS-Server abrufen konnte und daraus den Schlüssel generiert, der für die Authentifizierung beim Server erforderlich ist (er würde in den Kernel-Schlüsselbund des Client-Thread). cifs.upcall protokolliert sich in daemon.debug; Überprüfen Sie diese Nachrichten zuerst. Normalerweise ist dies /var/log/daemon, aber Sie müssen möglicherweise Ihre Syslog-Konfiguration anpassen, um Meldungen auf Debug-Ebene aufzunehmen. Auf meinem System sehen diese so aus:

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
...

Normalerweise verwenden Sie einen Mount-Befehl wie folgt:

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

Der Parameter cruid teilt cifs.upcall mit, für welches Konto dieser Mount ausgeführt wird. Zuerst wird nach Kerberos-Berechtigungsnachweiscaches ("Caches") gesucht, die diesem Konto (/tmp/krb5cc_*) gehören, um zu sehen, ob dieses Konto angemeldet ist und über aktuelle Berechtigungsnachweise verfügt (z. B. ob es sich um eine Person handelt und sie kinit). Sie können dies im Protokoll oben sehen, wo verschiedene Caches betrachtet werden. Wenn dies fehlschlägt, versucht es, mit einem Keytab zu navigieren. Frühere Versionen verwenden lediglich die Standardtastatur des Systems, dh die Schlüssel des Client-Principals müssen dorthin gehen (normalerweise /etc/krb5.keytab). Spätere Versionen haben ein -K-Flag, mit dem Sie benutzerspezifische Keytabs bereitstellen können. Dies ist offensichtlich auf einem Mehrbenutzersystem besser möglich. Beachten Sie, dass Sie das Kennwort im Befehl mount nicht benötigen. Das Keytab liefert diese Informationen.

Zu prüfen ist, dass die Kerberos-Konfiguration auf dem Client den Erhalt eines CIFS-Tickets für den Server zulässt. Z.B.: 

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

Trotzdem gibt es viele Variablen. Beginnen Sie mit dem cifs.upcall-Debug-Protokoll und gehen wir von dort weiter.

(Beachten Sie, dass die erste Antwort verwirrt und falsch ist; Sie sollten sie ignorieren. Es ist nicht erforderlich, den Client-Host mit dem Realm zu verbinden, und der Host-Principal spielt hier keine Rolle.)

Vorausgesetzt, Sie haben den vollständigen Inhalt aus Ihrem krb5.keytab gepostet, scheint der Schlüssel des Hosts zu fehlen. Um eine erfolgreiche Authentifizierung für einen Benutzer zu erhalten, benötigt Ihr Server sowohl einen Benutzer als auch ein Service-Ticket. Am einfachsten wäre es, den Server über sssd/samba (dies würde Ihre Keytab mit auffüllen) mit der Domäne zu verbinden und den Benutzer dann derselben Keytab hinzuzufügen.

Es gibt jedoch viele Möglichkeiten, dies zu tun, aber Sie müssen sicherstellen, dass Ihre Keytab (oder Keytabs) beide Schlüssel haben, damit sie beide Tickets erhalten können.

0
Reinaldo Gomes