
私はLinux初心者です。
私は Redhat 5.5 サーバーを使用しており、複数のユーザーがテキスト ファイルをサーバーにアップロードできるようにする Java ベースの SFTP スクリプトを使用しています。各ユーザーに個別のディレクトリを用意するか、顧客 ID を含む命名規則を使用するかは未定です。
ファイルには LAN 設定に関する個人情報が含まれているため、FTP ではなく SFTP を使用することを好みます。SFTP は暗号化されていると理解しています (また、Java クラスは SFTP 経由でアップロードするように構成されているため、非常に正当な理由がない限り、プロトコルを切り替えないようにしています)。
このプロトタイプは多数の顧客をサポートするシステム用であり、コマンド ラインからクライアントを継続的に追加および削除するという考えは非常に非現実的であると思われます。(繰り返しますが、私は Linux と Redhat の初心者であり、学習中です)。
複数のユーザーに、それぞれ固有のユーザー名とパスワードを使用して SFTP でファイルをアップロードする権限を与えるための通常の規則は何ですか。
答え1
外部 sshd を chroot された sftpd として設定することでこれを実現できます (このためには sshd_config の sftpd-internal オプションを使用します)。すべてのユーザーが独自の chroot-jail を持つことができます。ユーザーの authorized_key ファイル (パスワードは許可しないでください) で、各公開キーの前に、シェル アクセスを禁止する必要なプレフィックスを付ける必要があります。また、chroot には、sftp アクセスの基本設定のみを含める必要があります (バイナリやライブラリは含めず、/dev/null、/dev/zero、/dev/random、および /dev/urandom のみ - 私の記憶では)。
答え2
あなたが説明していることは可能ですが、特にあなたが言うように Linux を初めて使用する場合は、おそらく最良のアイデアではありません。
おっしゃるとおり、ファイルの権限とユーザーの管理は少々悪夢のような作業になります。また、SFTP には SSH が必要ですが、それ自体がリモート サーバー上でコードを実行したり、ファイルをダウンロードしたりするなど、あらゆる種類の機能を公開する可能性があります。
それはSFTPサーバーをある程度のセキュリティで構成することは可能ですが、その構成には多くの落とし穴があります。インターネットには、SSHdでSFTPのみのユーザーを構成することに関する誤解を招くアドバイスがたくさんあります。簡単に言うと、ないログイン シェルを無効なシェルに変更するだけでは十分ではありませんが、シェルをバイパスしてコマンドをリモートで実行する機能、ホーム ディレクトリ外にある機密性の高いシステム ファイルを読み取る機能、SSH トンネリングを使用してファイアウォールをバイパスする機能についても考慮する必要があります。また、すぐには思い出せないその他の機能についても考慮する必要があります。
そしてそれははPAMでSSHを他のユーザーデータベースに対して認証する魔法を使うか、または単に1つのユーザーアカウントを共有するか(ユーザーに許可を与えることだけを気にするのであれば、これで十分でしょう)、すべての顧客に対してユーザーを作成する必要があるという状況を回避することができます。アップロードファイル)。
さらに、リモートサーバーが本当にそのサーバーであるかどうかを確認する必要がある多くのリモートユーザーを対象とするアプリケーションで、SFTP が抱える基本的なセキュリティ問題を何とか解決することになります。SSH には証明機関がありません。中間者攻撃から保護するために SSH が使用する方法は、クライアントが接続するサーバーの SSH サーバーキーのフィンガープリントをキャッシュし、そのキーが以前に確認したキーと一致した場合、すべて正常です。ただし、キーが不明の場合、クライアントが初めて接続するため、SSH ではユーザーが手動でフィンガープリントを確認する必要があります。クライアントが実際にこれを行うことを期待するのは合理的ではありません。ほとんどの人は、そのまま作業を続けたいので「はい」をクリックするだけです。有効なホスト フィンガープリントをアプリケーションで配布できるかもしれませんが、それは少々悪夢のようです。
SFTPを導入することに決めた場合は、記載されている潜在的な問題にもかかわらず、調査することをお勧めします。rsshユーザーを SFTP のみに制限します。さらに、すべての SFTP ユーザーを chroot jail 内に保持する必要があります。これにより、ユーザーはサーバーの操作に干渉したり、システム ファイルにアクセスしたりできなくなります。(それでも、攻撃者がシステムのユーザーを列挙できる可能性があります...) また、sshd が SFTP ユーザーからの SSH トンネリングを防止するように構成されていることも確認する必要があります。
...
このような面倒な作業に煩わされるよりは、あなたのユースケースにもっと適していると思われる別のプロトコルを使ってファイルをアップロードすることを検討することをお勧めします。HTTPS を使ってファイルをアップロードしてみてはいかがでしょうか。ファイルを受け取って、それを使って何か役に立つことを行い、認証を行うには、何らかのサーバー側 CGI スクリプトや Java サーブレットなどが必要になります。サーバー側スクリプトは、ファイルを便利な場所に保存する作業を処理できます。クライアント側の問題については、HTTPS 経由でファイルをアップロードすることは非常に一般的なことなので、そのようなファイルのアップロードを簡単に実行できる、すぐに使える API クラスがなかったら驚きます。
もちろん、これは問題に対処するために実際にサーバー側の CGI スクリプトを記述する必要があることを意味しますが、いずれにしても何らかの方法で受信ファイルをプログラム的に処理したいと思われると思います。新しいファイルがあるたびにコードが呼び出されるため、実際にはこれが簡単になります。