Como posso permitir que o usuário “postgres” em um servidor rsync para outro?

Question

Estou tentando fazer com que este comando funcione como o usuário postgres (para que eu possa enviar arquivos wal):

rsync -a /tmp/test postgres@server2:/tmp/test

Mas recebo o erro:

Permission denied (publickey).

Eu executei ssh-keygen eval 'ssh-agent' e ssh-add como usuário postgres no server1. keygen criou /var/lib/postgresql/.ssh/id_rsa e id_rsa.pub e posso ver que ele é enviado usando ssh -vvv postgres@server2 .

No servidor2 eu criei /var/lib/postgresql/.ssh/authorized_keys coloquei o conteúdo do id_rsa.pub form server1 nele. É de propriedade do postgres user e group e chmod 600. O diretório .ssh também é de propriedade de postgres e chmod 700.

Eu posso ver a partir do registro detalhado do sshd no server2 que Failed publickey for postgres...

postgres usuário nos dois servidores: postgres:x:106:114:PostgreSQL administrator,,,:/var/lib/postgresql:/bin/bash

ssh -vvv postgres @ server2

...
debug1: Found key in /var/lib/postgresql/.ssh/known_hosts:1
debug1: ssh_ecdsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /var/lib/postgresql/.ssh/id_rsa (0x7f468e434000)
debug2: key: /var/lib/postgresql/.ssh/id_dsa ((nil))
debug2: key: /var/lib/postgresql/.ssh/id_ecdsa ((nil))
debug1: Authentications that can continue: publickey
debug3: start over, passed a different list publickey
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /var/lib/postgresql/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey
debug1: Trying private key: /var/lib/postgresql/.ssh/id_dsa
debug3: no such identity: /var/lib/postgresql/.ssh/id_dsa
debug1: Trying private key: /var/lib/postgresql/.ssh/id_ecdsa
debug3: no such identity: /var/lib/postgresql/.ssh/id_ecdsa
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey).  

server2 sshd_config (linhas comentadas removidas)

Port 22
Protocol 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
UsePrivilegeSeparation yes
KeyRegenerationInterval 3600
ServerKeyBits 768
SyslogFacility AUTH
LogLevel VERBOSE
LoginGraceTime 120
PermitRootLogin yes
StrictModes yes
RSAAuthentication yes
PubkeyAuthentication yes
IgnoreRhosts yes
RhostsRSAAuthentication no
HostbasedAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
PasswordAuthentication no
X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server
UsePAM yes

log de autenticação do server2

Jan 16 03:54:21 ip-10-28-26-251 sshd[7972]: Set /proc/self/oom_score_adj to 0
Jan 16 03:54:21 ip-10-28-26-251 sshd[7972]: Connection from 10.28.123.97 port 49377
Jan 16 03:54:21 ip-10-28-26-251 sshd[7972]: Failed publickey for postgres from 10.28.123.97 port 49377 ssh2
Jan 16 03:54:21 ip-10-28-26-251 sshd[7972]: Connection closed by 10.28.123.97 [preauth]

O que estou perdendo? Eu estou supondo que o sshd não está olhando para o meu arquivo authorized_keys no server2

    

Answer 1

Supondo que seu servidor escravo permita autenticação de chave, você só precisa atualizar /etc/ssh/sshd_config se tiver definido AllowedUsers , nesse caso você precisa garantir que postgres esteja nessa lista.

Além disso, apenas ssh-keygen (deixe a senha da chave privada vazia) e, em seguida, inclua um ~/.ssh/authorized_keys directory / file no servidor slave. O diretório inicial para postgres é /var/lib/postgresql , mas se você fizer essas operações enquanto su 'd como o usuário postgres , poderá usar apenas ~ , sem mencionar que você não precisará chown qualquer coisa, porque postgres possuirá as chaves ssh geradas no servidor master, e postgres possuirá o diretório / arquivo criado no servidor slave.

Certifique-se de definir as permissões de arquivo com segurança nos servidores mestre e escravo:

# 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

    

Answer 2

Você precisa da seguinte entrada em sshd_config do server2:

AuthorizedKeysFile  .ssh/authorized_keys

    

Answer 3

Desativar o sistema no mundo inteiro é uma solução ruim.

É muito melhor criar um módulo de política que permita a ação específica de que você precisa.

Aqui está o que eu fiz no RHEL6:

Limpei meu registro de auditoria, reiniciei o rsyslogd e repeti o problema.

Em seguida, use audit2allow para ver o problema legível:

# 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.

Após se certificar de que não houve negações extras, e que elas eram específicas para o problema em questão, crie um módulo selinux para permitir que o sshd leia, abra e getattr para postgres authorized_keys:

# audit2allow -a -M sshd_read_postgres_ssh_authorized_keys

Agora instale o módulo resultante:

# semodule -i sshd_read_postgres_ssh_authorized_keys.pp

Eu copiei este módulo para o servidor peer postgres e instalei lá também. Agora eu posso ssh com autenticação de chave pública entre caixas como postgres, e ainda estou em um estado de imposição selinux.

    

Answer 4

O SELinux estava causando esse problema para mim no Redhat 6.5. Corrigido usando:

setenforce Permissivo

    

Answer 5

Você pode ativar os registros de depuração no seu servidor ssh existente. No arquivo / etc / ssh / sshd_config mudar %código% se o motivo do login mal-sucedido for LogLevel DEBUG3 e direitos de acesso a authorized_keys parecem ok, então este comando ajudará

Could not open authorized keys '/var/lib/pgsql/.ssh/authorized_keys': Permission denied

explicação

    

Answer 6

Eu encontrei a resposta de Gregory apenas parcialmente trabalhada para mim, embora isso me apontasse na direção certa. Descobri que algumas regras / políticas eram necessárias e só podiam ser geradas em uma ordem específica.

Como o comando ssh-copy-id só funciona se a outra extremidade tiver uma senha, você precisará scp da chave pública e ajustará o usuário e as permissões de acordo. Desta forma, nenhuma senha precisa ser criada e um possível ponto de acesso é mantido fechado.

Para criar uma chave de usuário postgres e permitir que ela seja ssh em si, mas se você levar essa chave para outro servidor, ela também funcionará.

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

Cada erro precisa ocorrer antes que uma regra possa ser gerada para ele, portanto, após cada política adicionada, outra tentativa de ssh com apenas inserir os prompts de senha é necessária.

$ ssh [email protected] 

ssh em si mesmo por simplicidade, mas ainda funciona. Depois de erros:

$ exit
# audit2allow -a -M sshd_open_postgres_ssh_authorized_keys
# semodule -i sshd_open_postgres_ssh_authorized_keys.pp
# su postgres
$ ssh [email protected] 
$ exit
# audit2allow -a -M sshd_read_postgres_ssh_authorized_keys
# semodule -i sshd_read_postgres_ssh_authorized_keys.pp
# su postgres
$ ssh [email protected] 
$ exit
# audit2allow -a -M sshd_getattr_postgres_ssh_authorized_keys
# semodule -i sshd_read_postgres_ssh_authorized_keys.pp
# su postgres
$ ssh [email protected] 

deve funcionar desta vez

OBSERVAÇÃO: '#' indica root, mas use sudo, escrevi dessa maneira para facilitar - não para indicar as melhores práticas