私はまだLinuxに初めて触れています。複数のユーザーが使用するUbuntuメール/Webサーバーを構築しています。ユーザーを自分のホームディレクトリに制限して、ユーザーがログインしたり、パスワードを変更したり、シェルを使用してファイルを管理したりできます。また、メール、Webなどを含むすべてのユーザーファイルをホームディレクトリに保存したいと思います。
私が読んだすべての記事（例：SSH ユーザーが /home/%u のコンテンツのみを閲覧するように制限する方法chown）ユーザーディレクトリをroot所有にする必要があると述べました。まあ、それが共感のようです。
なぜですか？
フォローアップ
ユーザーが他のシステムユーティリティにアクセスできるようにしたいので、元のpasswd質問はもはや意味がないと思います。/home*他のディレクトリへのアクセスを制限するなど、特別なフォルダへの権限に集中することが正しいようです。
理想的には私はユーザーが管理する必要があるファイル（メール、Webなど）にアクセスでき、他の場所からのアクセスを最小限に抑え、ユーザーが他のユーザーのファイルを閲覧したり表示したりすることを絶対に防ぐことができることを願っています。
ベストアンサー1
withを使用するのがChrootDirectory合理的ですinternal-sftp。 with を使用すると、その構成ForceCommandに一致するユーザーがただSFTPプロトコルを使用してSSHを介してこのサーバーにアクセスする機能。
これはあなたが達成したいものと両立することはできません：
ユーザーを自分のホームディレクトリに制限してログインしたり、パスワードを変更したり、使用できるようにしたいと思います。シェル。
シェルを取得するにはSFTPだけでなくSSH全体が必要なので、おそらく望むものではありません。
ルート所有権に関しては、ChrootDirectoryこれは必ずしもホームディレクトリに関するものではなく、chroot環境の最上位に関するものです。ここでの問題は、ホームディレクトリをchrootのトップレベルとして使用することです。これは実際にChrootDirectory使用する方法ではなく、最も適切な方法でもありません。
より良いアプローチは、構成を使用してSFTP経由でchrootされたホームディレクトリを公開することです。
サブシステム SFTP 内部 SFTP
ユーザーブライアンマッチ
Chroot ディレクトリ/chroot/%u
ForceCommand 内部 SFTP
次に、root：rootが所有する各ユーザー（たとえば、user）のディレクトリをbrian作成します/chroot/brian（これはChrootDirectory正しい機能の制限であるため重要です）、次に内部でユーザーの/chroot/brianホームディレクトリを作成します/chroot/brian/home/brian。ホームディレクトリはユーザーが書くことができ、brianおそらくあなたが望むものです（ホームディレクトリは所有者が完全に管理できます）。
これがChrootDirectory機能すると、SFTPサーバーはchroot内のホームディレクトリが見つかるとそのディレクトリに変更されます。 SFTP経由でサーバーにアクセスするユーザーはディレクトリに移動できますが、..これらの../..ディレクトリはほとんど空であるため、興味深いコンテンツは表示されません。
バインドマウントを使用して、「実際の」ホームディレクトリをchroot内部ディレクトリに関連付けることができます。
$ sudo mkdir -p /chroot/brian/home/brian
$ mount --bind /home/brian /chroot/brian/home/brian
/etc/fstabサーバーが再起動するたびにインストールするようにこのインストールを構成できます。 SFTP を公開するすべてのユーザーに対してこれらのインストールが必要なため、これはかなりのメンテナンス負担となる可能性があります。
とにかくSFTPが必ずしも望むわけではないので、ChrootDirectory設定とは関係ないかもしれません。
公開したい場合シェル、技術的に各ユーザーに対してchrootを設定し、SSHを介してchrootに接続することができます。しかし：
この構成の設定は非常に複雑です。特に、いくつかの便利な操作を実行するには、シェルで通常は外部コマンドセット全体（たとえば、、
lsなどcp）が必要なため、chrootを完全に埋める必要があります。tar各ユーザーに対してchrootを設定する場合は、そのユーザーにこれらのバイナリ、ユーザーが依存するライブラリなどを入力する必要があります。また、バグやセキュリティの問題を解決するには、これらのバイナリを更新する必要があります。多くのことが必要です。そしておそらくもっと重要なことは：Aは
chroot非常に脆弱であり、制限なくアクセスできる場合（通常はシェルを使用して）削除する方法があります。 chrootのすべての脆弱性を閉じるのは簡単ではないため、この設定が多くのセキュリティ上の利点を提供するかどうかは不明です。
複雑さが追加され、セキュリティの面で小さな（存在しない可能性がある）利点があるため、SSHでシェルルートを変更する方法を考慮しないことをお勧めします。
したがって、問題は何を達成しようとしているのか、Linuxディストリビューションに付属のデフォルト設定はまだこれを達成していません。
通常、Unix 権限はユーザー間の適切なレベルのセキュリティと分離を達成するのに十分です。
デフォルトでは、ユーザーは他のユーザーのホームディレクトリにファイルを書き込むことはできません。
ユーザーをブロックできます検索そして読むホームディレクトリの権限を0700に設定して、他のユーザーのホームディレクトリにあるファイルにアクセスします。
（自分の権限を/home0711に制限すると、ホームディレクトリのリストは利用できなくなりますが、通常はコンテンツを読むすべてのユーザーのリストを見つけることができ、Linux上のすべてのユーザーは読む必要があるため、ls /homeあまり利点はありません。/etc/passwd）。
ユーザーは残りのファイルシステム（バイナリなど）のほとんどを参照して読み取ることができますが、シェルを使用するにはほとんどのファイルシステムが必要なため、これは通常予想されます。
メールシステムは、ユーザーが互いの電子メールを読むのを防ぐために適切な所有権と権限を設定するように注意する必要があります。したがって、これは通常既に正しく行われています。
デフォルト設定で解決されない特定のセキュリティ問題はありますか？それ以外の場合は、単に維持して使用することは、ほとんどの一般的なユースケースに十分です。