web-dev-qa-db-ja.com

ChrootDirectoryとユーザーのホームディレクトリはどのように連携しますか？

CentOS 7でSFTPのみのユーザーを作成する必要があります。さまざまなソースからその方法を読みました。セットアップは、単一のフォルダーへのSFTPアクセスのみを持つ単一ユーザーのみをサポートする必要があります。

ユーザーのホームディレクトリが/home/userで、sshd_configの場合、%hとしてChrootDirectoryがあります。chrootの後、sshdがディレクトリを/home/userに変更するとします。

ChrootDirectory認証後にchroot（2）するディレクトリのパス名を指定します。パス名のすべてのコンポーネントは、他のユーザーまたはグループが書き込みできないルート所有のディレクトリでなければなりません。 chrootの後、sshd（8）は作業ディレクトリをユーザーのホームディレクトリに変更します。

これはどのように作動しますか？ sshdは/home/user/home/userにCDを送ろうとするので、確かに失敗します。

補足質問：このようなユーザーを、ユーザーの作成時に定義されたホームディレクトリでchrootするか、/home外でchrootするかについてのベストプラクティスはありますか。 /var/sftp/user？ /homeの外にchrootを作成する場合、ユーザーのホームディレクトリの目的は何ですか？ ~/.ssh/authorized_keysの読み取りにまだ使用されていますか？

sshdchroot
2
jamieburchell

ChrootDirectoryとして使用されるディレクトリに課される他の制限に注意する必要があります：パス名のすべてのコンポーネントは、誰も書き込みできないルート所有のディレクトリでなければなりません他のユーザーまたはグループ。ユーザーがchroot内の自分のホームディレクトリに書き込むことができる必要がある場合、ホームディレクトリはChrootDirectoryと同じであってはなりません。

歴史的メモ：

OpenSSHのchrootサポートは別のパッチとして始まり、メインのOpenSSHディストリビューションに統合された後でも、ChrootDirectoryとして使用されるディレクトリに課される正確な要件は、異なるOpenSSHバージョンで変更されています。以前のセットアップで発見されたセキュリティの脆弱性に対応して、新しいバージョンは通常、古いバージョンよりも厳しい要件を適用する傾向があります。

また、同じホームディレクトリパスをchrootの内部と外部の両方に適用できるという要件は明らかに最適とは言えず、一部のディストリビューションではパッチを適用して動作を変更しています。残念ながら、過去のそのようなパッチのすべてに、マニュアルページやその他の関連ドキュメントの更新が含まれているわけではありません。

しかし、記述された要件を満たすために、たとえば次のようにすることができます。

mkdir -p /jail/username/home

# First, the chroot directory:
chown root:root /jail/username
chmod 755 /jail/username

# Then, the user's home directory:
chown username: /jail/username/home
chmod 750 /jail/username/home
usermod -d /jail/username/home username

# And here's the magic:
cd /jail/username
ln -s . jail       # this would normally be a silly thing to do
ln -s . username   # but with chroot it can be useful

これで、ChrootDirectory /jail/%uを設定できます。

Chrootの外部で表示すると、ユーザーのホームディレクトリは/jail/username/homeになります。通常の命名規則から少し離れていますが、それ以外は特別なことは何もありません。

そして、chroot内では、同じホームディレクトリパスは確かに/jail/username/jail/username/home...を参照しますが、上記の2つのばかげたシンボリックリンクを見ましたか？それらを逆参照すると、/jail/username/././homeが得られ、最終的には/jail/username/homeとまったく同じになります。そして、同じパスがchrootの内部と外部の両方で同じ場所を指すようになります。

Chroot内のユーザーには、ホームディレクトリが/jail/username/home = /././home = /homeとして表示され、通常どおり使用できます。ホームディレクトリの1レベル上の/を見ることができますが、そこに書き込むことができるのはrootだけです。

これにより、syslogスタイルのロギングなども可能になります。ルートが所有するディレクトリ/jail/username/devを作成し、rsyslogに/dev/logスタイルのソケットを/jail/username/dev/logに作成するように指示できます。 ...そしてchrootされたユーザーはログメッセージを生成し、通常のsyslogサブシステムで処理させることができます。

これは、chroot環境を調整する唯一の方法ではありませんが、上記のスタイルのセットアップでは、ユーザーのホームディレクトリが重要である場合、chrootの外部のプロセスに対して、ユーザーのホームディレクトリを通常どおり（=シムリンクやその他の奇妙さなしに）可能な限り作成します。

代わりに、jailされたユーザーに対して最大限に無菌であるchrootが必要な場合は、代わりに次のようにすることができます。

mkdir -p /jail/username/username

# Prepare the chroot directory
chown root:root /jail /jail/username
chmod 755 /jail /jail/username

# Prepare the user's actual home directory
chown username: /jail/username/username
chmod 750 /jail/username/username

# Make it usable outside the chroot too
ln -s /jail/username/username /username

# And now it can be assigned to the user.
usermod -d /username username

もう一度、ChrootDirectory /jail/%uを設定します。

Chrootの外では、/usernameは/jail/username/usernameを指すシンボリックリンクになるため、ユーザーのホームディレクトリが有効になります。

Chrootされたプロセスの場合、/usernameは通常のディレクトリになり、ユーザーのホームディレクトリとして完全に使用できます。

はい、実際のパス名は少し反復的であり、シンボリックリンクはシステムのルートディレクトリを乱雑にしますが、chroot環境内には無関係なものはありません。

そして、chrootされたユーザーが必要とするonlyがSFTPである場合、 この質問に対する受け入れられた回答はさらに簡単な方法を説明します。

1
telcoM

Sshdは/home/user/home/userにcdしようとするため、確かに失敗します。

まあ、そのディレクトリが存在しない場合のみ。

SFTPだけが必要だとおっしゃいましたが、ChrootDirectoryのような機能を使用して、chroot環境にやや大きなツールセットを提供し、バイナリファイルとライブラリが必要になったり、複数のユーザーが同じchroot環境を使用したりする可能性があります。 。そのような場合は、/some/chroot/home/userを使用することをお勧めします。確かに、その場合ChrootDirectory %hはあまり役に立ちません。

少しばかげているかもしれませんが、/home/user/home/userを作成して、そこでユーザーに作業を任せることができます。

/homeの外にchrootを作成する場合、ユーザーのホームディレクトリの目的は何ですか？ ~/.ssh/authorized_keysの読み取りにまだ使用されていますか？

実際、それは非常に良い点です。 manページにはChrootDirectoryと書かれています：

ChrootDirectory
chroot（2）にディレクトリのパス名を指定します認証後。

したがって、chrootの外部からauthorized_keysを読み取ることを意味しているようです。

それは私が持っていた別の構成のアイデアを妨げます。ユーザーの実際のホームディレクトリを/に設定してChrootDirectory /home/%uに設定することを考えましたが、今のところ、これは良い考えではないようです。

0
ilkkachu