Я настроил SFTP-сервер на CentOS следующим образом:этот документ. Я намерен запретить вход в консоль для новых пользователей ( user1
, user2
), которые принадлежат к sftpusers
группе, но по-прежнему могут входить в свои соответствующие sftp
папки.
Также я хочу использовать те же ключи, которые использует пользователь CentOS (который может войти в консоль sftp
без проблем). Для этого я скопировал .ssh
папку из пользователя CentOS в user1
и user2
домашние папки, изменив владельца на пользователей и 700
для .ssh
папки и 600
для authorized_keys
файла.
Тем не менее, я продолжаю получать сообщение Server refused our key
. Ключ, используемый пользователем CentOS, является главным ключом на всех серверах, поэтому я хочу повторно использовать этот ключ для новых пользователей.
Как мне добиться такой конфигурации?
ОБНОВЛЯТЬ
После генерации ключей для каждого пользователя оба пользователя могут получить удаленный доступ к серверу с помощью своих закрытых ключей, но когда я активирую следующую конфигурацию в /etc/ssh/sshd_config
разрешениях с помощью команды, они отказываются sftp
.
Конфигурация SSHD
Match Group sftpusers #Or you could replace Group with User and specify a different configuration for each user
X11Forwarding no
AllowAgentForwarding no
AllowTcpForwarding no
ChrootDirectory /path/to/shared_folder/%u # %h the path to upload the files
ForceCommand internal-sftp
Сообщение от shell
packet_write_wait: Connection to IPSERVER port 22: Broken pipe
Couldn't read packet: Connection reset by peer
решение1
Обновление вводит проблему, отличную от исходного вопроса. Похоже, исходная проблема больше не является проблемой. Я занимаюсь обновлением.
Theруководствочитает:
ChrootDirectory
Указывает путь к каталогуchroot(2)
после аутентификации. При запуске сеансаsshd(8)
проверяет, что все компоненты пути являются каталогами, принадлежащими root, которые не доступны для записи никакому другому пользователю или группе.
Мои тесты показывают, что если это условие не выполняется, то Broken pipe
при попытке входа в систему с помощью sftp
.
В вашем случае имя пути /path/to/shared_folder/%u
. Примечание %u
(после расширения)такжекомпонент; поэтому он должен быть «принадлежащим root и не доступным для записи любым другим пользователем или группой». Вам следует исправить владельца и разрешения. Тогда, очевидно, пользователь не сможет писать в каталог. Какой бы путь вы ни использовали с ChrootDirectory
, пользователь не сможет писать в него (если только он не root). Другими словами, пользователь не сможет писать /
в chrooted-среде. Чтобы разрешить запись, вам нужен подкаталог. Есть несколько способов справиться с этим.
Использование домашних каталогов в общем chroot-каталоге.
В руководстве также указано:
После этого
chroot
рабочийsshd(8)
каталог меняется на домашний каталог пользователя.Я предполагаю, что домашние каталоги по умолчанию такие
/home/user1
, как/home/user2
и т. д. Это предполагает следующий сценарий:Настройте сервер на chroot
/path/to/shared_folder
(нет%u
):ChrootDirectory /path/to/shared_folder
Скопируйте туда соответствующую структуру каталогов (
/path/to/shared_folder/home/user1
и т. д.).- Удовлетворить условию для
path
,to
иshared_folder
. - Сделайте права собственности и разрешения
home
такими же, как для обычного/home
. - Создайте права собственности и разрешения для каталогов внутри,
home
как для каталогов в/home
.
При такой настройке
sftp
он будет автоматически помещатьсяuser1
после/path/to/shared_folder/home/user1
аутентификации, но они будут видеть это как/home/user1
из-заchroot
.Использование пользовательских каталогов в общем chroot-каталоге.
С помощью
ForceCommand internal-sftp
можно указать начальный каталог (internal-sftp
поддерживает тот же набор опций, что иsftp-server
). Так:ChrootDirectory /path/to/shared_folder ForceCommand internal-sftp -d /home/%u
чтобы убедиться, что
sftp
пользователи будут использовать/path/to/shared_folder/home/…
независимо от их формальных домашних каталогов в ОС. Или так:ChrootDirectory /path/to/shared_folder ForceCommand internal-sftp -d /%u
для упрощения путей и избавления от этого
home
в середине. Таким образом,user1
они будут видны/user1
после входа в систему с помощьюsftp
. В этом случаеshared_folder
должны напрямую содержать пользовательские папки (неhome
).Использование по крайней мере одного подкаталога в каталоге chroot, специфичного для пользователя.
Решения выше позволяют пользователям просматривать каталоги друг друга. Пользователь сможет к
chmod
своим файлам (sftp
поддерживаетchmod
) предоставлять или запрещать доступ.Вы использовали
%u
сChrootDirectory
, поэтому вы, скорее всего, хотите создать отдельные каталоги chroot. В таком случае сделайте то, что вы сделали:ChrootDirectory /path/to/shared_folder/%u
и установить владельца и разрешения для каждого компонента (включая то,
%u
во что он расширяется) для удовлетворения условия. Если речь не идет о доступе только для чтения, вам нужен по крайней мере один подкаталог, который будет доступен для записи пользователем. Несколько возможностей:- реплицирование пути к домашнему каталогу пользователя, как определено в ОС;
- форсирование
/home/%u
с помощьюForceCommand internal-sftp -d /home/%u
; - форсирование
/%u
с помощьюForceCommand internal-sftp -d /%u
; - используя фиксированное имя подкаталога, например
ForceCommand internal-sftp -d /files
.
В каждом случае вам необходимо подготовить структуру каталогов внутри
/path/to/shared_folder
. Например, если вы хотите принудительно выполнить/home/user1
,user1
соответствующий путь будет:/path/to/shared_folder/user1/home/user1
где
path
,to
,shared_folder
и (первый)user1
удовлетворяет условию,home
имитирует/home
и (второй)user1
доступен для записи пользователем.
Возможны более гибкие подходы. Например, вы можете иметь общий chroot-каталог для user1
и user2
, но другой для user3
.
Директория chroot распространена или нет, лично я бы сделал подкаталоги наименее неожиданным образом, так что любой пользователь окажется в каталоге, который он ожидает. После ввода pwd
они sftp
должны увидеть что-то вроде /home/user1
. Я нахожу другие возможности ( /user1
, /files
) несколько удивительными.