История изменений

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»

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»

1. На сервере, где хранятся копии, создаём отдельного пользователя с домашней директорией, и добавляем его в группу chrooted 2.Для домашней директории выставляем права доступа drwxr-x--x, пользователь и группа — root
2. В домашней директории создаём каталоги backup с правами drwxr-x-wx и backup-backup с drwx-----, оба также root:root.
3. В crond на сервере добавляем mv /home/backup-user/backup/* /home/backup-user/backup-backup/
4. На клиенте, который делает резервное копирование, генерируем уникальный 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»