web-dev-qa-db-ja.com

Kerberos化されたNFS共有をマウントすると「資格情報キャッシュなし」エラーが発生するのはなぜですか？

ローカルネットワークに2つのシステム、nfsclient（CentOS 7）とnfsserver（CentOS 6）があります。これらの名前はIPアドレスに正しく解決され、Kerberosはそれらの間で機能します（nfsserverはKDCです）。 nfsserverにエクスポートされたKerberos化されたNFSv4共有があります。私の/ etc/exportsは次のとおりです：

/export                 *(rw,sync,fsid=0,no_subtree_check,sec=krb5p)                   
/export/home            *(rw,sync,no_subtree_check,no_root_squash,sec=krb5p)

私はnfsclientからこれらのエクスポートを見ることができます：

[root@nfsclient ~]# showmount -e nfsserver
Export list for nfsserver:
/export/home *
/export      *

/ etc/exportsのsec = krb5pオプションを削除すると、nfsclientから共有をマウントできます。

[root@nfsclient ~]# mount -t nfs4 nfsserver:/ /mnt/nfs

ただし、NFSがKerberos化されている場合は、うまくいきません。

[root@nfsclient ~]# mount -t nfs4 -o sec=krb5p nfsserver:/ /mnt/nfs
mount.nfs4: access denied by server while mounting nfsserver:/

これには、/ var/log/messagesに一連の繰り返しエラーメッセージが付随します。

Jun 22 19:55:02 oxo gssproxy: gssproxy[769]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure.  Minor code may provide more information, No credentials cache found
Jun 22 19:55:02 oxo gssproxy: gssproxy[769]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure.  Minor code may provide more information, No credentials cache found
Jun 22 19:55:02 oxo gssproxy: gssproxy[769]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure.  Minor code may provide more information, No credentials cache found
Jun 22 19:55:02 oxo gssproxy: gssproxy[769]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure.  Minor code may provide more information, No credentials cache found
Jun 22 19:55:02 oxo gssproxy: gssproxy[769]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure.  Minor code may provide more information, No credentials cache found
Jun 22 19:55:02 oxo gssproxy: gssproxy[769]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure.  Minor code may provide more information, No credentials cache found

サーバーのログには何も表示されません。クライアントでklistを実行すると、ルートに/ tmp/krb5cc_0に資格情報キャッシュがあることが示されるため、gss-proxyに問題があると思われます。

/etc/gssproxy/gssproxy.conf：

[gssproxy]

[service/HTTP]
  mechs = krb5
  cred_store = keytab:/etc/gssproxy/http.keytab
  cred_store = ccache:/var/lib/gssproxy/clients/krb5cc_%U
  euid = 48

[service/nfs-server]
  mechs = krb5
  socket = /run/gssproxy.sock
  cred_store = keytab:/etc/krb5.keytab
  trusted = yes
  kernel_nfsd = yes
  euid = 0

[service/nfs-client]
  mechs = krb5
  cred_store = keytab:/etc/krb5.keytab
  cred_store = ccache:FILE:/var/lib/gssproxy/clients/krb5cc_%U
  cred_store = client_keytab:/var/lib/gssproxy/clients/%U.keytab
  cred_usage = initiate
  allow_any_uid = yes
  trusted = yes
  euid = 0

そのため、gss-proxyは/ var/lib/gssproxy/clientsで認証情報キャッシュを探す必要があります。また、/ etc/krb5.keytab（プリンシパルnfs/nfsclientおよびHost/nfsclientのキーがある）からキーを取得しています。ただし、/ var/lib/gssproxy/clientsはnfsclientで常に空のようです。

ここで何か不足していますか？この共有のマウントで何が問題になっているのか、正確にはわかりません。

centosnfskerberos
3
L. Londau

キャッシュのパスを定義する際のデフォルトのファイル構成に問題があります。 /etc/gssproxy/gssproxy.confで、クライアントの次の構成を試してください。

[service/nfs-client]
  mechs = krb5
  cred_store = keytab:/etc/krb5.keytab
  cred_store = ccache:FILE:/tmp/krb5cc_%U
  cred_usage = initiate
  allow_any_uid = yes
  trusted = yes
  euid = 0
  debug = true
2
knuspykrackers

クライアントがドメインに参加していることを確認してください。

ipa-client-install --force-join

次に、チケットを持っていることを確認します

kinit admin

そしてkrb5.keytabを再確認してください

restorecon -v /etc/krb5.keytab

クライアントがキータブにあることを確認してください

kinit -k

Host/ < client > . < domain > @REALM

その後、sec=krb5pでマウントできるはずです

0
RayKeck