Можно ли предоставить пользователям доступ по sftp без доступа к оболочке? Если да, то как это реализовано?


29

У меня есть массив пользователей, которым нужно просто загружать файлы на свои домашние каталоги. Я думаю, что sftp будет достаточно, но я не хочу, чтобы они входили через шелл. Так возможно ли это? Моя платформа - Centos 7, домашние каталоги пользователей хранятся, скажем, / personal / $ user

Я создал пользователя с этими настройками

useradd -m -d /personal/user1 -s /sbin/nologin

назначил пользователя passwd, затем, когда я использую sftp для входа в систему, он говорит, что не может подключиться.


scponly github.com/scponly/scponly/wiki chroot необязательно
user2497

Ответы:


11

Изменить ваш, /etc/ssh/sshd_configчтобы содержать:

Match User [SFTP user]
ForceCommand internal-sftp

Перезагрузка sshd. Если у вас есть несколько пользователей, поместите их всех в строку совпадения, разделенную запятыми, например:

Match User User1,User2,User3

Ключом к настройке sftpзапрета доступа к оболочке является ограничение пользователей с помощью этой ForceCommand опции.


Хорошо, я выполнил все шаги, но он не
вошел

2
@Sollosa Попробуй Match User [SFTP user] ForceCommand internal-sftpтолько, без рутирования.
Мартин Прикрыл

@MartinPrikryl это сработало, Мартин, спасибо, я только что удалил параметр chrootdirectory и альт
Sollosa

1
Кроме того, вы можете настроить chrootпользователей, чтобы они не могли перемещаться вверх и из вашей определенной «тюрьмы»
ivanivan

37

Мне нравится следующая настройка для управления доступом по SSH, которую я использую на работе для управления группой пользователей на небольшом парке серверов. Безопасность и простота управления занимает первое место в списке моих приоритетов.

Его основными функциями являются простое управление правами SSH через членство в группах Unix, строго определенные разрешения и безопасность по умолчанию.

Настройка

Установите программное обеспечение (необязательно, но полезно):

yum install members   # or apt install members

Добавить группы:

addgroup --system allowssh
addgroup --system sftponly

В /etc/ssh/sshd_config, убедитесь, что следующие настройки No:

PermitRootLogin no
PubkeyAuthentication no
PasswordAuthentication no

И в конце /etc/ssh/sshd_configдобавьте эти две строфы:

Match Group allowssh
    PubkeyAuthentication yes

Match Group sftponly
    ChrootDirectory %h
    X11Forwarding no
    AllowTcpForwarding no
    ForceCommand internal-sftp

(не забудьте перезапустить SSH после редактирования файла)

объяснение

Итак, что же все это делает?

  • Это всегда отключает root-логины, в качестве дополнительной меры безопасности.
  • Он всегда отключает логины на основе паролей (слабые пароли представляют большой риск для серверов, работающих под управлением sshd).
  • Это позволяет (pubkey) вход в систему только для пользователей в allowsshгруппе.
  • Пользователи в sftponlyгруппе не могут получить оболочку через SSH, только SFTP.

Управление тем, у кого есть доступ, просто выполняется путем управления членством в группе (эти изменения вступают в силу немедленно, перезапуск SSH не требуется):

# adduser marcelm allowssh
# members allowssh
marcelm
# deluser marcelm allowssh
# members allowssh
#

Обратите внимание, что ваши пользователи sftp должны быть членами как sftponly(чтобы гарантировать, что они не получат оболочку), так и из allowssh(чтобы разрешить вход в систему в первую очередь).

