web-dev-qa-db-ja.com

接続ユーザーの公開鍵に応じてchrootを使用したSFTP

Sshfsを介してさまざまなクライアントからバックアップを受け取るサーバー（DebianまたはFreeBSDを実行）を構築したいと思います。各クライアントは、独自のバックアップデータを読み書きできますが、他のクライアントのデータはできません。

私は次のアイデアを持っていました：各クライアントは公開鍵認証を介して[email protected]に接続します。ユーザーbackupには、次のような特別なauthorized_keysファイルがあります。

command="internal-sftp" chroot="/backup/client-1/data" ssh-rsa (key1)
command="internal-sftp" chroot="/backup/client-2/data" ssh-rsa (key2)
command="internal-sftp" chroot="/backup/client-3/data" ssh-rsa (key3)
etc...

これの利点は、クライアントごとに個別のユーザーを使用する必要がなく、スクリプトを使用して簡単にauthorized_keysファイルを自動生成できることです。

問題は1つだけです：chroot=... 動作しません。 OpenSSHのauthorized_keysファイルには、ChrootDirectoryに相当するものがないようです（これは/ etc/ssh/sshd_configでグローバルに、またはMatch Userブロックで機能します）。

OpenSSHを使用して私がやりたいことを達成するためのかなり簡単な方法はありますか？多分command=...ディレクティブは賢い方法で？または、私がやりたいことを実行できる他のSFTPサーバーはありますか？

[〜＃〜] edit [〜＃〜]：達成したいことをより明確にするために：複数のクライアントが自分のサーバーにファイルを保存できるようにしたい。各クライアントは、他のクライアントのファイルを見ることができません。また、サーバーに数十のユーザーアカウントを散らかしたくないので、クライアントがユーザーアカウントを共有しても、お互いのファイルにアクセスできない、簡単に管理できるソリューションが欲しいのですが。

linuxsshfreebsdsftpssh-keys
9
Xykon42

または、私がやりたいことを実行できる他のSFTPサーバーはありますか？

はい、あなたはproftpdを使うことができます

ユーザー環境を準備します。 ProFTPDでは、有効なシェルをユーザーに提供する必要はありません。

# useradd -m -d /vhosts/backup/user1/ -s /sbin/nologin user1
# passwd --lock user1
Locking password for user user1.
passwd: Success

# mkdir /vhosts/backup/user1/.sftp/
# touch /vhosts/backup/user1/.sftp/authorized_keys

# chown -R user1:user1 /vhosts/backup/user1/
# chmod -R 700 /vhosts/backup/user1/

SFTPAuthorizedUserKeysでOpenSSH公開鍵を使用するには、それらをRFC4716形式に変換する必要があります。 ssh-keygenツールでこれを行うことができます：

# ssh-keygen -e -f user1.public.key > /vhosts/backup/user1/.sftp/authorized_keys

ProFTPDのセットアップ

ServerName "ProFTPD Default Installation"
ServerType standalone
DefaultServer off

LoadModule mod_tls.c
LoadModule mod_sftp.c
LoadModule mod_rewrite.c

TLSProtocol TLSv1 TLSv1.1 TLSv1.2

# Disable default ftp server
Port 0

UseReverseDNS off
IdentLookups off

# Umask 022 is a good standard umask to prevent new dirs and files
# from being group and world writable.
Umask 022

# PersistentPasswd causes problems with NIS/LDAP.
PersistentPasswd off

MaxInstances 30

# Set the user and group under which the server will run.
User nobody
Group nobody

# Normally, we want files to be overwriteable.
AllowOverwrite                  on

TimesGMT off
SetEnv TZ :/etc/localtime

<VirtualHost sftp.example.net>
    ServerName "SFTP: Backup server."
    DefaultRoot ~
    Umask 002
    Port 2121

    RootRevoke on

    SFTPEngine on
    SFTPLog /var/log/proftpd/sftp.log

    SFTPHostKey /etc/ssh/ssh_Host_rsa_key
    SFTPHostKey /etc/ssh/ssh_Host_dsa_key
    SFTPDHParamFile /etc/pki/proftpd/dhparam_2048.pem
    SFTPAuthorizedUserKeys file:~/.sftp/authorized_keys

    SFTPCompression delayed
    SFTPAuthMethods publickey
</VirtualHost>

<Global>
    RequireValidShell off
    AllowOverwrite yes

    DenyFilter \*.*/

    <Limit SITE_CHMOD>
        DenyAll
    </Limit>
</Global>

LogFormat default "%h %l %u %t \"%r\" %s %b"
LogFormat auth    "%v [%P] %h %t \"%r\" %s"
ExtendedLog /var/log/proftpd/access.log read,write

DH（Diffie-Hellman）グループパラメータを作成します。

# openssl dhparam -out /etc/pki/proftpd/dhparam_2048.pem 2048

SFTPクライアントを構成します。 FileZillaを使用しました

FileZilla SFTP server settings

ProFPTDをデバッグモードで実行する場合

# proftpd -n -d 3

コンソールに次のようなものが表示されます

