Надеюсь, это не дубликат, но не могу найти ответ на этот вопрос... Я нашел это, которое на первый взгляд кажется тем же самым, но оно очень старое, и единственный ответ в нем не отвечает на настоящий вопрос: Установить для пользователей chroot-окружение для sftp, но разрешить пользователям входить в SSH
Я успешно настроил рабочую среду ChrootDirectory через sftp для пользователей в группе 'sftp_users'. Она работает хорошо, все необходимые разрешения и т. д., ограничивая доступ только sftp, и они могут читать/читать в своих подкаталогах внутри ChrootDirectory. Это отлично подходит для непривилегированных пользователей, запрещая доступ по ssh и разрешая читать/читать только внутри своих подкаталогов внутри ChrootDirectory.
Я хотел бы иметь немного больше привилегированных пользователей, которые все еще могут использовать ssh в обычном режиме, однако при входе через sftp будут иметь среду ChrootDirectory. Это не проблема безопасности, так как они считаются привилегированными и obvi может перемещаться по файловой системе в ssh в рамках своих обычных прав пользователя. Проблема в том, что я не вижу способа сделать их Chroot, когда они входят через sftp, не предотвращая вход по ssh. Это больше для стандартизации и удобства, чем для чего-либо еще, поэтому, когда они подключаются через sftp, они просто попадают в свое местоположение Chrooted, как и пользователи только с sftp.
Я думал, что это сработает, если я оставлю их оболочку по умолчанию (не /bin/false или nologin). К сожалению, когда они находятся в группе sftp_only, это вообще не позволит им войти по ssh, только по sftp. Есть ли обходной путь для этого, кроме как иметь две отдельные учетные записи — одну добавленную в 'sftp_users', а другую — нет? Пока что все, что я смог найти, — это документация по ограничению sftp Chroot и одновременному запрету ssh, если они находятся в этой группе.
Пример пользователя — «test». «test» входит в группу sftp_users и, следовательно, может войти через sftp и быть Chrooted в указанную им папку («/sftp/test»), а также читать или писать в его домашнюю папку, смонтированную с помощью bind-mount в «/sftp/test/home». Все это работает. Но даже если его оболочка по-прежнему установлена в /etc/passwd на /bin/bash, «test» не может войти через ssh, если добавлен в группу sftp_users. Удалите членство в этой группе, и он сможет делать и то, и другое, но тогда не будет Chrooted в sftp.
Пользователи, не входящие в группу «sftp_users», по-прежнему могут входить в систему через ssh или sftp, но не имеют Chroot-доступа в sftp.
Есть ли способ Match, какой протокол используется, и/или, может быть, установить дополнительный Match для другой группы? Я ищу только chroot, когда они входят через sftp. Non-chroot через ssh подходит для этих пользователей.
Ниже приведен мой sshd_config:
Port XXXX
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
SyslogFacility AUTH
LogLevel INFO
LoginGraceTime 120
PermitRootLogin no
StrictModes yes
PubkeyAuthentication yes
IgnoreRhosts yes
HostbasedAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
X11Forwarding yes
X11DisplayOffset 10
PrintMotd yes
PrintLastLog yes
ClientAliveCountMax 10
ClientAliveInterval 3600
TCPKeepAlive no
#Banner /etc/issue.net
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server -u 0027
UsePAM yes
PasswordAuthentication yes
Match Group sftp_users
ChrootDirectory /sftp/%u
ForceCommand internal-sftp -u 0027
X11Forwarding no
AllowTcpForwarding no
PasswordAuthentication yes
решение1
OpenSSH не поддерживает переопределение глобальных ключевых слов на основе представленной команды. Вам необходимо различать некоторые (комбинации) критериев, которые OpenSSH предлагает для оператора Match
.
Доступные критерии: Пользователь, Группа, Хост, Локальный адрес, Локальный порт, RDomain и Адрес (где RDomain представляет собой rdomain(4), на котором было получено соединение).
-- man 5 sshd_config
Распространенным вариантом является предложение намеренно ограниченных услуг на альтернативных IP-адресах, доступных через альтернативные домены, такие как snapshot.backup.example
и sftp.backup.example
.
Комментарии по темесвязанный вопросОднако четко сформулируйте проблему.
Если вы думаете, что выхотетьsftp доступ chrooted для привилегированных пользователей, вы, вероятно, искажаете разныеролив идентичныепользователи, и это создает риски для безопасности.
Чаще всего проблемы аудита и разделения привилегий лучше решаются с помощьюиспользуя другого пользователядля того, что заставило вас задуматься о настройке chroot-настроек даже для пользователей, которые не ограничены этим. Если есть две разные задачи, даже если они выполняются одним и тем жечеловеки один из них более безопасен, если он намеренно ограничен, то любыми способами настройте нового системного пользователя (например, заведите пользователя person
и person-task
поделитесь большинством ограничений и методов аутентификации, а в ssh ограничьте только один из них).
решение2
Я также был сбит с толку этой проблемой, когда я настраивал chroot sftp для пользователей, которые не могли войти по ssh. Мой сценарий немного отличается, мне нужно предоставить ограниченную среду оболочки для пользователей, в то время как пользователям по-прежнему нужны sftp и scp для доступа к их домашнему каталогу для RW, а также назначенный публичный каталог, например /home/public для RDONLY.
Сначала я разработал оболочку jailed, я хотел, чтобы эта оболочка могла взаимодействовать с openssh internal-sftp для достижения моих требований. Затем я обнаружил, что это не удалось, потому что openssh не позволяет пользователям входить по ssh вместе с включенным chroot internal-sftp.
Поэтому мне пришлось модифицировать оболочку jailed для поддержки home jailed sftp и scp. Немного сложно, что я использовал системные вызовы ptrace для реализации jailed sftp. Если эта информация вам полезна, вы можете обратиться к https://github.com/diggerwoo/jsh.