Я новичок в Linux.
Я работаю с сервером Redhat 5.5 и использую скрипт SFTP на основе Java, который позволит нескольким пользователям загружать текстовые файлы на сервер. Я не решил, будет ли у каждого пользователя отдельный каталог или я буду использовать соглашение об именовании, которое включает их идентификатор клиента.
Файлы включают некоторую личную информацию о настройках локальной сети, поэтому я предпочитаю использовать SFTP вместо FTP. Насколько я понимаю, SFTP зашифрован (Кроме того, у меня есть класс Java, настроенный на загрузку через SFTP, поэтому я предпочитаю не переключать протоколы, если только на то нет очень веской причины).
Прототип предназначен для системы, которая будет поддерживать большое количество клиентов, и идея постоянного добавления и удаления клиентов через командную строку кажется крайне непрактичной. (Опять же, я новичок/изучаю Linux и Redhat).
Каковы обычные соглашения о предоставлении нескольким пользователям разрешения на загрузку файлов по SFTP с уникальным именем пользователя и паролем для каждого?
решение1
Вы можете сделать это, настроив свой внешний sshd как chrooted sftpd (используйте для этого опцию sftpd-internal в sshd_config). Каждый пользователь может иметь свою собственную chroot-jail. В файле authorized_key ваших пользователей (не разрешайте пароли!) вы должны добавить к каждому открытому ключу необходимые префиксы, которые запретят shell-access. Ваш chroot также должен содержать только базовую настройку для sftp-access (никаких двоичных файлов, никаких библиотек, только /dev/null, /dev/zero, /dev/random и /dev/urandom - насколько я помню).
решение2
То, что вы описываете, возможно, но это, вероятно, не самая лучшая идея, особенно если вы, как вы говорите, новичок в Linux.
Как вы сказали, управление правами доступа к файлам и пользователями станет настоящим кошмаром, а для SFTP требуется SSH, который сам по себе может предоставлять всевозможные функции, такие как выполнение кода на удаленном сервере и загрузка файлов.
Этоявляетсяможно настроить сервер SFTP с минимальным уровнем безопасности, но в его настройке есть много подводных камней. В Интернете есть много вводящих в заблуждение советов о настройке пользователей SFTP-only с помощью SSHd. Короче говоря, этонетдостаточно просто изменить их оболочку входа на недействительную оболочку, вам также нужно беспокоиться об их способности удаленно выполнять команды в обход оболочки, и их способности читать потенциально чувствительные системные файлы за пределами их домашнего каталога, а также их способности использовать SSH-туннелирование для обхода брандмауэров. А также о любой другой функциональности, которую я, возможно, не вспомню навскидку.
И этоявляетсяможно обойти всю эту «необходимость создания пользователя для каждого клиента», либо проделав какое-нибудь темное колдовство с PAM, чтобы позволить SSH аутентифицироваться в какой-то другой базе данных пользователей, либо просто разделив одну учетную запись пользователя (чего должно быть достаточно, если вы заботитесь только о том, чтобы позволить пользователямзагрузитьфайлы).
Кроме того, вы собираетесь каким-то образом решить базовую проблему безопасности, которую SFTP имеет в вашем виде приложения со многими удаленными пользователями, которым нужно иметь возможность проверить, является ли удаленный сервер тем, за кого он себя выдает. Для SSH нет центров сертификации — метод, который SSH использует для защиты от атак типа «человек посередине», заключается в кэшировании отпечатка ключей сервера SSH серверов, к которым подключается клиент, и если ключ совпадает с ранее увиденным ключом, все хорошо. Однакоесли ключ неизвестен, поскольку это первый раз, когда клиент подключается, SSH требует, чтобы пользователь вручную проверил отпечаток. Неразумно ожидать, что ваши клиенты действительно сделают это, почти все просто нажмут «да», потому что они хотят продолжить свою жизнь. Вы можете распространять действительный отпечаток хоста с вашим приложением, но это кажется немного кошмарным.
Если вы все же решите использовать SFTP, несмотря на описанные потенциальные проблемы, я бы рекомендовал изучитьршшограничить пользователей только SFTP. Кроме того, вы должны держать всех ваших пользователей SFTP в chroot jail, где они не смогут вмешиваться в работу сервера или получать доступ к каким-либо системным файлам. (Даже в этом случае злоумышленник может перечислить пользователей вашей системы...) И вам также нужно убедиться, что sshd настроен на предотвращение туннелирования SSH от ваших пользователей SFTP.
...
Вместо того, чтобы разбираться с такого рода беспорядком, я бы предложил рассмотреть другой протокол для загрузки ваших файлов, который кажется намного более подходящим для вашего варианта использования - почему бы не рассмотреть загрузку файлов с использованием HTTPS? Вам понадобится какой-то серверный CGI-скрипт или Java-сервлет или что-то еще, чтобы получать файлы и делать с ними что-то полезное и выполнять аутентификацию. Серверный скрипт мог бы позаботиться о сохранении файлов в удобном месте. Что касается проблемы на стороне клиента, загрузка файла через HTTPS - это настолько распространенное желание, что я был бы удивлен, если бы не было какого-то готового класса API, который вы могли бы просто использовать для выполнения такой загрузки файлов.
Конечно, это означает, что вам придется написать какой-то серверный CGI-скрипт, чтобы справиться с вашей проблемой, но я подозреваю, что вы в любом случае захотите как-то программно обрабатывать входящие файлы. На самом деле это упрощает задачу, поскольку код будет вызываться каждый раз при появлении нового файла.