2016-02-21 22:12:48,275 sftp.example.net proftpd[50511]: using PCRE 7.8 2008-09-05
2016-02-21 22:12:48,279 sftp.example.net proftpd[50511]: mod_sftp/0.9.9: using OpenSSL 1.0.1e-fips 11 Feb 2013
2016-02-21 22:12:48,462 sftp.example.net proftpd[50511] sftp.example.net: set core resource limits for daemon
2016-02-21 22:12:48,462 sftp.example.net proftpd[50511] sftp.example.net: ProFTPD 1.3.5a (maint) (built Sun Feb 21 2016 21:22:00 UTC) standalone mode STARTUP
2016-02-21 22:12:59,780 sftp.example.net proftpd[50512] sftp.example.net (192.168.1.2[192.168.1.2]): mod_cap/1.1: adding CAP_SETUID and CAP_SETGID capabilities
2016-02-21 22:12:59,780 sftp.example.net proftpd[50512] sftp.example.net (192.168.1.2[192.168.1.2]): SSH2 session opened.
2016-02-21 22:12:59,863 sftp.example.net proftpd[50512] sftp.example.net (192.168.1.2[192.168.1.2]): Preparing to chroot to directory '/vhosts/backup/user1'
2016-02-21 22:12:59,863 sftp.example.net proftpd[50512] sftp.example.net (192.168.1.2[192.168.1.2]): Environment successfully chroot()ed
2016-02-21 22:12:59,863 sftp.example.net proftpd[50512] sftp.example.net (192.168.1.2[192.168.1.2]): USER user1: Login successful

/var/log/sftp.logの次の行

2016-02-21 22:12:48,735 mod_sftp/0.9.9[50309]: sending acceptable userauth methods: publickey
2016-02-21 22:12:48,735 mod_sftp/0.9.9[50309]: public key MD5 fingerprint: c2:2f:a3:93:59:5d:e4:38:99:4b:fd:b1:6e:fc:54:6c
2016-02-21 22:12:48,735 mod_sftp/0.9.9[50309]: sending publickey OK
2016-02-21 22:12:59,789 mod_sftp/0.9.9[50309]: public key MD5 fingerprint: c2:2f:a3:93:59:5d:e4:38:99:4b:fd:b1:6e:fc:54:6c
2016-02-21 22:12:59,790 mod_sftp/0.9.9[50309]: sending userauth success
2016-02-21 22:12:59,790 mod_sftp/0.9.9[50309]: user 'user1' authenticated via 'publickey' method

追伸.

承認済みキーを含むファイルの構成済みパス（SFTPAuthorizedUserKeys）は、％u変数を使用できます。これは、名前で補間されます認証されるユーザーの。この機能は、ユーザーが独自の承認済みキーを管理することを要求する（または許可する）のではなく、中央の場所にある承認済みキーのユーザーごとのファイルを持つことをサポートします。例えば：

SFTPAuthorizedUserKeys file:/etc/sftp/authorized_keys/%u

複数のクライアントが自分のサーバーにファイルを保存できるようにしたい。各クライアントは、他のクライアントのファイルを見ることができません。また、サーバーに数十のユーザーアカウントを散らかしたくないので、クライアントがユーザーアカウントを共有しても、お互いのファイルにアクセスできない、簡単に管理できるソリューションが欲しいのですが。

proFTPDでも可能です。初期設定を少し変更するだけです

<VirtualHost sftp.example.net>
    ...   
    SFTPAuthorizedUserKeys file:/etc/proftpd/sftp_authorized_keys
    AuthUserFile /etc/proftpd/sftp_users.passwd

    CreateHome on 0700 dirmode 0700 uid 99 gid 99

    RewriteHome on
    RewriteEngine on
    RewriteLog /var/log/proftpd/rewrite.log
    RewriteCondition %m REWRITE_HOME
    RewriteRule (.*) /vhosts/backup/%u
</VirtualHost>

そして、1つの仮想アカウントを作成します

# ftpasswd --passwd --file /etc/proftpd/sftp_users.passwd --sha512 --gid 99 --uid 99 --Shell /sbin/nologin --name user1 --home /vhosts/backup

それで全部です。追加のアカウントごとに必要なのは、彼の公開鍵を/ etc/proftpd/sftp_authorized_keysに追加することだけです。

注：ファイルの最後には改行が含まれている必要があります！それは重要です。

5
ALex_hha

chroot=...は機能しません。

いいえ、authorized_keysファイルの形式を説明しているsshdのマニュアルページには、そのようなものはありません。

Chrootをcommand=に入れると、sshd内の内部関数呼び出しの置換であるため、internal-sftpを使用できなくなります。

分離が必要な場合は、より多くのユーザーを設定することをお勧めします。次のように、厳密な分離が必要ない場合（例：異なる作業ディレクトリのみ）、internal-sftpへの引数を使用することもできます。

command="internal-sftp -d /backup/client-1/data" ssh-rsa (key1)

-Pのマニュアルページのように、sftp-serverオプションを使用してリクエストの量を制限することもできます。

6
Jakuje

その間、私は、少なくとも私のユースケースでもうまく機能する別の簡単な解決策を考え出しました。

すべてのクライアントは、同じユーザーアカウントを使用してサーバーに接続し、場合によっては同じキーを使用します（重要ではありません）。 OpenSSHは、次の構造を持つディレクトリにchrootします。

d--x--x---   dark-folder
drwxr-x---   |- verylongrandomfoldername1
drwxr-x---   |- verylongrandomfoldername2
drwxr-x---   `- ...

サーバーは、backupコマンドとともに、ファイルを入れるフォルダー名をクライアントに通知します。フォルダー名は64バイトのランダムな文字列であり、事実上推測することはできません。したがって、他のユーザーが「暗闇のどこかにいる」としても、すべてのクライアントは実際には独自のフォルダーにしかアクセスできません。

ダークフォルダーのd--x--x--モードでは、すべてのクライアントがフォルダー（およびその下のフォルダー）に入ることができますが、その内容を一覧表示したり、新しいエントリを作成したりすることはできません。

サブフォルダーはバックアップサーバープロセスによって作成され、クライアントとフォルダー間の接続は（特に）SQLiteデータベースに保存されます。

0
Xykon42