SSH пользователь с одним правом

chroot в эту директорию

На сервере {ip2} В /etc/ssh/sshd_config:

Match User backuser
    ChrootDirectory /mnt/backup
    ForceCommand internal-sftp
    AllowTcpForwarding no
    X11Forwarding no

Но удалить файл User сможет?

Помимо уже отвеченного на ваш вопрос, обращаю внимание на на такую фигню как «бэкап может и не случиться по разным причинам», но одна из них «что-то по дороге поломалось в момент перелива» и ломаться оно может день за днем по разным независящим от вас причинам, поэтому я предпочитаю переливать файло бэкапа с временным именем, в вашем варианте например «${dir2}/${daten}_Documents.tar.gz.tmp» и только после успеха ( обработать exit code) делаю ему mv ${daten}_Documents.tar.gz.tmp ${daten}_Documents.tar.gz
ЗЫ Ну и сам трансфер оборачиваю в цикл с несколькими попытками со слипом между ними, т.е. не случилось, подождали, начали заново.

Можно использовать скрипт в качестве login shell, но очень аккуратно:

• Юзер может переопределить некоторые переменные (см. man ssh_config), и тем самым обойти ограничения;
• В скрипте могут не определиться/развернуться переменные, что в итоге приведёт к повреждению или уничтожению данных в совершенно другом месте (требуется написать проверки на всё);
• Сам скрипт может быть подменён/модифицирован, в том числе для повышения прав (он должен быть 0555/-r-xr-xr-x, принадлежать root и находиться за пределами домашней директории целевого пользователя, где у него нет прав записи).

Возможно ещё какие-то детали, которые я сходу вспомнить не смог.

Но удалить файл User сможет?

Если юзер может что-то создать в директории, он может изменить и удалить что угодно в этой же директории. При условии что изменяемый/удаляемый файл принадлежит ему (даже если с флага снят w, он может его добавить, если файл принадлежит ему или группе, в которой он состоит).

При копировании файлов права перенесутся с оригинала, владельцем станет этот юзер и его primary group. То есть как минимум изменить/удалить только что скопированный по SFTP файл бэкапа он сможет.

Но удалить файл User сможет?

сможет. удаление файла это запись (в директории)

chroot не поможет

что бы он мог только писать в ${dir2}?

но не мог … что и зачем?

но не мог … что и зачем?

Удалить файл - Если кто-то 3-й получит доступ к ПК1 и скрипту не смог удалить бэкапы Документов.

Не получится без доп. действий на стороне сервера2, в рамках ssh

На сервере2 некий пользователь (root, например) должен совершить некие манипуляции с файлом

1. /mnt/backup принадлежит root, user2 имеет доступ к директории только для чтения

2. /mnt/backup/INrw для записи бэкапов по алгоритму anc, когда .tmp будет переименован в .tar.gz, файл будет перенесен по cron’u в /mnt/backup/ со сменой владельца и доступен user2 только для чтения. Если в /mnt/backup файл с таки именем существует, то к новому файлу добавить суфикс типа (#)

ssh все же шел, если нужен такой узкий функционал только файл записать поднимай http/webdav сервер

Если есть такие риски, имхо, лучше организовать наоборот - бэкап-хост с правом на запись а отдавать данные в ro.

Rsync в режиме демона вроде бы отдает ro по умолчанию, если ничего не путаю.

Пишите бэкапы на dvd/bd болванки

При доступе через ssh по ключу можно указать программу которая будет запущена вместо шелла.

Sticky bit на dir2 плюс скрипт-костыль, который меняет владельцев через inotify или даже просто через крон.

Если хочешь чтобы юзер мог создавать файлы, но не мог удалять, то варианта два:

1) ForceCommand на свою прогу или скрипт, которая сделает ровно то что нужно (создаст файл с правильным именем и запишет в него принятые байты), и ничего кроме этого, при этом принимать от юзера что-то кроме содержимого файла она не должна т.к. взломщик может передать туда не то что надо

2) запустить на бекап-сервере прогу или скрипт, который принимает подключения (на юникс-сокет или на обычный), сохраняет всё принятое из него в файл итд, а по ssh вообще запретить любые доступы к файлам или командам и разрешить только подключение к этому сокету

Гонка же получается. Можно не успеть поставить права когда файл уже удалят.

