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

Я хотел бы ежедневно передавать некоторые файлы с сервера A на сервер B (в целях резервного копирования). Однако я не могу найти способ, который не создает нарушений безопасности. Моя цель состоит в том, чтобы кто-то с правами sudo на сервере A не мог использовать эту передачу для подключения к серверу B.

Моя основная идея состояла в том, чтобы сделать cronjob с SCP (или аналогичную) команду в нем. Очевидно, что использование SSH-соединения на основе пароля между A и B не работает, а использование SSH-соединения на основе ключа, насколько я знаю, позволит пользователю сервера A напрямую подключаться к B через A.

Я не эксперт по безопасности, я могу упустить очевидное. Есть ли способ добиться того, чего я хочу?

Я также не хочу, чтобы пользователи сервера B могли подключаться к серверу A.

Использовать rsync в cronjob, как обычно.

На клиенте rsync пользователи с привилегией «sudo» смогут увидеть имя пользователя и пароль, необходимые для доступа конкретные папки, совместно используемые сервером rsync.

Но эти сертификаты отделены от учетных данных пользователя и не предоставляют SSH-доступа к серверу. Поэтому, если все настроено правильно, все, к чему они получат доступ на сервере, — это резервные копии с их собственной машины.

На rsync-сервере нет ничего, что давало бы доступ к rsync-клиенту.

Просто отправьте файл к serverA вместо того, чтобы пользователь на serverA копировал его с serverB. Если вы хотите скопировать foo.txt от серверB к серверA, вы можете сделать это двумя основными способами:

1. Запустите команду на серверA принести файл из серверB.
2. Запустите команду на серверB отправить файл на сервер А.

Во втором случае никто на сервер А нужен доступ к серверB. Итак, настройте ssh на основе ключей от serverB к serverA, а затем добавьте свою строку cron для соответствующего пользователя на сервере B.

Например, чтобы сделать это вручную, вы должны сделать:

user1@serverB $ scp /path/to/foo.txt user1@serverA:/path/to/foo.txt

Таким образом, никто на серверA получает любой доступ к серверB и вам нужно только иметь пользователя на серверB кто может войти в серверA.

Обычный способ сделать это — использовать sftp и chroot.

На сервере B вы должны настроить ssh для chroot пользователя с сервера A и ограничиться sftp. например добавить в /etc/ssh/sshd_config

Подсистема sftp /usr/lib/openssh/sftp-сервер

Резервные копии Match Group
    ChrootDirectory /backups/%u
    AuthorizedKeysFile %h/.ssh/authorized_keys
    ForceCommand внутренний-sftp
    AllowTcpForwarding нет

Затем вы создаете пользователя для сервера A на сервере B, например. пользовательA, с каталогом /резервные копии/пользовательA (принадлежит root). Тогда вам понадобится резервные копии группа, которая пользовательA добавляется к. Правило в конфигурации ssh применяется к пользователям в этой группе, и это ограничивает пользователя из A только данными, которые они помещают в этот «дропбокс» sftp, и не позволяет им использовать ssh.

Для резервного копирования я бы рекомендовал этот подход в сочетании с таким инструментом, как duply, для фактического управления резервными копиями, чтобы резервные копии можно было зашифровать, добавить, легко восстановить и т. д.

ssh и rsync (и SFTP) всегда будут давать вам логин на сервере, к которому вы подключаетесь, который вы можете или не можете контролировать.

Почему бы не использовать HTTPS?

Вы можете либо

1. запустить сервер на A и иметь B ПОЛУЧАТЬ данные
2. или запустите его на B и получите A ПУБЛИКОВАТЬ Это.

Чтобы защитить данные от посторонних третьих лиц, вам придется зашифровать соединение (используйте HTTPS, а не обычный HTTP). и использовать по крайней мере базовая аутентификация.

Это не защитит данные от пользователей root ни в одной из двух систем: обе могут читать данные и изменить это на их стороне, и вы буквально ничего не можете с этим поделать.

