私は今日同じ問題に遭遇しました。 「zfs allow」コマンドを使用して、通常のユーザーに特定の操作を許可できることがわかりました:
root として、サーバー上で次の操作を行います:zfs allow your_username receive,create,mount storage/photos
その後、your_username を使用してサーバーに ssh できるようになり、zfs 権限を取得できるようになります。 .html
これはルート ログインを完全に削除するわけではありませんが、フル機能のログイン以上のものを保護します。
ローカル ユーザーの公開鍵 (通常は ~/.ssh/id_rsa.pub) をコピーして、SSH 信頼を設定します。 ) authorized_keys ファイル (~/.ssh/authorized_keys) に ) リモート ユーザーの場合。これにより、パスワード プロンプトが不要になり、SSH キーの総当たり攻撃が困難になるため、セキュリティが向上します。 sshd_config であることも確認したいでしょう。 PermitRootLogin without-password を持っています -- これにより、リモート ルート ログインが SSH キーのみに制限されます (正しいパスワードでも失敗します)。
ForceCommand を使用してセキュリティを追加できます。 zfs コマンドの実行のみを許可するように、authorized_keys ファイル内のディレクティブを使用してください。
@analog900 は正しい軌道に乗っています。
ルート ログインの必要性を回避するなど、セキュリティを強化するための鍵の 1 つは、ZFS の組み込みのアクセス許可構造を使用することと、バックアップ転送を逆の方法で構造化することです。 プッシュするのではなく、ネットワーク経由でバックアップします。 root アクセスなしでファイルシステムをバックアップできる機能は、ZFS ファイルシステムの主要な設計成果の 1 つです。
destination でジョブを実行します source からデータを取得します 、おそらく次のようなもの:
- ソースについて 権限のないユーザー アカウント
fooを作成します。zfs allowを使用します そのアカウントがスナップショットを作成して送信できるようにするには:
zfs allow foo mount,snapshot,send,hold storage/photos
- 目的地で マシン、非特権アカウント
barを作成します そのアカウントに、ファイルシステムを受信/作成/マウントする機能を付与します:
zfs allow bar mount,create,receive storage/photos
- 宛先で、ユーザー
barとして 、バックアップ ジョブ専用の ssh キーを作成します。その鍵の公開半分を.sshにインストールします ユーザーfooのディレクトリ ソース マシン上。これにより、ユーザーに[email protected]が与えられます[email protected]への安全な ssh ログイン アクセス アカウント。また、destinationの ~bar/.ssh/config ファイルを編集します。 正しい SSH キー ファイル名 (以前に作成したもの) とユーザー名が自動的に使用されるようにします。
Host source
Hostname FQDN.of.source.example.com
User foo
IdentityFile ~bar/.ssh/backup_key_id_rsa
[email protected]からバックアップ ジョブを実行します :
dt=$(date +%Y-%m-%d_%H-%M-%S)
ssh source "zfs snap storage/[email protected]_$dt"
ssh source "zfs send -R storage/[email protected]_$dt" | zfs receive storage/photos
この方法ではいいえが必要です root アクセスは一切許可しません。