回答:
両方sftp-serverとinternal-sftpのOpenSSHの一部です。sftp-serverスタンドアロンのバイナリです。internal-sftpは、別のプロセス(通常は)を実行する代わりsshdにsshd、組み込みのSFTPサーバーコードを使用するように指示する構成キーワードですsftp-server。
機能的な観点から見るsftp-serverとinternal-sftp、ほとんど同じです。それらは同じソースコードから構築されます。
主な利点internal-sftpは、ChrootDirectorydirectiveとともに使用する場合、サポートファイルを必要としないことです。
sshd_config(5)manページからの引用:
以下のためのSubsystemディレクティブ:
このコマンド
sftp-serverは、SFTPファイル転送サブシステムを実装しています。または、名前
internal-sftpはインプロセスSFTPサーバーを実装します。これによりChrootDirectory、クライアント上で異なるファイルシステムルートを強制するために使用する構成を簡素化できます。
以下のためのForceCommandディレクティブ:
のコマンドを指定する
internal-sftpと、サポートファイルを必要としないインプロセスSFTPサーバーを強制的に使用しChrootDirectoryます。
以下のためのChrootDirectoryディレクティブ:
に
ChrootDirectoryは、ユーザーのセッションをサポートするために必要なファイルとディレクトリが含まれている必要があります。インタラクティブセッションの場合、これは、典型的には、少なくともシェルを必要とshし、基本的な/dev等ノードnull、zero、stdin、stdout、stderr、およびttyデバイス。SFTPを使用したファイル転送セッションでは、インプロセスsftp-serverを使用する場合、環境の追加構成は必要ありません/dev/logが、一部のオペレーティングシステムでは、ロギングを使用するセッションでchrootディレクトリ内が必要になる場合があります(詳細sftp-serverを参照)。
別の利点internal-sftpはパフォーマンスです。新しいサブプロセスを実行する必要がないためです。
これinternal-sftpは、スタンドアロンsftp-serverバイナリよりもずっと後(2008年のOpenSSH 4.9p1?)に追加されましたが、現在はデフォルトです。
sftp-server新しいインストールに使用する理由はないと思います。
機能が同じであり、上記の利点さえあるsshdためinternal-sftp、に遭遇したときにを自動的に使用できるように思われるかもしれません。しかし、違いがあるエッジケースがあります。sftp-serverinternal-sftp
いくつかの例:
管理者は、特定のユーザーのログインを防ぐためにログインシェル構成に依存する場合があります。internal-sftpログインシェルが関与しなくなったため、これに切り替えると制限がバイパスされます。
使用してsftp-serverバイナリあなたは次のように、いくつかのハックを使用することができます(スタンドアロンのプロセスである)の下でSFTPを実行していますsudo。
SSH-1の場合(だれかがまだ使用している場合)、Subsystemディレクティブはまったく関係しません。SSH-1を使用するSFTPクライアントは、サーバーに実行するバイナリを明示的に指示します。したがって、レガシーSSH-1 SFTPクライアントのsftp-server名前はハードコーディングされています。
OpenSSHと一緒に使用できる代替SFTP実装が存在します。
authorized_keyを外部sftp-serverにロックできます。
command = "/ usr / libexec / openssh / sftp-server" ssh-rsa AAAA…== user@host.com
実行すると、ユーザーはsftpを実行できますが、scpまたはsshは実行できません。
$ sftp host:/ etc / group / tmp ホストに接続しています... / etc / groupを/ tmp / groupに取得する / etc / group 100%870 0.9KB / s 00:00
他のことをしようとするとハングするだけです:
$ scp host:/ etc / group / tmp シグナル2で殺されました。 $ sshホストの稼働時間 シグナル2で殺されました。
残念ながら、sshd_configが変更されない限り、キーをchrootにロックする簡単な方法はありません。これは、システム管理者の介入なしでユーザーができることは本当にクールです。
sshfs host:/home/user/.ssh ~/hackmeしなくても、後で気が変わった場合にすべての設定を編集してオープンアクセスに戻すことができることです。
ForceCommand internal-sftp同じことを達成する必要があります