Взаимодействие между подсистемой sftp и принудительной командой

Я отвечаю на результат тестирования на проникновение, связанным с одним из моих серверов приложений. Результат заключается в том, что закрытый ключ, встроенный в мой клиентский скрипт, может быть использован для открытия SFTP-сессии на сервере.

Я считал, что использование параметра "command=" в соответствующем открытом ключе исключает возможность использования SFTP с соответствующим закрытым ключом. Однако тестировщик безопасности смог использовать WinSCP с ключом, извлеченным из клиента, для доступа ко всему, к чему может получить доступ учетная запись службы, владеющая ключом.

Приложение использует следующую команду (соответствующим образом измененную) для передачи данных от клиента к серверу:

        (print ${FQDN} ; print ${Environment} ; cat ${OutFileXML}) | \
        ssh -Ti ${EmbeddedPrivateKey} \
                -o HostKeyAlias="${Alias}" \
                -o GlobalKnownHostsFile="${EmbeddedKnownHosts}"  \
                -o UserKnownHostsFile="${ClientSpecificKnownHosts}" \
                -o StrictHostKeyChecking="yes" \
                -o CheckHostIP="no" \
                -o NumberOfPasswordPrompts=0 \
                ${User}@${Host} 2>/dev/null

Принужденная команда настроена в открытом ключе с параметром “command=”. Я вставил следующий отладочный код в верхнюю часть скрипта, выполняемого этим параметром:

LOGFILE=/tmp/name-of-file.log
if [[ $SSH_ORIGINAL_COMMAND ]]; then
    print "Command: $SSH_ORIGINAL_COMMAND" >> $LOGFILE
else
    print "No SSH_ORIGINAL COMMAND set" >> $LOGFILE
fi

Затем я попробовал три вещи:

1. Я запустил приложение как есть.
2. Я запустил приложение с флагом, который удаляет “2>/dev/null” после команды ssh для целей отладки.
3. Я попытался войти под тем же именем пользователя с тем же закрытым ключом с ПК, на котором запущен WinSCP. Это оказалось успешным, хотя, по моему мнению, это не должно было произойти.

После этих шагов журнал показывает:

Command: 2>/dev/null
No SSH_ORIGINAL COMMAND set

Нет указаний на то, что принужденная команда вообще выполнялась, когда я подключался с WinSCP. Поэтому я не могу определить, следует ли принимать соединение и пытаться читать данные из стандартного ввода.

Я читал в нескольких местах, что SFTP-соединение должно выполнять принужденную команду перед запуском процесса sftp-server, но, похоже, это не так, поскольку каждый раз, когда соединение WinSCP активно, процесс /usr/libexec/openssh/sftp-server запущен.

Существует ли способ гарантировать, что конкретный пользователь/ключ не может быть использован для интерактивного SFTP без разрушения этого метода передачи файлов?

Если я правильно понимаю ваши опасения:

1. Убедитесь, что пользователь не может использовать закрытый ключ для получения SSH-доступа, что открывает еще больше возможностей. Обычно уловка заключается в том, чтобы установить оболочку для пользователя на /bin/false. Но этого достаточно, чтобы создать SSH-туннель, и, насколько я знаю, этого должно быть достаточно для SFTP.
2. Ограничьте то, что пользователь может делать с этим закрытым ключом, и уменьшите экспозицию файлов на стороне сервера. Вы говорите, что передача происходит от клиента к серверу. Тогда вам, вероятно, нужен односторонний канал связи, чтобы клиент мог загружать новые файлы, но не мог читать удаленные файлы с сервера. Вот одна актуальная тема, которую вы можете найти полезной Как настроить односторонний scp?. Один из подходов заключается в использовании ProFTPd, но OpenSSH также должен подойти. Отказ от ответственности: я не пробовал ни одно из этих предложений, но намерен сделать это в будущем.