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