私はまだ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に設定して、他のユーザーのホームディレクトリにあるファイルにアクセスします。
(自分の権限を/home
0711に制限すると、ホームディレクトリのリストは利用できなくなりますが、通常はコンテンツを読むすべてのユーザーのリストを見つけることができ、Linux上のすべてのユーザーは読む必要があるため、ls /home
あまり利点はありません。/etc/passwd
)。
ユーザーは残りのファイルシステム(バイナリなど)のほとんどを参照して読み取ることができますが、シェルを使用するにはほとんどのファイルシステムが必要なため、これは通常予想されます。
メールシステムは、ユーザーが互いの電子メールを読むのを防ぐために適切な所有権と権限を設定するように注意する必要があります。したがって、これは通常既に正しく行われています。
デフォルト設定で解決されない特定のセキュリティ問題はありますか?それ以外の場合は、単に維持して使用することは、ほとんどの一般的なユースケースに十分です。
答え2
ユーザーを自分のホームディレクトリに制限して、ユーザーがログインしたり、パスワードを変更したり、シェルを使用してファイルを管理したりできます。また、メール、Webなどを含むすべてのユーザーファイルをホームディレクトリに保存したいと思います。
理想的には、ユーザーが管理する必要があるファイル(メール、Webなど)にアクセスでき、他の場所からのアクセスを最小限に抑え、ユーザーが他のユーザーのファイルを閲覧または表示するのを絶対に防ぐことができることを願っています。
chroot
このための環境を必ず提供する必要はありません。/home
一般的な方法では、ユーザーアカウントを作成し、あるユーザーが別のユーザーのホームディレクトリにアクセスすることを制限できます。
chown root.root /home # Guarantee owner/group
chmod o=x /home # Search the directory but no read (listing) access
chmod go= /home/* # Prevent anyone else have access to users' home directories
システムデータベース(たとえば、/etc/passwd
および)/etc/group
はすべてのユーザーが読み取ることができるため、システムにアカウントを持つユーザーグループに関するいくつかの情報が漏洩します。
すべてのユーザーが共有する必要がある使用可能なディスク容量を1人のユーザーが満たすことができないように、ディスク使用量のクォータを作成して適用する必要があります。充填によってシステム自体が中断されないように、別々の/home
パーティションを設定することをお勧めします。/
/home