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

Чому існують два способи налаштування SFTP за допомогою OpenSSH і коли їх використовувати? Чи є різниця між ними?

Я маю на увазі, що перший використовує ліб від 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)сторінки 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-сервер, хоча сеанси, які використовують журнал, можуть вимагати /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двійковий (будучи самостійним процесом), ви можете використовувати деякі хаки, як, наприклад, запуск SFTP підsudo .

• Для SSH-1 (якщо хтось все ще використовує його) Subsystemдиректива взагалі не бере участь. Клієнт SFTP, що використовує SSH-1, чітко повідомляє серверу, який бінарний сервер повинен працювати. Тож застарілі клієнти SSH-1 SFTP мають 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
/ тощо / група 100% 870 0,9 КБ / с 00:00

Спроба зробити що-небудь інше просто зависне:

$ scp хост: / etc / group / tmp
Загинув за сигналом 2.

$ ssh бездротовий хост
Загинув за сигналом 2.

На жаль, не існує простого способу блокування ключа до chroot, якщо sshd_config не буде змінено. Це було б дуже здорово, щоб користувач міг обійтися без втручання системного менеджера.