Chrooted пользовательские полномочия записи SFTP

Это должно работать на этот конкретный случай.

awk '/^[[:blank:]]*Linux1/ {print}'
10
31.07.2014, 17:39
6 ответов

У меня такие же настройки на нашем сервере. Мы используем ту же самую конфигурацию SSHD. Домашние каталоги пользователей принадлежат root'у, а внутри них находятся папки документы и public_html, принадлежащие соответствующим пользователям. Затем пользователи входят, используя SFTP, и записывают в эти папки (не напрямую в дом). Так как SSH для них не разрешен, то это отлично работает. Вы можете настроить, какие каталоги будут созданы для новых пользователей в /etc/skel/ (по крайней мере, в openSUSE, я не очень хорошо знаком с другими дистрибутивами).

Другой возможностью будет ACL (документация openSUSE) - он может добавить разрешение на запись для соответствующего пользователя в его домашний каталог.

2
27.01.2020, 20:02

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

4
27.01.2020, 20:02

Может быть...

ipcs | sed -n '
    s/[^ ]*  *//
    /^Messages/q
    /^Semaphores/cshift
    /  *bob .*/!d;s///
    / /!s/./ipcrm $1 &/p
'| sh -s -- shm \-s

Удаляет строки, которые не содержат последовательности bob в качестве третьего космоса разделенного поля или , которые не имеют во втором поле Сообщения/семафоры.

Вставляет последовательность ipcrm $1 < поле 2 > для оставшихся строк. Он прекращает ввод при совпадении Messages и заменяет Semaphores match w/ shift . Вывод

sed интерпретируется процессом оболочки с двумя позициями shm/-s . Таким образом, когда sed говорит shift , что оболочка прекращает выполнение команды ipcrm shm < field2 > и начинает выполнение -s в месте shms.

Я думаю, что если вы хотите чистого решения оболочки это близко:

set -f; IFS='
'; for l in $(ipcs); 
do IFS=\ ;set -- $l
case "$1:$2:${3#bob}" in
(-*:Sh*) a=shm;; 
(-*:Se*) a=-s;; 
(-*:Me*) break 2;;
(*:*:) ipcrm "$a" "$2";;
esac; done
-121--84725-

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

Механизм SysRq немного отличается: Клавиатура захватывает комбинацию и отправляет в ОС специальный клавишной код, как если бы была нажата одиночная кнопка. Linux kerenel ловит специальный код и обрабатывает его внутри, не пересылая входные данные в приложения более высокого уровня, такие как сервер X. Это подразумевает два последствия:

  1. Комбинация клавиш действительно зависит от клавиатуры. Клавиатура должна фиксировать все нажатия на клавишу самостоятельно, и только клавиатура «знает», где находится фактическая клавиша SysRq и какая комбинация запускает отправку специального клавишного кода. Итак:

    • SysRq не обязательно находится на одной кнопке с «Home» или «Print Screen», попробуйте найти его, обычно он помечен явно как «SysRq».
    • Используйте различные комбинации: Ctrl + Alt + SysRq + b или Ctrl + Alt + Fn + SysRq + b и т.д. (предупреждение, система перезагрузится после успешного завершения). На клавиатурах с клавишей Fn обычно необходимо нажать ее для перехода к фактической клавише SysRq , поэтому, вероятно, в комбинации будет использоваться клавиша Fn .
  2. Вы можете знать, когда получите правильную комбинацию. Запустите xev с терминала, фокусируйте окно xev и нажмите некоторые кнопки на клавиатуре, чтобы увидеть события, появляющиеся на терминале. При получении правильной комбинации НЕ следует получать событие, поскольку оно улавливается ядром и не доставляется на сервер X.

Также обратитесь к документации: https://www.kernel.org/doc/Documentation/sysrq.txt

-121--125736-

Недавно мы нашли решение, которое заключается в следующем:

/etc/ssh/sshd _ config:

...

Subsystem sftp internal-sftp

Match Group sftponly
    ChrootDirectory /home
    AllowTCPForwarding no
    X11Forwarding no
    ForceCommand internal-sftp

разрешения каталога:

root@server:~ # chown root:root /home
root@server:~ # chmod 111 /home
root@server:~ # chmod 700 /home/*

Теперь /home удовлетворяет требованиям для ChrootDirectory и можетно sftponly пользователи не смогут войти в систему, если их домашние каталоги настроены как обычно (/home/$ LOGNAME ): в среде chrouted их домашние каталоги находятся не внутри /home , а непосредственно под root (/).

Обходной путь 1

Задайте для домов ограниченных пользователей, как они выглядят в chroot:

root@server:~ # usermod -d /username username

предупреждение 1

Если любой из неограниченных пользователей или какой-либо сценарий администрирования использует расширение bash tilde, например ~ username , оно расширится до /username

Кроме того, администратор, создающий sftponly , должен помнить об использовании нестандартного дома. Разрешимо с помощью сценария. Которую администратор должен помнить, чтобы использовать.

обходной путь 2

Это альтернатива предыдущему, который мы в итоге использовали:

root@server:~ # ln -s . /home/home

То есть создать symlink внутри /home к собственному имени. Теперь под chroot /home/username точек в тот же каталог, что и без chroot. Для ограниченного пользователя, вошедшего в систему с помощью sftp, он будет отображаться как /username . Этот каталог доступен для записи его владельцу (пользователю с ограниченными правами). Пользователь с ограниченными правами не может перечислять родительские или домашние каталоги ни одного из братьев и сестер по имени.

Единственное, что особенно важно для пользователя sftponly , это его участие в группе sftponly . С нами было легче справиться, чем с обходным путем 1.

предостережения 2

  1. Пользователь с именем «home» не может иметь домашний каталог /home/home
  2. Необходимо быть осторожным со сценариями, которые пересекают иерархию /home и следуют по символьным ссылкам.
7
27.01.2020, 20:02

Debe crear la siguiente estructura de directorios:

/inicio/usuario

/home/user/home/user < -el directorio real al que tendrá acceso el usuario

Opcionalmente:

/home/user/.ssh/authorized _claves < -si desea autenticarse con una clave pública

0
27.01.2020, 20:02

В отношении раздела «прав доступа к каталогу» в ответе @artm (, который я только что протестировал )... Я нашел:

root@server:~ # chmod 111 /home <- Does not work

Это не позволяет sftp-подключению работать в Ubuntu с разрешениями только на выполнение для всего, т.е. 111.

Я обнаружил, что:

root@server:~ # chmod 555 /home

Работает при подключении к sftp с разрешениями на чтение и выполнение, т. е. 555. Не уверен, что Debian отличается от других вариантов, но это то, что работает в моих установках Ubuntu.

0
27.01.2020, 20:02

Когда вы создаете пользователя, вы должны установить права собственности с помощью chownдля каждого каталога для каждого пользователя.

Например:

sudo chown usertest:groupsftp /home/rootsftp/usertest
0
27.01.2020, 20:02

Теги

Похожие вопросы