NFS/Kerberos - 版の履歴

Kusanaginoturugi: add en page link.

2024-04-19T09:23:24Z

add en page link.

← 古い版		2024年4月19日 (金) 18:23時点における版
1行目:		1行目:
	[[Category:ネットワーク共有]]		[[Category:ネットワーク共有]]
			[[en:NFS/Kerberos]]
	Kerberos は NFS に利用可能な数少ないセキュリティメカニズムの一つです。Kerberos は強力なユーザー認証とデータ暗号化を提供し、NFSv4 を使用することでクライアントとサーバー間の UIDs/GIDs の一致が不要になります。		Kerberos は NFS に利用可能な数少ないセキュリティメカニズムの一つです。Kerberos は強力なユーザー認証とデータ暗号化を提供し、NFSv4 を使用することでクライアントとサーバー間の UIDs/GIDs の一致が不要になります。

Kusanaginoturugi: /* Client configuration */ 飜訳

2024-04-19T09:20:48Z

Client configuration: 飜訳

← 古い版		2024年4月19日 (金) 18:20時点における版
49行目:		49行目:
	* {{ic\|sys}} は従来の UID ベース（非 Kerberos）の NFS セキュリティモードです。		* {{ic\|sys}} は従来の UID ベース（非 Kerberos）の NFS セキュリティモードです。

			== クライアント設定 ==
	== Client configuration ==

			ユーザーに加えて、各 NFS クライアントは {{ic\|/etc/krb5.keytab}} に「マシン」Kerberos プリンシパルを持つべきであり、ユーザーの Kerberos チケットがまだ利用可能でない状況で使用されます。特に、ユーザーがログインする前や（autofs 経由でのマウントが行われる場合など）、ファイルシステムをブート時にマウントするために必要になります。一般的に、「root として」行われるすべての操作はマシンプリンシパルとして認証されます。
	In addition to users, each NFS client should have a ''machine'' Kerberos principal in {{ic\|/etc/krb5.keytab}}, which will be used in situations where user Kerberos tickets are not yet available – in particular, it will be needed to actually mount the filesystem at boot time before any users have logged in yet (or if mounting is done via autofs). More generally, all operations done "as root" will be authenticated as the machine principal.

			{{Tip\|マシンアイデンティティは NFSv4.0 や NFSv4.1 を使用する場合に一部の内部 NFS 操作にも必要ですが、NFSv4.2 ではもはや必須ではありません。}}
	{{Tip\|The machine identity is also mandatory for some internal NFS operations if NFSv4.0 or NFSv4.1 are used, although no longer mandatory in NFSv4.2.}}

			サーバーの場合と異なり、クライアントマシンは特に {{ic\|nfs/}} プリンシパルを必要としません。一般的な {{ic\|host/''the.fqdn''}} プリンシパルがあれば十分です（rpc.gssd マニュアルページで何を探すかを参照）。
	Unlike in the server case, the client machine does not need an {{ic\|nfs/}} principal specifically – it is enough to have the generic {{ic\|host/''the.fqdn''}} principal. (See the rpc.gssd manual page for what it looks for.)

	~~The client must have~~ {{ic\|rpc-gssd.service}} ~~active (i.e. the~~ {{ic\|rpc.gssd}} ~~daemon).~~		クライアントは {{ic\|rpc-gssd.service}} をアクティブにする必要があります（つまり、{{ic\|rpc.gssd}} デーモン）。

			ファイルシステムをマウントするときに使用されるオプションは、{{ic\|/etc/exports}} で使用されるオプションと非常に似ています。{{ic\|1=sec=}} オプションを使用して、1つ以上のフレーバーを指定できます。クライアントは自動的に提供された最も強力なモードを使用しますが、ダウングレード攻撃を防ぐために、例えば {{ic\|1=sec=krb5p}} を明示的に要求することを推奨します。
	Options used when mounting the filesystems are very similar to the options used in {{ic\|/etc/exports}}; you can specify one or more flavors using the {{ic\|1=sec=}} option. Although the client will automatically use the strongest mode offered, it is nevertheless recommended to explicitly require e.g. {{ic\|1=sec=krb5p}} to prevent downgrade attacks.

	~~Once the filesystem has been mounted,~~ root ~~may already access it (using the machine's~~ Kerberos ~~credentials), but~~ '''~~every~~''' ~~non-~~root ~~user needs their own~~ Kerberos ~~tickets to be present. This means either having the user manually run~~ {{ic\|kinit}} ~~for themselves, or setting up~~ {{Pkg\|pam-krb5}} ~~to acquire tickets during login (which only works for password-based logins), or using~~ {{ic\|gssproxy}} or {{man\|1\|k5start\|url=https://manned.org/k5start.1}} ~~(from~~ {{AUR\|kstart}}) ~~to acquire tickets from a~~ keytab ~~file.~~		ファイルシステムがマウントされた後、root はすでに（マシンの Kerberos 資格情報を使用して）アクセスできますが、'''すべての'''非 root ユーザーは自身の Kerberos チケットが必要です。これはユーザーが自分で {{ic\|kinit}} を手動で実行するか、ログイン中にチケットを取得する {{Pkg\|pam-krb5}} を設定するか（これはパスワードベースのログインでのみ機能します）、または {{ic\|gssproxy}} や {{man\|1\|k5start\|url=https://manned.org/k5start.1}}（{{AUR\|kstart}} から）を使用して keytab ファイルからチケットを取得するかのいずれかを意味します。

			{{Tip\|チケットは取得後数時間で期限切れになるため、k5start を設定してチケットを「更新」する必要があります。}}
	{{Tip\|You will likely need to set up k5start to ''renew'' tickets as they expire a few hours after being acquired.}}

Kusanaginoturugi: /* Server configuration */ 飜訳

2024-04-19T09:17:56Z

Server configuration: 飜訳

← 古い版		2024年4月19日 (金) 18:17時点における版
15行目:		15行目:
	}}		}}

	== ~~Server configuration~~ ==		== サーバーの設定 ==

	~~Each~~ NFS ~~server needs a Kerberos principal~~ ~~for~~ {{ic\|nfs/''server.fqdn''}} to be ~~created on the KDC, and its keys added to the server's~~ {{ic\|/etc/krb5.keytab}}.		各 NFS サーバーは、KDC 上に {{ic\|nfs/''server.fqdn''}} の Kerberos プリンシパルを作成し、その鍵をサーバーの {{ic\|/etc/krb5.keytab}} に追加する必要があります。

	{{Note\|		{{Note\|
29行目:		29行目:
	kadmin: ktadd nfs/fs.example.com		kadmin: ktadd nfs/fs.example.com

	{{ic\|gssproxy.service}} ~~must be~~ [[~~enable~~]]~~d and~~ [[~~start~~]]~~ed on the server.~~		サーバー上で {{ic\|gssproxy.service}} を[[有効化]]し[[開始]]する必要があります。

	{{Tip\|~~Earlier systems used~~ {{ic\|rpc.svcgssd}}, ~~but it is no longer present in modern~~ nfs-utils ~~and~~ ~~has been fully superseded by gssproxy.~~}}		{{Tip\|以前のシステムでは {{ic\|rpc.svcgssd}} を使用していましたが、現代の nfs-utils には存在せず、gssproxy に完全に置き換えられています。}}

			gssproxy は NFS サーバーのサポートで事前に設定されています（標準パッケージの一部として {{ic\|/etc/gssproxy/24-nfs-server.conf}} ファイルが含まれています）そして、NFS サービスの keytab を標準の場所に置く以外に調整する必要はありません。
	gssproxy comes pre-configured with NFS server support (the {{ic\|/etc/gssproxy/24-nfs-server.conf}} file is part of the standard package) and does not need any tweaking, other than placing the NFS service keytab in the standard location.

			{{ic\|/etc/exports}} では、{{ic\|1=sec=}} オプションで Kerberos 認証フレーバーを提供する必要があります：
	Your {{ic\|/etc/exports}} should offer the Kerberos authentication flavors in the {{ic\|1=sec=}} option:

	/home *(rw,sec=krb5p)		/home *(rw,sec=krb5p)
	/usr 10.147.0.0/16(rw,sec=krb5p:krb5i:krb5:sys) *(rw,sec=krb5p)		/usr 10.147.0.0/16(rw,sec=krb5p:krb5i:krb5:sys) *(rw,sec=krb5p)

			{{Note\|廃止された {{ic\|gss/krb5p(...)}} 構文を使用しないでください。まだ動作しますが、もはや使用すべきではありません。}}
	{{Note\|Do not use the obsolete {{ic\|gss/krb5p(...)}} syntax. It still works, but you should not be using it anymore.}}

			利用可能なフレーバーは以下の通りです：
	The available flavors are:

			* {{ic\|krb5p}} は「プライバシー」（Kerberos ベースの暗号化）を提供します。インターネット上で使用するには十分なセキュリティですが、LAN 上でのスループットが低下する可能性があるため、RPC-with-TLS 内で {{ic\|krb5}} を使用することを検討してください。
	* {{ic\|krb5p}} provides 'privacy' (Kerberos-based encryption). It is sufficiently secure to be used over Internet, but might provide poor throughput over a LAN – consider using {{ic\|krb5}} inside RPC-with-TLS instead.
			* {{ic\|krb5i}} は「完全性」（Kerberos ベースの MAC）を提供しますが、暗号化は提供しません。パケット改ざんから保護するため、静的データを提供する際に有用かもしれません。
	* {{ic\|krb5i}} provides 'integrity' (Kerberos-based MAC) but ''not'' encryption. It might be useful for serving static data as it still protects against packet tampering.
			* {{ic\|krb5}} は認証のみを提供し、データの完全性や暗号化はありません。RPC-over-TLS を {{ic\|1=xprtsec=}} を通じて有効化している、または Kerberos をそれ自体「安全な」LAN（例：WireGuard トンネルを通じて）上で運用している場合は良い選択ですが、公開ネットワーク上でクリアな状態で使用するのは避けてください。
	* {{ic\|krb5}} provides ''only'' authentication, without data integrity or encryption. It is a good choice if you have RPC-over-TLS enabled via {{ic\|1=xprtsec=}} ''or'' if Kerberos is being run over an otherwise "secure" LAN (e.g. over a WireGuard tunnel), but certainly not in the clear over public networks.
			* {{ic\|sys}} は従来の UID ベース（非 Kerberos）の NFS セキュリティモードです。
	* {{ic\|sys}} is the traditional UID-based (non-Kerberos) NFS security mode.

	== Client configuration ==		== Client configuration ==

Kusanaginoturugi: 一部飜訳

2024-04-19T09:12:56Z

一部飜訳

← 古い版		2024年4月19日 (金) 18:12時点における版
1行目:		1行目:
	[[Category:~~Network sharing~~]]		[[Category:ネットワーク共有]]
			Kerberos は NFS に利用可能な数少ないセキュリティメカニズムの一つです。Kerberos は強力なユーザー認証とデータ暗号化を提供し、NFSv4 を使用することでクライアントとサーバー間の UIDs/GIDs の一致が不要になります。
	Kerberos is one of the few security mechanisms available for NFS. It provides strong per-user authentication, strong data encryption, and (with NFSv4) removes the requirement for matching UIDs/GIDs between client and server.

			Kerberos には NFSv4 が推奨されます。NFSv3 で Kerberos を有効にすることは可能ですが、補助的な NFSv3 プロトコル（例えば「マウント」プロトコル）がセキュアでないため、100% のカバレッジは提供されません。また、NFSv3 には idmapping がないため、Kerberos の使用性が大幅に低下します。
	NFSv4 is recommended for Kerberos. Although it is possible to enable Kerberos in NFSv3, it will not provide 100% coverage as the auxiliary NFSv3 protocols (e.g. the "mount" protocol) remain insecure, and the lack of idmapping in NFSv3 severely reduces the usability of Kerberos as well.

	== ~~Prerequisites~~ ==		== 前提条件 ==

			Kerberos は '''KDC''' （Key Distribution Center）サービスがどこかで動作している必要があります。MIT Kerberos （{{Pkg\|krb5}}）に付属する {{ic\|krb5-kdc.service}} は、Active Directory や FreeIPA のような複雑さが必要ない小規模設定に適しています。2 番目のオプションは Heimdal で、一部の BSD や Arch 上の {{AUR\|heimdal}} で見つかります。
	Kerberos requires a '''KDC''' (Key Distribution Center) service to be running somewhere. The {{ic\|krb5-kdc.service}} that comes with MIT Kerberos ({{Pkg\|krb5}}) is a good option for small setups that do not warrant the complexity of Active Directory or FreeIPA. The second option is Heimdal, found on some BSDs and as {{AUR\|heimdal}} on Arch.

			Kerberos と共に NFSv4 の '''idmapping''' がとても重要になります。サーバーとクライアントはどちらも同じ idmapping ドメインを設定している必要があります：
	NFSv4 '''idmapping''' becomes much more important to have with Kerberos. Both the server and the clients should have the same idmapping domain configured:

	{{hc\|/etc/idmapd.conf\|2=		{{hc\|/etc/idmapd.conf\|2=

Kusanaginoturugi: 英語版より転載.

2024-04-19T09:10:10Z

英語版より転載.

新規ページ

[[Category:Network sharing]]
Kerberos is one of the few security mechanisms available for NFS. It provides strong per-user authentication, strong data encryption, and (with NFSv4) removes the requirement for matching UIDs/GIDs between client and server.

NFSv4 is recommended for Kerberos. Although it is possible to enable Kerberos in NFSv3, it will not provide 100% coverage as the auxiliary NFSv3 protocols (e.g. the "mount" protocol) remain insecure, and the lack of idmapping in NFSv3 severely reduces the usability of Kerberos as well.

== Prerequisites ==

Kerberos requires a '''KDC''' (Key Distribution Center) service to be running somewhere. The {{ic|krb5-kdc.service}} that comes with MIT Kerberos ({{Pkg|krb5}}) is a good option for small setups that do not warrant the complexity of Active Directory or FreeIPA. The second option is Heimdal, found on some BSDs and as {{AUR|heimdal}} on Arch.

NFSv4 '''idmapping''' becomes much more important to have with Kerberos. Both the server and the clients should have the same idmapping domain configured:

{{hc|/etc/idmapd.conf|2=
[General]
Domain = example.com
}}

== Server configuration ==

Each NFS server needs a Kerberos principal for {{ic|nfs/''server.fqdn''}} to be created on the KDC, and its keys added to the server's {{ic|/etc/krb5.keytab}}.

{{Note|
{{Expansion|Why?}}
It is recommended to ''also'' have the standard {{ic|host/}} principal there as well, for other purposes.
}}

fileserv# kadmin -p frob/admin
Password for frob/admin@EXAMPLE.COM: *********
kadmin: addprinc -nokey nfs/fs.example.com
kadmin: ktadd nfs/fs.example.com

{{ic|gssproxy.service}} must be [[enable]]d and [[start]]ed on the server.

{{Tip|Earlier systems used {{ic|rpc.svcgssd}}, but it is no longer present in modern nfs-utils and has been fully superseded by gssproxy.}}

gssproxy comes pre-configured with NFS server support (the {{ic|/etc/gssproxy/24-nfs-server.conf}} file is part of the standard package) and does not need any tweaking, other than placing the NFS service keytab in the standard location.

Your {{ic|/etc/exports}} should offer the Kerberos authentication flavors in the {{ic|1=sec=}} option:

/home *(rw,sec=krb5p)
/usr 10.147.0.0/16(rw,sec=krb5p:krb5i:krb5:sys) *(rw,sec=krb5p)

{{Note|Do not use the obsolete {{ic|gss/krb5p(...)}} syntax. It still works, but you should not be using it anymore.}}

The available flavors are:

* {{ic|krb5p}} provides 'privacy' (Kerberos-based encryption). It is sufficiently secure to be used over Internet, but might provide poor throughput over a LAN – consider using {{ic|krb5}} inside RPC-with-TLS instead.
* {{ic|krb5i}} provides 'integrity' (Kerberos-based MAC) but ''not'' encryption. It might be useful for serving static data as it still protects against packet tampering.
* {{ic|krb5}} provides ''only'' authentication, without data integrity or encryption. It is a good choice if you have RPC-over-TLS enabled via {{ic|1=xprtsec=}} ''or'' if Kerberos is being run over an otherwise "secure" LAN (e.g. over a WireGuard tunnel), but certainly not in the clear over public networks.
* {{ic|sys}} is the traditional UID-based (non-Kerberos) NFS security mode.

== Client configuration ==

In addition to users, each NFS client should have a ''machine'' Kerberos principal in {{ic|/etc/krb5.keytab}}, which will be used in situations where user Kerberos tickets are not yet available – in particular, it will be needed to actually mount the filesystem at boot time before any users have logged in yet (or if mounting is done via autofs). More generally, all operations done "as root" will be authenticated as the machine principal.

{{Tip|The machine identity is also mandatory for some internal NFS operations if NFSv4.0 or NFSv4.1 are used, although no longer mandatory in NFSv4.2.}}

Unlike in the server case, the client machine does not need an {{ic|nfs/}} principal specifically – it is enough to have the generic {{ic|host/''the.fqdn''}} principal. (See the rpc.gssd manual page for what it looks for.)

The client must have {{ic|rpc-gssd.service}} active (i.e. the {{ic|rpc.gssd}} daemon).

Options used when mounting the filesystems are very similar to the options used in {{ic|/etc/exports}}; you can specify one or more flavors using the {{ic|1=sec=}} option. Although the client will automatically use the strongest mode offered, it is nevertheless recommended to explicitly require e.g. {{ic|1=sec=krb5p}} to prevent downgrade attacks.

Once the filesystem has been mounted, root may already access it (using the machine's Kerberos credentials), but '''every''' non-root user needs their own Kerberos tickets to be present. This means either having the user manually run {{ic|kinit}} for themselves, or setting up {{Pkg|pam-krb5}} to acquire tickets during login (which only works for password-based logins), or using {{ic|gssproxy}} or {{man|1|k5start|url=https://manned.org/k5start.1}} (from {{AUR|kstart}}) to acquire tickets from a keytab file.

{{Tip|You will likely need to set up k5start to ''renew'' tickets as they expire a few hours after being acquired.}}