Рейтинг:0

OpenSSH - sshd_config - Разрешить sftp-chroot И обычный вход в систему ssh с тем же пользователем

флаг cn

Надеюсь, это не обман, но я не могу найти ответ на этот вопрос... Я нашел это, которое на первый взгляд кажется таким же, но очень старым, и единственный ответ в нем не отвечает на фактический вопрос: Установите пользователей как chroot для sftp, но разрешите пользователю входить в систему через SSH

Я успешно настроил рабочую среду ChrootDirectory через sftp для пользователей в группе 'sftp_users'. Он работает хорошо, все необходимые разрешения и тому подобное, ограничивая доступ только к sftp, и они могут rw в своих подкаталогах внутри ChrootDirectory. Это отлично подходит для непривилегированных пользователей, запрещающих доступ по ssh и разрешающих rw только внутри их подпапок в 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'), а также читать или писать в свою домашнюю папку, смонтированную привязкой в ​​'/sftp/test/home' . Это все работает. Но даже если его оболочка по-прежнему установлена ​​в /etc/passwd как /bin/bash, 'test' не может войти через ssh, если он добавлен в группу sftp_users. Удалите членство в этой группе, и он может делать и то, и другое, но тогда не Chrooted под sftp.

Пользователи, не входящие в группу 'sftp_users', по-прежнему могут входить в систему через ssh или sftp, но не получают доступ к Chroot через sftp.

Есть ли способ сопоставить, какой протокол используется, и/или, возможно, установить дополнительное совпадение для другой группы? Я ищу только chroot, когда они входят в систему через sftp. Этим пользователям подходит не-chroot через ssh.

Ниже приведен мой sshd_config:

Порт ХХХХ
#ListenAddress ::
#ListenAddress 0.0.0.0

Протокол 2

Ключ хоста /etc/ssh/ssh_host_rsa_key
Ключ хоста /etc/ssh/ssh_host_dsa_key
Ключ хоста /etc/ssh/ssh_host_ecdsa_key
Ключ хоста /etc/ssh/ssh_host_ed25519_key

АУТЕНТИФИКАЦИЯ SyslogFacility
ИНФОРМАЦИЯ об уровне журнала

ЛогинGraceTime 120
PermitRootЛогин нет
Строгие режимы да

PubkeyAuthentication да

Игнорировать хосты да
Аутентификация на основе хоста нет

PermitEmptyPasswords нет

ВызовОтветАутентификация нет

X11Переадресация да
X11DisplayOffset 10
PrintMod да
PrintLastLog да

ClientAliveCountMax 10
Клиентживинтервал 3600
TCPKeepAlive нет

#Баннер /etc/issue.net

AcceptEnv ЯЗЫК LC_*

Подсистема sftp /usr/lib/openssh/sftp-server -u 0027

ИспользоватьPAM да
Аутентификация по паролю да



Группа соответствия sftp_users
  ChrootDirectory /sftp/%u
  ForceCommand внутренний-sftp -u 0027
  X11Номер переадресации
  AllowTcpForwarding нет
  Аутентификация по паролю да
Рейтинг:1
флаг fr
anx

OpenSSH не поддерживает переопределение глобальных ключевых слов на основе отправленной команды. Вы должны различать некоторые (комбинацию) критерии, предлагаемые OpenSSH для Соответствовать утверждение.

Доступные критерии: Пользователь, Группа, Host, LocalAddress, LocalPort, RDomain и Address (где RDomain представляет rdomain(4), на котором было получено соединение)

-- мужчина 5 sshd_config

Распространенным выбором является предложение намеренно ограниченных услуг на альтернативных IP-адресах, доступных через альтернативные домены, такие как snapshot.backup.example и sftp.backup.пример.


Комментарии к связанный вопрос однако четко изложите проблему.

Если вы думаете, что вы хочу доступ по sftp для привилегированных пользователей, вы, вероятно, коверкаете разные роли в идентичные пользователи, и это создает риски для безопасности. Чаще всего проблемы аудита и разделения привилегий лучше решаются используя другого пользователя за то, что заставило вас задуматься о настройке параметров chroot даже для пользователей, которые этим не ограничены. Если есть две разные задачи, даже если они выполняются одним и тем же человек, и один из них более безопасен, если он преднамеренно ограничен, тогда во что бы то ни стало настройте нового системного пользователя (например, человек и человек-задача разделяют большинство ограничений и методов аутентификации и ограничивают только один из них в ssh).

jdmayfield avatar
флаг cn
Чтобы уточнить, если я настрою sshd для прослушивания двух портов, скажем, 22 и 2222, я могу установить разделы Match для порта 2222, которые могут быть специфичными для Chrooted sftp? У меня только один IP-адрес, поэтому в настоящее время это единственный вариант с тем же именем пользователя.
anx avatar
флаг fr
anx
У вас должно быть достаточно доступных IP-адресов, даже если вы в настоящее время используете только один. Если в вашем списке назначенных IP-адресов указано /56, я полагаю, что это будет написано *quadrillion* на английском языке.
anx avatar
флаг fr
anx
Независимо от того, выбрали ли вы IP-адреса или порты, позаботьтесь о том, чтобы случайно не снять ограничения, применяя их только к одному порту и/или адресу. Вы можете столкнуться с тем, что ваша конфигурация станет более сложной, если вы создадите отдельные группы для «разрешено здесь» и «разрешено там».
jdmayfield avatar
флаг cn
У меня есть один локальный общедоступный IP-адрес, выделенный для моего облачного сервера. Можно приобрести дополнительный Pub.IP, однако, если это будет разрешено, это, вероятно, будет дорого. Этот вариант использования (в целом) не учитывает удаленные IP-адреса; ему не нужно полагаться на адрес клиента.
jdmayfield avatar
флаг cn
Я провел несколько экспериментов с различными комбинациями портов сопоставления и групп пользователей. Вроде работает удобно и надежно. Тщательно протестировано. Группа 'sftp_users' может войти только на один порт, только через sftp и chroot. Пользователи, не входящие в эту группу, могут использовать ssh или sftp для одного порта (скажем, порта A), без chroot, или они могут использовать sftp для другого, чтобы получить chroot (скажем, порт B). У группы 'sftp_users' есть только один выбор: получить chroot (только порт B). Все это, похоже, работает по плану, за исключением того, что я надеялся, что смогу сопоставить доменные имена с одним и тем же IP. Спасибо за уточнение.
jdmayfield avatar
флаг cn
Комментарии к связанному вопросу не касались моего варианта использования и не давали ответа о том, как выполнить эту задачу. Очевидно, что пользователи в группе «sftp_users» должны быть заблокированы только для chroot sftp, без ssh. Предполагается, что пользователи, не входящие в эту группу, имеют привилегии и разрешены ssh, обычный sftp (без chroot) и chroot для удобства, а не для дополнительной безопасности. В противном случае я бы не задавал вопрос, так как существует множество очень простых примеров chrooting одной группы. Для этого есть несколько вариантов использования.

Ответить или комментировать

Большинство людей не понимают, что склонность к познанию нового открывает путь к обучению и улучшает межличностные связи. В исследованиях Элисон, например, хотя люди могли точно вспомнить, сколько вопросов было задано в их разговорах, они не чувствовали интуитивно связи между вопросами и симпатиями. В четырех исследованиях, в которых участники сами участвовали в разговорах или читали стенограммы чужих разговоров, люди, как правило, не осознавали, что задаваемый вопрос повлияет — или повлиял — на уровень дружбы между собеседниками.