OpenSSH: разница между внутренним sftp и sftp-сервером

Почему есть два способа настройки SFTP с OpenSSH и когда использовать какой? Есть ли разница между ними?

Я имею в виду, что первый использует lib из OpenSSH, а второй говорит «использовать внутреннее», так что это тоже OpenSSH?

Subsystem sftp /usr/lib/openssh/sftp-server
Subsystem sftp internal-sftp

Оба sftp-serverи internal-sftpявляются частью OpenSSH. sftp-serverэто отдельный бинарный файл internal-sftpэто просто ключевое слово конфигурации, которое указывает sshdиспользовать встроенный код сервера SFTP sshdвместо запуска другого процесса (обычно sftp-server).

С функциональной точки зрения sftp-serverи internal-sftpпрактически идентичны. Они построены из одного и того же исходного кода.

Основным преимуществом internal-sftpявляется то, что он не требует поддержки файлов при использовании с ChrootDirectoryдирективой .

Цитаты из sshd_config(5)справочной страницы :

• Для 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-сервер, хотя /dev/logв некоторых операционных системах сеансы, использующие ведение журнала, могут потребоваться внутри каталога chroot ( sftp-serverподробности см. ).

Еще одним преимуществом internal-sftpявляется производительность, так как для этого не нужно запускать новый подпроцесс.

Он internal-sftpбыл добавлен намного позже (OpenSSH 4.9p1 в 2008 году?), Чем автономный sftp-serverбинарный файл, но сейчас он используется по умолчанию.

Я считаю, что нет причин использовать sftp-serverдля новых установок.

Может показаться, что его sshdможно автоматически использовать internal-sftp, когда он встречается sftp-server, так как функциональность идентична и internal-sftpимеет даже вышеуказанные преимущества. Но есть крайние случаи, когда есть различия.

Несколько примеров:

• Администратор может полагаться на конфигурацию оболочки входа, чтобы предотвратить вход определенных пользователей. Переключение на режим internal-sftpобойдет ограничение, так как оболочка входа больше не используется.

• Используя sftp-serverбинарный файл (будучи автономным процессом), вы можете использовать некоторые хаки, такие как запуск SFTPsudo .

• Для SSH-1 (если кто-то все еще его использует) Subsystemдиректива вообще не задействована. SFTP-клиент, использующий SSH-1, в явном виде сообщает серверу, какой двоичный файл должен выполнять сервер. Таким образом, устаревшие SFTP-клиенты SSH-1 имеют sftp-serverжестко запрограммированное имя.

Существуют альтернативные реализации SFTP, которые можно использовать вместе с OpenSSH:

• http://www.greenend.org.uk/rjk/sftpserver/
• https://github.com/mysecureshell/mysecureshell

Вы можете заблокировать авторизованный ключ к внешнему sftp-серверу.

command = "/ usr / libexec / openssh / sftp-server" ssh-rsa AAAA… == user@host.com

Когда вы это сделаете, ваш пользователь может sftp, но не может scp или ssh:

Хост $ sftp: / etc / group / tmp
Подключение к хосту ...
Извлечение / etc / group в / tmp / group
/ etc / group 100% 870 0,9 КБ / с 00:00

Попытка сделать что-нибудь еще будет просто зависать:

$ scp host: / etc / group / tmp
Убит по сигналу 2.

$ ssh host uptime
Убит по сигналу 2.

Увы, нет простого способа заблокировать ключ в chroot, если sshd_config не изменен. Это было бы здорово, если бы пользователь мог обходиться без вмешательства системного администратора.