web-dev-qa-db-ja.com

認証後にSFTPユーザーをchrootサブディレクトリに転送する

OpenSSHを使用してSFTPサーバーをセットアップしました。すべてが正常に機能し、作成したユーザーが接続できます。

認証後、ユーザーは/chroot、つまり書き込みが許可されていないディレクトリの中に直接いることがわかります。だから私は/subdirectoryを/chrootに入れました。彼らは（ このブログ投稿 に触発された）への書き込みアクセス権を持っています。

ただし、私が取り組んでいるプロジェクトの性質上、ユーザーは認証後に書き込みが許可されているフォルダーに直接アクセスする必要があります。それらを/chroot/subdirectoryに転送するのが最善の解決策かもしれませんが、それを実現する方法を説明するリソースは見つかりませんでした。

できますか？どうやって？

sshfile-permissionssftp
6
zerodot

[編集]はい、それは可能であると信じていますが、opensshではそうではないと信じています：

Opensshを使用してsftpをchrootする方法は次のとおりです。

sshd_configファイルで識別される特別なグループsftponlyにsftpユーザーを配置します。私はsftpユーザーにシェルがないことを確認し（したがって、sshでログインできない）、.%h環境変数を使用して、ChrootDirectoryを使用するホームディレクトリにちなんで名付けられたsftp chrootサブディレクトリにユーザーを強制します指令。 sshd_configによって解釈される他の環境変数は sshd_conf man page に次のように記載されています：

パス名には、接続ユーザーが認証されると実行時に展開される次のトークンが含まれる場合があります。%%はリテラル '％'に置き換えられ、％hは認証されるユーザーのホームディレクトリに置き換えられ、％uは置き換えられますそのユーザーのユーザー名。

OpenBSDでこれを実現するための私のメモのコピーを次に示します。別のシステムを使用する場合、.%h環境変数はもちろん異なる場合があります。

# 1. Create the sftp jail directories
# These directory permissions work with this /etc/ssh/sshd_config:
# drwxr-xr-x  4 root    wheel  512 May 14 16:20 /home/sftproot
# drwxr-xr-x  3 root  wheel  512 May 14 16:21 /home/sftproot/home
# drwxr-xr-x  3 root  wheel  512 May 14 16:37 /home/sftproot/home/User01
# drwxr-xr-x  3 User01  sftponly  512 May 14 16:39 /home/sftproot/home/User01/upload
# drwxr-xr-x  3 root  wheel  512 May 14 16:37 /home/sftproot/home/User02
# drwxr-xr-x  3 User02  sftponly  512 May 14 16:39 /home/sftproot/home/User02/upload

# 2. Make sure /etc/ssh/sshd_config jails /home/sftproot/.%h

# 3. Create a group whose members will only be allowed sftp access
# groupadd sftponly

# 4. Create User01 + User02 whom will only get sftp access
# useradd -s /sbin/nologin -m -G sftponly User01
# useradd -s /sbin/nologin -m -G sftponly User02

# 5. In /etc/ssh/sshd_config enable use of chroot(internal-sftp) then force chroot dirs per user:
# override default of no subsystems
# Subsystem     sftp    /usr/libexec/sftp-server
# Subsystem       sftp    internal-sftp
# Rules for sftponly members
# Match group sftponly
#         ChrootDirectory /home/sftproot/.%h
#         X11Forwarding no
#         AllowTcpForwarding no
#        ForceCommand internal-sftp

# [Comment] Make sure /etc/ssh/sshd_config jails /home/sftproot/.%h
# Which will translate .%h to /home/$username

# [Comment] The sftp users will not be able to log in outside of sftp (as they have no Shell).
# As they sftp in they will land in the /home/sftproot/home/Userxx directory which
# will be named "./" and where they have no write access.
# However the directory ./upload is read/writable.

[EDITパート2]ただし、 sshd_confのmanページ では、次のことも指定されています。

ChrootDirectory

認証後にchroot（2）するディレクトリのパス名を指定します。セッションの起動時に、sshd（8）は、パス名のすべてのコンポーネントがrootが所有するディレクトリであり、他のユーザーやグループが書き込みできないディレクトリであることを確認します。 chrootの後で、sshd（8）は作業ディレクトリをユーザーのホームディレクトリに変更します。

そのため、変数展開で指定された部分を含むchrootディレクトリパスは、sshdによって所有され、ルートのみが書き込み可能であることが期待され、テストされています。したがって、openssh sftp chrootedサービスのユーザーがホームディレクトリに書き込むことができるようにするには、書き込み可能なサブディレクトリが必要です。

ただし、これはすべてのsshサーバーの要件ではないと思います。 Tectia も使用していますが、ユーザーはそれぞれのルートディレクトリに書き込むことができます。ただし、Windowsが必要な場合にのみ実行するため、残念ながら対応する* nix構成を簡単にテストすることはできません。 Tectia sftp chrooting support page は、ユーザーのホームがUnix環境のrootによって所有される必要があることを明示的に指定していません。したがって、Tectiaではこれは必須ではありませんが、chrootされたユーザーのホームrootdirの所有権は実際のユーザーの所有権である可能性があると思います。

3
ErikE

ChrootDirectory/upload /％u

ForceCommand internal-sftp -dデータ

これにより、sftpが/ upload/UserXX/dataディレクトリに配置されます。データディレクトリは、UserXXによって所有され、読み取り/書き込み可能です。

3
user474056