Дальнейшая информация

  1. Обратите внимание, что эта конфигурация не позволяет входить по паролю ; все учетные записи должны использовать аутентификацию с открытым ключом. Это, вероятно, самая большая победа в области безопасности, которую вы можете получить с помощью SSH, поэтому я считаю, что это стоит усилий, даже если вы должны начать сейчас.

    Если вы действительно этого не хотите, то добавьте PasswordAuthentication yesв Match Group allowsshстрофу. Это позволит пользователям использовать как pubkey, так и пароль allowssh.

  2. Эта конфигурация ограничивает любого sftponlyпользователя их домашним каталогом. Если вы не хотите этого, удалите ChrootDirectory %hдирективу.

    Если вы хотите, чтобы chroot работал, важно, чтобы домашний каталог пользователя (и любой каталог над ним) находился в собственности группы, root:rootа не на ее запись. Это нормально, если подкаталоги домашнего каталога принадлежат пользователю и / или доступны для записи.

    Да, домашний каталог пользователя должен быть корневым и недоступным для записи пользователю. К сожалению, есть веские причины для этого ограничения. В зависимости от вашей ситуации, ChrootDirectory /homeможет быть хорошей альтернативой.

  3. Установка оболочки для sftponlyпользователей не /sbin/nologinявляется ни необходимой, ни вредной для этого решения, потому что SSH ForceCommand internal-sftpпереопределяет оболочку пользователя.

    Использование /sbin/nologinможет быть полезно, чтобы остановить вход в систему другими способами (физическая консоль, samba и т. Д.).

  4. Эта настройка не разрешает прямой rootвход через SSH; это формирует дополнительный уровень безопасности. Если вы действительно действительно нужны прямые логины корня, изменить PermitRootLoginдирективу. Подумайте о том, чтобы установить его на forced-commands-only, prohibit-passwordи (в крайнем случае) yes.

  5. Для получения бонусных баллов обратите внимание на ограничение того, кто может suполучить root-права; добавить системную группу с именем wheelи добавить / включить auth required pam_wheel.soв /etc/pam.d/su.


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

1
Это действительно хороший ответ с дополнительными советами по безопасности, но я волнуюсь за тех пользователей, чьи системы используют логины паролей, корневые логины и т. Д. Конечно, это нехорошо, но, возможно, перенесут изменения, связанные с общим улучшением безопасности, в свои собственный раздел, чтобы был доступен ответ на вопрос с минимальными изменениями?
Джош Рамбут

1
@JoshRumbut Я не хотел переписывать ответ для ваших (очень правильных) замечаний, отчасти потому, что он действительно просто показывает My Way ™, а отчасти в надежде, что это может быть своего рода каноническая настройка SSH по умолчанию для SSH пример, который многие люди находят полезным. В качестве компромисса я постарался прояснить, что логин root и пароль не будут работать, и я включил инструкции, как их снова включить :)
marcelm

1
Хороший ответ, но, по-моему, самые большие недостатки других ответов не учитывали аспекты безопасности, в основном chroot. +1
Руи Ф Рибейро

1
Chroot не будет работать для общего% h. Удивительно, но от вас требуется chown root:rootиchmod og-w
kubanczyk

1

просто измените их оболочку по умолчанию на / sbin / nologin. Предполагая большинство разновидностей Linux:

# usermod -s /sbin/nologin username

Я пробовал, но пользователь не может войти через sftp, я не знаю почему. Я использую Centos, кстати.
Соллоза

@Sollosa Возможно, либо проблема с правами доступа в вашем sftp chroot, либо sshd_config. Вы должны обновить свой вопрос, включив в него права доступа к каталогу chroot и свой sshd_config с удаленной конфиденциальной информацией.
Кефка

Я считаю (хотя я не могу проверить это сейчас), что это позволяет SFTP, только если есть Subsystem sftp internal-sftp) (или, может быть ForceCommand internal-sftp). Если есть общий Subsystem sftp /path/to/sftp-server, nologinпомешает даже SFTP.
Мартин Прикрыл

@MartinPrikryl Я неправильно понял их первоначальный неотредактированный вопрос, как спрашивать, как отключить доступ к оболочке для пользователей на сервере SFTP, работающем в противном случае. В то время я не спал минут десять, поэтому у меня не было такой ясной головы, как я мог себе представить. Хотя я не знал, что для работы sftp-сервера у пользователя должна быть действующая оболочка - это кажется потенциально опасным. Я только когда-либо использую internal-sftp просто по привычке, потому что я всегда так делал.
Кефка

Смотрите мой ответ на OpenSSH: Разница между внутренним-sftp и sftp-сервером (особенно раздел в конце)
Мартин Прикрыл

0

Вы можете использовать TFTP. все, что связано с ssh, потребует некоторой авторизации (key | pass).

Хотя tftp может быть защищен, возможно, стоит пересмотреть решение о предоставлении доступа к чему-либо без аутентификации.

http://manpages.ubuntu.com/manpages/bionic/man1/tftp.1.html


2
Я думаю, что OP хотел, чтобы пользователи (которые предположительно имели имена пользователей и пароли) не могли использовать обычный SSH-клиент для подключения к серверу и выполнять произвольные команды, но эти же пользователи могли загружать файлы через SFTP.
John_ReinstateMonica
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.