☰

sftp 設定で ssh 公開鍵を共有する

tag-icon • tag-icon ssh centos sftp public-key
sftp 設定で ssh 公開鍵を共有する

CentOS上でSFTPサーバーを以下のように設定しました。このドキュメント私の意図は、グループに属しているが、それぞれのフォルダにログインできる新しいユーザー ( user1、 )のコンソール ログインを禁止することです。user2sftpuserssftp

また、CentOS ユーザーが使用しているのと同じキー (コンソールに問題なくログインできるsftp) を使用したいと思います。そのためには、フォルダーを CentOS ユーザーからホーム フォルダーにコピーし、.sshフォルダーの所有権をユーザーに変更し、ファイルの所有権も変更しました。user1user2700.ssh600authorized_keys

それでも、メッセージが表示され続けますServer refused our key。CentOS ユーザーが使用するキーは、すべてのサーバーのマスター キーのようなもので、そのため、新しいユーザーに対してそのキーを再利用したいと考えています。

この構成を実現するにはどうすればよいですか?

アップデート

各ユーザーのキーを生成すると、両方のユーザーが自分の秘密キーを使用してリモートでサーバーにアクセスできるようになりますが、コマンドを使用して次の構成を有効にすると、/etc/ssh/sshd_config権限が拒否されますsftp。

SSHD設定

Match Group sftpusers #Or you could replace Group with User and specify a different configuration for each user
X11Forwarding no
AllowAgentForwarding no
AllowTcpForwarding no
ChrootDirectory /path/to/shared_folder/%u # %h the path to upload the files
ForceCommand internal-sftp

シェルからのメッセージ

packet_write_wait: Connection to IPSERVER port 22: Broken pipe
Couldn't read packet: Connection reset by peer

答え1

アップデートにより、元の質問とは異なる問題が発生します。元の問題はもう問題ではないようです。アップデートに対処しています。

のマニュアル読みます:

ChrootDirectory
認証後にディレクトリのパス名を指定しますchroot(2)。セッションの起動時に、sshd(8)パス名のすべてのコンポーネントがルート所有のディレクトリであり、他のユーザーまたはグループによって書き込み可能ではないことを確認します。

Broken pipe私のテストでは、この条件が満たされていない場合、でログインしようとすると が発生することがわかりましたsftp。

あなたの場合、パス名は です/path/to/shared_folder/%u。注%u（展開後）はまたコンポーネントであるため、「root が所有し、他のユーザーやグループが書き込みできない」状態にする必要があります。所有権と権限を修正する必要があります。そうすると、当然、ユーザーはディレクトリに書き込むことができなくなります。 でどのパス名を使用してもChrootDirectory、ユーザーはそれに書き込むことができません (ユーザーが root でない限り)。言い換えると、ユーザーは chroot 環境では書き込むことができません/。書き込みを許可するには、サブディレクトリが必要です。これに対処する方法はいくつかあります。

  • 共通の chroot ディレクトリでホーム ディレクトリを使用する。

    マニュアルには次のようにも記載されています。

    の後chroot、sshd(8)作業ディレクトリをユーザーのホームディレクトリに変更します。

    /home/user1ホーム ディレクトリは、デフォルトでは などであると想定します/home/user2。これは、次のシナリオを示唆しています。

    1. サーバーを chroot に設定します/path/to/shared_folder(no %u):

      ChrootDirectory /path/to/shared_folder

    2. 関連するディレクトリ構造をそこに複製します（/path/to/shared_folder/home/user1など）。

    3. path、toおよびの条件を満たしますshared_folder。
    4. の所有権と権限をhome通常のものと同じにします/home。
    5. 内部のディレクトリの所有権と権限を、home内のディレクトリと同じにします/home。

    この設定では、認証後にsftp自動的user1に配置されますが、によるもの/path/to/shared_folder/home/user1として表示されます。/home/user1chroot

  • 共通 chroot ディレクトリでカスタム ディレクトリを使用する。

    ForceCommand internal-sftp開始ディレクトリを指定することができます（はinternal-sftp、sftp-server）。 このような：

    ChrootDirectory /path/to/shared_folder
ForceCommand internal-sftp -d /home/%u

    sftpユーザーが/path/to/shared_folder/home/…OS 内の正式なホーム ディレクトリに関係なく使用できるようにします。または、次のようになります。

    ChrootDirectory /path/to/shared_folder
ForceCommand internal-sftp -d /%u

    homeパスを簡素化し、途中でこれを削除します。 この方法では、 でログインした後に にuser1あることがわかります。 この場合は、ユーザー フォルダー ( ではない) を直接含める必要があります。/user1sftpshared_folderhome

  • ユーザー固有の chroot ディレクトリ内の少なくとも 1 つのサブディレクトリを使用します。

    chmod上記のソリューションにより、ユーザーは互いのディレクトリを参照できます。ユーザーは自分のファイル (sftpサポートchmod) へのアクセスを許可または拒否できます。

    %uを使用したChrootDirectory場合、別の chroot ディレクトリを作成する必要がある可能性が高くなります。そのような場合は、次の操作を実行してください。

    ChrootDirectory /path/to/shared_folder/%u

    そして、条件を満たすように、すべてのコンポーネント（%u展開先も含む）の所有権と権限を設定します。読み取り専用アクセスでない限り、ユーザーが書き込み可能なサブディレクトリが少なくとも 1 つ必要です。可能性はいくつかあります。

    • OS で定義されているユーザーのホーム ディレクトリへのパスを複製します。
    • 強制/home/%u的にForceCommand internal-sftp -d /home/%u;
    • 強制/%u的にForceCommand internal-sftp -d /%u;
    • 固定のサブディレクトリ名を使用します (例: ) ForceCommand internal-sftp -d /files。

    いずれの場合も、 内のディレクトリ構造を準備する必要があります。たとえば、を/path/to/shared_folder強制する場合、関連するパスは次のようになります。/home/user1user1

    /path/to/shared_folder/user1/home/user1

    ここでpath、、、toおよびshared_folder（最初の）はuser1条件を満たし、homeをシミュレートし/home、（2 番目の）user1はユーザーが書き込み可能です。

より柔軟なアプローチも可能です。たとえば、user1とに共通の chroot ディレクトリを用意しuser2、 には別の chrootディレクトリを用意することができますuser3。

chroot ディレクトリが一般的かどうかは別として、個人的にはサブディレクトリをできるだけ意外性のない方法で作成し、どのユーザーも自分が予想しているディレクトリにたどり着けるようにします。 と入力すると、pwdのsftpように表示さ/home/user1れます。他の可能性 ( /user1、/files) はやや意外だと思います。

関連情報