Простой HTTP-сервер можно запустить несколькими способами, например:

python -m Простой HTTP-сервер 8080

Шифрование соединения требует создания SSL-сертификата и нескольких строк кода Python:

#!/usr/бин/питон
импортировать BaseHTTPServer, SimpleHTTPServer
импорт SSL

httpd = BaseHTTPServer.HTTPServer(('0.0.0.0', 8443), SimpleHTTPServer.SimpleHTTPRequestHandler)
httpd.socket = ssl.wrap_socket(httpd.socket, certfile='./certs_and_key.pem', server_side=True)
httpd.serve_forever()

Базовая аутентификация требует немного больше кода, но это также может быть сделано.

Существует проблема с предположениями, стоящими за вашим вопросом. SSH предназначен для предоставления доступа к системе, но вы хотите использовать SSH и не предоставлять доступ к системе. Может быть, SSH не подходит для этих требований?

Опция 1

Передача файлов на веб-сайты происходит постоянно, при этом загрузчик не получает доступа к базовой системе. Создайте или найдите простое веб-приложение, которое может принимать загружаемый файл и записывать его в нужный каталог. При необходимости запросите секрет приложения или пароль. Любой пользователь root в системе A сможет увидеть файл, в котором хранится секрет приложения, поэтому он сможет загружать файлы таким же образом. Но пока веб-приложение, которое получает загрузку, не предоставляет никакого доступа для чтения, требование не допускать привилегированного пользователя к Системе B выполняется.

Вариант 2

Вы все еще можете использовать SSH для отправки файлов. Просто ограничьте права. Для пользователя системы B, который используется для передачи SCP, дайте доступ только на запись к определенному каталогу и разрешение на чтение нигде в системе B. Вы можете отправлять команды передачи файлов из системы A для записи в этот каталог, вы просто никогда не будете уметь их читать.Опять же, пользователь root в системе A будет иметь возможность доступа к ключам SSH и загрузки своих файлов в то же место, но если пользователь системы B не имеет прав на чтение в файловой системе, его возможности ограничены. Эту технику легче сказать, чем сделать. Пользователь root системы A по-прежнему может получить оболочку в системе B, поэтому, если вы не ограничите разрешения во всей системе, включая системные исполняемые команды, пользователь все равно сможет запускать множество команд без чтения файлов данных. Так что это зависит от того, что вы подразумеваете под кем-то, имеющим доступ к системе. Опять же, лучше не использовать SSH.

Пока не ssh, вы можете обнаружить, что синхронизация представляет интерес:

• занимает безопасность серьезно
• это с открытым исходным кодом
• имеет большой документация
• поддерживает туннелирование SSH
• поддерживает несколько платформ

Он также доступен через подходящийвместе со связанными пакетами:

$ apt search -q синхронизация
Сортировка...
Полнотекстовый поиск...
golang-github-syncthing-notify-dev/focal,focal 0.0~git20180806.b76b458-1 все
  Библиотека уведомлений о событиях файловой системы на стероидах

golang-github-syncthing-syncthing-dev/focal,focal 1.1.4~ds1-4ubuntu1 все
  децентрализованная синхронизация файлов — пакет dev

синхронизация/фокус 1.1.4~ds1-4ubuntu1 amd64
  децентрализованная синхронизация файлов

syncthing-discosrv/focal 1.1.4~ds1-4ubuntu1 amd64
  децентрализованная синхронизация файлов - сервер обнаружения

syncthing-gtk/focal,focal 0.9.4.4-1 все
  Графический интерфейс на основе GTK3 и значок области уведомлений для синхронизации

syncthing-relaysrv/focal 1.1.4~ds1-4ubuntu1 amd64
  децентрализованная синхронизация файлов - сервер ретрансляции

Для SSH, в зависимости от частоты интервала и, следовательно, фактора раздражения, вы можете реализовать Двойная аутентификация с помощью Пэм, что будет означать, что для подключения потребуется утверждение.