Ну, одним бекапом придётся пожертвовать. Вопрос в том, на сколько это критично.

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

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

не ходи с пк1 на пк2 ходи с пк2 на пк1 и соси бекапы

1. На сервере, где хранятся копии, создаём отдельного пользователя с домашней директорией, и добавляем его в группу chrooted
2. Для домашней директории выставляем права доступа drwxr-x--x, пользователь и группа — root
3. В домашней директории создаём каталоги backup с правами drwxr-x-wx и backup-backup с drwx-----, оба также root:root.
4. В crond на сервере добавляем mv /home/backup-user/backup/* /home/backup-user/backup-backup/
5. На клиенте, который делает резервное копирование, генерируем уникальный ssh-ключ для этой задачи, добавляем его на сервер
6. В sshd_config добавляем то, что ниже

Match Group chrooted
        ChrootDirectory %h
        ForceCommand internal-sftp
        AllowTcpForwarding no
        GatewayPorts no
        X11Forwarding no
        PermitUserRC no

Получили в итоге:

• Доступ к SSH-консоли отключён, работает только SFTP
• По SFTP клиент может зайти только в директорию backup внутри собственной домашней директории, при этом не может сделать листинг файлов в ней (нет +r, есть только +x), а может только «вслепую» загрузить (или прочитать) файл бэкапа. Создание файлов и директорий вне backup невозможно.
• Сервер по cron’у перемещает загруженные в backup бэкапы в директорию backup-backup, куда доступа у SSH-клиента нет никакого, чтобы нельзя было изменить или удалить загруженные файлы даже вслепую

Это костыль, но рабочий. Лучше, конечно, применять специализированные решения, изначально рассчитанные на write-only доступ.

Какой вопроос задать в гугле?

«Что такое проблема XY»

4 В crond на сервере добавляем mv /home/backup-user/backup/* /home/backup-user/backup-backup/

Что если этот mv сработает во время заливки файла?

Я такую же схему предложил с ВХОДНОЙ RW директорией и переносом в RO директорию SSH пользователь с одним правом (комментарий)

А если вместо cron использовать incron?

Юзер может переопределить некоторые переменные (см. man ssh_config), и тем самым обойти ограничения;

Я не нумизмат но мне тоже интересно, какие переменные юзер может переопределить в варианте использования у ТС ?

В скрипте могут не определиться/развернуться переменные, что в итоге приведёт к повреждению или уничтожению данных в совершенно другом месте (требуется написать проверки на всё);

Такой же вопрос, как/почему могут «не определиться/развернуться переменные» указанные в этом же скрипте?

Сам скрипт может быть подменён/модифицирован

Может, но разве ТС говорил про машинку на которой биткоины все кому не лень майнят уже не первый год?

Удалить файл - Если кто-то 3-й получит доступ к ПК1 и скрипту не смог удалить бэкапы Документов.

Как вариант на ПК2 по завершении копирования делать mv бэкапа в директорию не доступную юзеру под которым заливается бэкап.

/mnt/backup/INrw для записи бэкапов по алгоритму @anc, когда .tmp будет переименован в .tar.gz, файл будет перенесен по cron’u в /mnt/backup/ со сменой владельца и доступен user2 только для чтения.

Ага, именно так!

Если в /mnt/backup файл с таки именем существует, то к новому файлу добавить суфикс типа (#)

Какой-то странный суффикс, а если неудач будет больше одной, то потом разгребать «забор» из суффиксов? :)

http/webdav сервер

Больше костылей богу костылей.

Если есть такие риски, имхо, лучше организовать наоборот

Поддерживаю! Но не всегда такое возможно, сторона сгребющая бэкап может быть в сеансовом доступе, т.е. не она инициирует соединение. Второй минус подобного решения это когда заливающий хост может быть за fw/nat на который вы не можете и/или-не-должны пропускать/пробрасывать внешние соединения.

какие переменные юзер может переопределить в варианте использования у ТС ?

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

как/почему могут «не определиться/развернуться переменные» указанные в этом же скрипте?

По той же причине: ожидание что переменная определена, хотя не всё определяется из дефолтного профиля в неинтерактивном режиме (а скрипт является таковым).

Может, но разве ТС говорил про машинку на которой биткоины все кому не лень майнят уже не первый год?

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

При доступе через ssh по ключу можно указать программу которая будет запущена вместо шелла.

Ну справедливости ради, программу вместо shell вы можете указать любую в независимости от того ssh это или локальный логин.

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

Понял. Да, такое надо учитывать, но это не вариант скрипта ТС.

как/почему могут «не определиться/развернуться переменные» указанные в этом же скрипте?

По той же причине: ожидание что переменная определена, хотя не всё определяется из дефолтного профиля в неинтерактивном режиме (а скрипт является таковым).

Простите, но я написал «указанные в этом же скрипте» других у ТС в нем нет.

Может, но разве ТС говорил про машинку на которой биткоины все кому не лень майнят уже не первый год?

Это открытый форум, наши ответы видит не только топикстартер. (=

Неправильное применение молотка проблема использующего молоток не правильно.

если не можете, то ssh -R

суффикс – отсылка к винде, так-то date +%s сойдёт

я написал «указанные в этом же скрипте»

Скрипт для использования в качестве логина придётся сильно модифицировать. Этот не годится, он не будет работать именно в качестве login shell.

Неправильное применение молотка проблема использующего молоток не правильно.

Увы, таких сейчас даже не большинство, а почти все. )=

Что если этот mv сработает во время заливки файла?

А ничего: fd не изменится, файл «переместится» после окончания его загрузки. И не повредится, если вы об этом.

В crond на сервере добавляем mv /home/backup-user/backup/* /home/backup-user/backup-backup/

А теперь в зависимости от FS или при условии если /home/backup-user/backup/ и /home/backup-user/backup-backup/ это разные mount-point, в момент когда файло ещё льется мы получаем тыкву вместо бэкапа.

incron тоже не прокатит, соединение разорвалось, файл не докачен, но при этом уже никем не используется.

ssh -R не спасет отца русской демократии от сеансовых соединений.

Скрипт для использования в качестве логина придётся сильно модифицировать.

1. man ssh по ключам.
2. sshpass это не сильная модификация.

Неправильное применение молотка проблема использующего молоток не правильно.

Увы, таких сейчас даже не большинство, а почти все. )=

Ну справедливости ради, как показывает минимум лор, все-таки не все. То что таких стало много это да, согласен, но далеко не все. С развитием инета и создания игровых мышек и клавиатур (отсылка к copy-past) таких наплодилось много, но это далеко не все.

Ты мало того что не понял про какой логин он говорит, так ещё и советуешь использовать вредительскую прогу sshpass. Не надо так. Не для того авторы ssh заблокировали неинтерактивный приём пароля чтобы потом всякие умники эту защиту портили.

на узел SSH

Выброси и забудь. Есть такая штука S3 - там это изначально определено и называется ObjectLockConfiguration

Но удалить файл User сможет?

нет!

Если настроить SSH-авторизацию «root» по ключу и в скрипт добавить строку:

ssh root@${ip2} chmod 0400 ${dir2}/${daten}_Documents.tar.gz

Скрипт для использования в качестве логина придётся сильно модифицировать.

1. man ssh по ключам.
2. sshpass это не сильная модификация.

Ещё раз:

в качестве логина

• Скрипт, принимающий поток в stdin;
• chsh -s /path/to/script user.

Хотя, мне тут подумалось, можно сделать просто nologin, на sftp это вроде как повлиять не должно?

Ну справедливости ради, как показывает минимум лор, все-таки не все.

Ошибка выжившего же. Мы не можем знать кто посещает ЛОР, потому что не все посетители зарегистрированы, и не все из посетителей здесь пишут.

Больше костылей богу костылей.

Как насчёт такого костыля? https://github.com/restic/rest-server

--append-only enable append only mode

Скрипт, принимающий поток в stdin;

Скрипт примет, но кому он передаст?

Это вы что бы совсем утопить?

Смотря какой скрипт написать.

Текущий (из стартового поста), например, ничего не принимает. (=

ну я бы навернул ему правила apparmor, повозиться конечно придется.

Если тебе надо чтобы бэкапы писались, но их нельзя было удалить с клиента - гугли Write-Once-Read-Many(WORM). У Veeam такое есть, на самбу есть плагин - можно накостылять подобное. Restic вроде тоже умеет (режим append-only у rest-server).