Как я могу разрешить пользователю «postgres» на одном сервере выполнять синхронизацию с другим?

Предполагая, что ваш подчиненный сервер поддерживает аутентификацию по ключу, вам нужно только обновить /etc/ssh/sshd_config если вы установили AllowedUsers, в этом случае вам нужно убедиться postgres находится в этом списке.

Кроме этого, просто ssh-keygen (оставьте кодовую фразу закрытого ключа пустой), а затем добавьте ~/.ssh/authorized_keys каталог / файл на подчиненный сервер. Домашний каталог для postgres является /var/lib/postgresql, но если вы выполните эти операции, пока suкак postgres пользователь, вы можете просто использовать ~, не говоря уже о том, что вам не придется chown что угодно, потому что postgres будет владеть сгенерированными ключами ssh на главном сервере, и postgres будет владеть созданным каталогом / файлом на подчиненном сервере.

Обязательно установите права доступа к файлам как на главном, так и на подчиненном сервере:

# On master
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_rsa
chmod 600 ~/.ssh/id_rsa.pub
chmod 600 ~/.ssh/known_hosts  # this one won't exist until you SSH once

# On slave
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Вам нужна следующая запись в sshd_config сервера 2:

AuthorizedKeysFile  .ssh/authorized_keys

Отключение всей системы selinux - плохое решение.

Гораздо лучше создать модуль политики, который позволит вам выполнить конкретное действие.

Вот что я сделал в RHEL6:

Я очистил журнал аудита, перезапустил rsyslogd и повторил проблему.

Затем используйте audit2allow, чтобы увидеть проблему, удобочитаемую человеком:

# audit2allow -w -a
type=AVC msg=audit(1438288591.000:8525): avc:  denied  { open } for  pid=6063 comm="sshd" path="/var/lib/pgsql/.ssh/authorized_keys" dev="dm-0" ino=920234 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:postgresql_db_t:s0 tclass=file
        Was caused by:
                Missing type enforcement (TE) allow rule.

                You can use audit2allow to generate a loadable module to allow this access.

type=AVC msg=audit(1438288591.000:8525): avc:  denied  { read } for  pid=6063 comm="sshd" name="authorized_keys" dev="dm-0" ino=920234 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:postgresql_db_t:s0 tclass=file
        Was caused by:
                Missing type enforcement (TE) allow rule.

                You can use audit2allow to generate a loadable module to allow this access.

type=AVC msg=audit(1438288591.000:8526): avc:  denied  { getattr } for  pid=6063 comm="sshd" path="/var/lib/pgsql/.ssh/authorized_keys" dev="dm-0" ino=920234 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:postgresql_db_t:s0 tclass=file
        Was caused by:
                Missing type enforcement (TE) allow rule.

                You can use audit2allow to generate a loadable module to allow this access.

Убедившись, что никаких лишних отказов не происходит и что они относятся к рассматриваемой проблеме, создайте модуль selinux, чтобы позволить sshd читать, открывать и getattr для postgres authorized_keys:

# audit2allow -a -M sshd_read_postgres_ssh_authorized_keys

Теперь установите получившийся модуль:

# semodule -i sshd_read_postgres_ssh_authorized_keys.pp

Я скопировал этот модуль на одноранговый сервер postgres и также установил там. Теперь я могу использовать ssh с аутентификацией с открытым ключом между ящиками как postgres, и я все еще нахожусь в принудительном состоянии selinux.

Вы можете включить журналы отладки на существующем ssh-сервере. В файле / etc / ssh / sshd_config изменить LogLevel DEBUG3 если причина неудачного входа в систему Could not open authorized keys '/var/lib/pgsql/.ssh/authorized_keys': Permission denied и права доступа к authorized_keys кажутся нормальными, тогда эта команда поможет

restorecon -FRvv /var/lib/pgsql/.ssh/

объяснение

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

Поскольку ssh-copy-id команда работает только в том случае, если на другом конце есть пароль, вам нужно будет scp открытый ключ и соответствующим образом настройте пользователя и разрешения. Таким образом, не требуется создавать пароль, а одна возможная точка доступа остается закрытой.

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

# su postgres
$ cd
$ ssh-keygen # [enter....] * 
$ cd .ssh/
$ cp id_rsa.pub authorized_keys
$ chmod 0600 authorized_keys 

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

$ ssh postgres@192.168.0.10 

ssh в self для простоты, но он все еще работает. После этого ошибки:

$ exit
# audit2allow -a -M sshd_open_postgres_ssh_authorized_keys
# semodule -i sshd_open_postgres_ssh_authorized_keys.pp
# su postgres
$ ssh postgres@192.168.0.10 
$ exit
# audit2allow -a -M sshd_read_postgres_ssh_authorized_keys
# semodule -i sshd_read_postgres_ssh_authorized_keys.pp
# su postgres
$ ssh postgres@192.168.0.10 
$ exit
# audit2allow -a -M sshd_getattr_postgres_ssh_authorized_keys
# semodule -i sshd_read_postgres_ssh_authorized_keys.pp
# su postgres
$ ssh postgres@192.168.0.10 

должен работать на этот раз

ПРИМЕЧАНИЕ: '#' указывает на root, но используйте sudo, я написал это для простоты, а не для обозначения лучших практик

SELinux вызывал у меня эту проблему на Redhat 6.5. Исправлено с использованием:

setenforce Permissive