Comment puis-je autoriser l'utilisateur "postgres" sur un serveur à synchroniser vers un autre à l'aide de rsync?

En supposant que votre serveur esclave autorise l'authentification par clé, vous devez simplement mettre à jour /etc/ssh/sshd_config si vous avez défini AllowedUsers, auquel cas vous devez vous assurer que postgres est dans cette liste.

En dehors de cela, il vous suffit de faire ssh-keygen (laissez vide la phrase secrète de la clé privée), puis ajoutez un répertoire/fichier ~/.ssh/authorized_keys sur le serveur esclave. Le répertoire personnel de postgres est /var/lib/postgresql, mais si vous effectuez ces opérations en étant connecté en tant qu'utilisateur postgres, vous pouvez simplement utiliser ~, sans oublier que vous n'avez pas à changer les droits avec chown, car postgres possédera les clés ssh générées sur le serveur maître, et postgres possédera le répertoire/fichier créé sur le serveur esclave.

Assurez-vous de définir les autorisations de fichier de manière sécurisée sur le serveur maître et esclave:

# Sur le maître
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_rsa
chmod 600 ~/.ssh/id_rsa.pub
chmod 600 ~/.ssh/known_hosts  # celui-ci n'existera pas avant que vous ne vous connectiez en SSH une fois

# Sur l'esclave
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Vous avez besoin de l'entrée suivante dans le sshd_config de server2 :

AuthorizedKeysFile  .ssh/authorized_keys

Désactiver SELinux au niveau du système est une mauvaise solution.

Il est beaucoup mieux de créer un module de politique qui permettra l'action spécifique dont vous avez besoin.

Voici ce que j'ai fait dans RHEL6 :

J'ai effacé mon journal d'audit, redémarré rsyslogd et reproduit le problème.

Ensuite, utilisez audit2allow pour voir le problème lisible par l'homme :

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

                Vous pouvez utiliser audit2allow pour générer un module chargeable permettant cet accès.

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.

                Vous pouvez utiliser audit2allow pour générer un module chargeable permettant cet accès.

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.

                Vous pouvez utiliser audit2allow pour générer un module chargeable permettant cet accès.

Après avoir vérifié qu'il n'y avait pas de dénis supplémentaires en cours et que ceux-ci étaient spécifiques au problème en cours, créez un module SELinux pour permettre à sshd de lire, ouvrir et obtenir les autorisations de postgres authorized_keys :

# audit2allow -a -M sshd_read_postgres_ssh_authorized_keys

Installez maintenant le module résultant :

# semodule -i sshd_read_postgres_ssh_authorized_keys.pp

J'ai copié ce module sur le serveur postgres distant et l'ai également installé là-bas. Je peux désormais me connecter en SSH avec une authentification par clé publique entre les machines en tant que postgres, tout en restant en mode SELinux forcé.

Vous pouvez activer les journaux de débogage sur votre serveur ssh existant. Dans le fichier /etc/ssh/sshd_config, changez LogLevel DEBUG3 si la raison de l'échec de la connexion est Could not open authorized keys '/var/lib/pgsql/.ssh/authorized_keys': Permission denied et que les droits d'accès aux authorized_keys semblent corrects, alors cette commande aidera

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

explication

J'ai trouvé que la réponse de Gregory ne fonctionnait que partiellement pour moi, même si elle m'a mis sur la bonne voie. J'ai constaté que quelques règles/politiques étaient nécessaires et ne pouvaient être générées que dans un ordre spécifique.

Comme la commande ssh-copy-id ne fonctionne que si l'autre extrémité a un mot de passe, vous devrez scp la clé publique et ajuster l'utilisateur et les autorisations en conséquence. De cette façon, aucun mot de passe n'a besoin d'être créé et un point d'accès possible est maintenu fermé.

Pour créer une clé utilisateur postgres et lui permettre de se connecter en ssh à lui-même, mais si vous portez cette clé sur un autre serveur, elle fonctionnera également.

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

Chaque erreur doit survenir avant qu'une règle puisse être générée pour elle, donc après chaque politique ajoutée, une autre tentative de ssh avec simplement une pression sur la touche entrée sur les invites de mot de passe est nécessaire.

$ ssh postgres@192.168.0.10 

Se connecter en ssh pour la simplicité, mais cela fonctionne toujours. Après une erreur :

$ 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 

devrait fonctionner cette fois

REMARQUE : '#' indique root, mais utilisez sudo, je l'ai écrit de cette façon pour faciliter - et non pour indiquer les meilleures pratiques