Назад | Перейти на главную страницу

Несколько серверов SFTP имеют общую проблему регистрации пути chroot

Я настраиваю службу SFTP с несколькими экземплярами EC2 для обеспечения высокой доступности на AWS с общим общим ресурсом EFS (смонтированным на /efs/sftp).

            ,--------,
            |        |
            |  SFTP  |-------,
 -----      |________|       |    ,-----------------,
| NLB |                      |    |                 |
 -----                       |----| EFS (/efs/sftp) |
            ,--------,       |    |_________________|
            |        |       |
            | SFTP   |-------'
            |________|

Я использую chroot с SFTP, чтобы пользователи имели доступ только к /efs/sftp. Для регистрации действий chroot'ов я создал /efs/sftp/dev и внутри я настроил сокет rsyslog, используя imuxsock (/efs/sftp/dev/log).

Я в основном слежу за этим блогом, чтобы настроить свой SFTP-сервер. (https://www.the-art-of-web.com/system/sftp-logging-chroot/).

Одна из проблем с настройкой заключается в том, что оба сервера имеют одинаковую конфигурацию (для rsyslog, sftp) оба экземпляра rsyslogs будут получать журналы из /efs/sftp/dev/log. Разве оба сервера не будут записывать одинаковые журналы в /var/log/sftp.log? экземпляр rsyslog, в котором был создан сокет, является единственным, который может регистрировать действия в chroot.

Журналы из этих экземпляров (/var/log/sftp.log) передаются на централизованные серверы регистрации (Splunk) и в конечном итоге будут дубликаты.

Как лучше всего избежать этого дублирования? Как лучше всего получать журналы активности chroot SFTP на обоих серверах?

Изменить: я попробовал это сегодня и обнаружил, что только один сервер может получать журналы. Обновил вопрос.