OpenSSH: разница между internal-sftp и sftp-server

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

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

Я считаю, что нет причин использовать 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 - это перформанс, так как для него не нужно запускать новый подпроцесс.

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

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

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

• С помощью sftp-server бинарный (как отдельный процесс) вы можете использовать некоторые хаки, например запуск SFTP под sudo.

• Для 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

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

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

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

$ sftp host:/etc/group /tmp
Connecting to host...
Fetching /etc/group to /tmp/group
/etc/group                                    100%  870     0.9KB/s   00:00

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

$ scp host:/etc/group /tmp
Killed by signal 2.

$ ssh host uptime
Killed by signal 2.

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

Если все, что вы хотите сделать, это заблокировать учетную запись, чтобы использовать только SFTP, просто укажите для их учетной записи оболочку по умолчанию / sbin / nologin