Connexion distante à PostgresSQL 9.6 sur Centos 6 (VPS Vultr)

hypn0s · 14/10/2016 21:06:26

Bonjour,

J'ai pris un serveur virtuel (VPS) chez Vultr.com avec l'objectif de pouvoir accéder à ma base PostgreSQL depuis mon ordinateur avec pgAdmin, car c'est plus confortable qu'avec phpPgAdmin.

Chez Vultr, j'ai donc l'utilisateur "root" pour le serveur, auquel j'accède en SSH avec Putty.
J'ai ensuite créé un utilisateur Linux que l'on appellera "snoopy" avec un mot de passe.
Cet utilisateur a été inscrit dans le groupe "wheel" et comme super-administrateur dans le fichier des "sudoers". Il peut donc passer des commandes "sudo".

L'installation de PostgreSQL a été réalisée autant que possible avec des commandes "sudo" passées par l'utilisateur "snoopy".
Via Putty, psql fonctionne et j'ai pu créer un utilisateur PostgreSQL, que nous appellerons "pluto" une base du même nom:

CREATE USER pluto;
  ALTER USER pluto CREATEDB;
  CREATE DATABASE "pluto" OWNER pluto;
  GRANT ALL PRIVILEGES ON DATABASE "pluto" to pluto;

J'ai également donné sur cette base tous les privilèges à l'utilisateur "snoopy" :

CREATE USER snoopy;
  GRANT ALL PRIVILEGES ON DATABASE "pluto" to snoopy;

J'ai donné aux utilisateurs des mots de passe chiffrés par md5 en passant par la base template1 :

ALTER USER pluto with encrypted password 'le_mot_de_passe_de_pluto';
ALTER USER snoopy with encrypted password 'le mot_de_passe_de_snoopy';

J'ai édité le fichier postgresql.conf pour écouter sur toutes les adresses, devant toutefois passer par l'utilisateur "root" pour cela:

sudo su
cd /var/lib/pgsql/9.6/data/
nano postgresql.conf
  listen_adresses='*';
  port = 5432

Ctrl+X et Yes pour sauver.

et j'ai édité le fichier pg_hba.conf, également avec l'utilisateur "root" :

nano pg_hba.conf
  #IPv4 local connections:
  host    all    all    127.0.0.1/32 md5
  host    all    all    123.124.125.126/32  md5
  # L'adresse IP de la ligne précédente correspond à l'adresse IP publique de mon ordinateur , mais l'exemple est bien sûr fictif.

Ctrl+X et Yes pour sauver.

En tant que "root", j'ai également ouvert le port 5432 dans le pare-feu (enfin, je crois que ça le fait):

sudo su
cd /sbin
iptables -A INPUT -p tcp -m state --state NEW -m tcp -dport 5432 -j ACCEPT

Et j'ai bien sûr redémarré les services :

service iptables restart
service postgresql-9.6 restart

(Les deux retournent "OK".)

L'appel de la commande "hostname" retourne bien le nom de mon serveur :

hostname
  chien01

Alors voilà, je caressais le rêve que le serveur PostgreSQL réponde aux commandes passées depuis mon ordinateur et j'entre donc dans la ligne de commande de Window :

cd "C:\Program Files\PostgreSQL\9.5\bin"
psql -h 111.112.113.114 -U pluto -p 5432 -d pluto -W

J'entre alors le mot de passe PostgreSQL de l'utilisateur "pluto" et le message suivant m'est retourné :

psql n'a pas pu se connecter au serveur : Connexion timed out ( blabla / blabla )
Le serveur est-il actif sur l'hôte <ici l'IP de mon instance VPS chez VULTR> et accepte-il les connexions TCP/IP sur le port 5432 ?

Le problème ne semble donc pas au niveau des identifiants mais bien de l'accès au serveur.

Où le problème peut-il bien se situer ?
Faut-il que j'ouvre des ports sur mon routeur ?

J'ai déjà essayé ceci sans succès:
- entrer dans la ligne de commande le mot de passe normal (non chiffré md5)
- entrer dans la ligne de commande le mot de passe chiffré md5
- me connecter avec l'utilisateur snoopy au lieu de pluto

Quelque chose m'échappe, mais quoi ?

Merci pour votre aide.

Dernière modification par hypn0s (14/10/2016 21:10:55)

rjuju · 14/10/2016 21:21:38

psql n'a pas pu se connecter au serveur : Connexion timed out ( blabla / blabla )
Le serveur est-il actif sur l'hôte <ici l'IP de mon instance VPS chez VULTR> et accepte-il les connexions TCP/IP sur le port 5432 ?

Effectivement, le problème indique ici un problème réseau. Je pense que le paramétrage du firewall n'est pas correct (state NEW n'est pas suffisant), vous pouvez valider rapidement en coupant iptables. Vous pouvez vous inspirer de cet article pour la configuration : http://www.cyberciti.biz/tips/howto-ipt … -port.html

hypn0s · 14/10/2016 22:58:02

Merci beaucoup !

Désactiver le pare-feu rend effectivement possible l'accès distant à la base de données:

service iptables save
service iptables stop

J'essaie à présent de trouver la combinaison du pare-feu qui va permettre la connexion.
Idéalement, j'aimerais imposer une connexion SSH, mais je compte commencer par les choses "simples" avec une connexion classique sur le port 5432.

J'ai donc essayé de rajouter cette ligne dans pg_hba.conf afin d'assouplir temporairement les règles et qu'il n'y ait pas de filtrage sur l'IP:

host    all    all    0.0.0.0/0    md5

.

Je me suis également inspiré de la section consacrée à PostgreSQL du didacticiel "Iptables Essentials: Common Firewall Rules and Commands" :
https://www.digitalocean.com/community/ … postgresql
mais en n'imposant pas l'interface eth1 :

iptables -A INPUT -p tcp -m conntrack  --ctstate NEW,ESTABLISHED -p tcp -dport 5432 -j ACCEPT
iptables -A OUTPUT -p tcp --sport 5432 -m conntrack --ctstate ESTABLISHED -j ACCEPT

(Note: Je vois que cet exemple utilise conntrack et devrai éclaircir cela.)

puis j'ai redémarré les services iptables et postgresql :

service iptables start
service postgresql-9.6

Hélas pare-feu bloque toujours la connexion.

Des idées pour aller de l'avant ?
Merci.

rjuju · 15/10/2016 17:36:05

que renvoie « iptables -L -n » ?

hypn0s · 16/10/2016 21:13:44

Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:80
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:22
REJECT     all  --  0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
REJECT     all  --  0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Bizarre cette instruction REJECT qui vient à la fin de la CHAIN INPUT ; j'imagine qu'il faut
- soit la supprimer
- soit inverser l'ordre des instructions ACCEPT / REJECT en mettant REJECT au début puis en créant ensuite des exceptions avec ACCEPT.

C'est bien cela ?
Merci.

rjuju · 16/10/2016 22:50:10

Les règles d'iptables sont examinées les unes à la suite des autres. Si une règle correspond elle est appliquée et ça s'arrête là, sinon ça continue avec la règle suivante. Finir par un REJECT est donc normal si on veut que sauf exception, le paquet soit rejeté.

Mais de ce que je vois le firewall devrait accepter toutes les connexions entrantes (chaîne input, ACCEPT all -- 0.0.0.0/0 0.0.0.0/0), et il n'y a d'ailleurs aucune trace de vos règles sur le port 5432. Vous êtes sur que la base postgres est bien disponible si vous coupez iptables ?

Ou alors il s'agit d'une règle pour une interface spécifique (lo par exemple). Pouvez-vous plutôt renvoyer le résultat de la commande « iptables -L -n -v »

hypn0s · 17/10/2016 11:45:47

Si une règle correspond elle est appliquée et ça s'arrête là, sinon ça continue avec la règle suivante.

Merci pour cet éclairage utile.

il n'y a d'ailleurs aucune trace de vos règles sur le port 5432

Effectivement. Cela m'étonne ...

Pouvez-vous plutôt renvoyer le résultat de la commande « iptables -L -n -v »

Avec plaisir. Voici donc la version verbeuse :

[snoopy@serveur01 ~]$ iptables -L -n -v
iptables v1.4.7: can't initialize iptables table `filter': Permission denied (you must be root)
Perhaps iptables or your kernel needs to be upgraded.
sudo su
[root@serveur01 snoopy]# iptables -L -n -v                                                                                                                         Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
  454 29734 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:80
 114K   15M ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
  134  9770 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0
 8634  518K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:22
 6259  332K REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited

Chain OUTPUT (policy ACCEPT 160K packets, 27M bytes)
 pkts bytes target     prot opt in     out     source               destination

Toujours pas de trace du port 5432.

Vous êtes sûr que la base postgres est bien disponible si vous coupez iptables ?

Oui, aussitôt que j'entre "service iptables stop", j'arrive à accéder à la base "pluto" (pour reprendre mon exemple) ainsi qu'à la base "postgres" via pgAdmin III.

J'ai encore tenté ceci :

iptables -I INPUT 1 -p tcp --dport 5432 -j ACCEPT

ainsi que suggéré dans la réponse plébiscitée ici : http://serverfault.com/questions/556545 … ct-to-port
Ceci aussi bien avec iptables activé qu'avec iptables désactivé par un "service iptables stop".
Puis j'ai appliqué un "service iptables start/restart".
La règle ne semble pas être appliquée, car il n'y a aucun effet sur le résultat de "iptables -L -n -v".

rjuju · 17/10/2016 11:52:32

hypn0s a écrit :

[root@serveur01 snoopy]# iptables -L -n -v                                                                                                                         Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
  454 29734 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:80
 114K   15M ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
  134  9770 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0
 8634  518K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:22
 6259  332K REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited

Chain OUTPUT (policy ACCEPT 160K packets, 27M bytes)
 pkts bytes target     prot opt in     out     source               destination

ok, donc le traffic est bien bloqué en entrée.

hypn0s a écrit :

J'ai encore tenté ceci :
iptables -I INPUT 1 -p tcp --dport 5432 -j ACCEPT
ainsi que suggéré dans la réponse plébiscitée ici : http://serverfault.com/questions/556545 … ct-to-port
Ceci aussi bien avec iptables activé qu'avec iptables désactivé par un "service iptables stop".
Puis j'ai appliqué un "service iptables start/restart".
La règle ne semble pas être appliquée, car il n'y a aucun effet sur le résultat de "iptables -L -n -v".

Je suppose que vous devez effectuer le paramétrage avec le service iptables démarré, valider avec iptables -L -n et un test de connexion distante que c'est bon, puis sauvegarder la config (service iptables save je suppose), puis éventuellement redémarrer iptables pour vous assurer que ça sera repris au prochain démarrage. Si « service iptables save » ne fonctionne pas, regardez la doc du paquet sur votre distrib pour sauvegarder la configuration d'iptables.

hypn0s · 17/10/2016 12:02:10

Aha !

Voici la commande magique "service iptables save", qui permet alors de sauver la commande nouvellement appliquée dans le fichier /etc/sysconfig/iptables.
Suivie d'un "service iptables restart", la bouille du fichier iptables est nettement plus sympa:

[root@alp01 pgsql-9.6]# iptables -L -n -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:5432
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:80
(...)

@rjuju: Nos messages ce sont croisés.
C'est le message de TrevorH de ce fil qui m'a débloqué https://www.centos.org/forums/viewtopic.php?t=27145
mais vous avez vu tout juste avec le "service iptables save".
Encore merci !

hypn0s · 17/10/2016 12:06:21

Je confirme que cela fonctionne.
Ne me reste plus qu'à sécuriser davantage avec un filtrage sur l'adresse IP.

#1 14/10/2016 21:06:26

Connexion distante à PostgresSQL 9.6 sur Centos 6 (VPS Vultr)

#2 14/10/2016 21:21:38

Re : Connexion distante à PostgresSQL 9.6 sur Centos 6 (VPS Vultr)

#3 14/10/2016 22:58:02

Re : Connexion distante à PostgresSQL 9.6 sur Centos 6 (VPS Vultr)

#4 15/10/2016 17:36:05

Re : Connexion distante à PostgresSQL 9.6 sur Centos 6 (VPS Vultr)

#5 16/10/2016 21:13:44

Re : Connexion distante à PostgresSQL 9.6 sur Centos 6 (VPS Vultr)

#6 16/10/2016 22:50:10

Re : Connexion distante à PostgresSQL 9.6 sur Centos 6 (VPS Vultr)

#7 17/10/2016 11:45:47

Re : Connexion distante à PostgresSQL 9.6 sur Centos 6 (VPS Vultr)

#8 17/10/2016 11:52:32

Re : Connexion distante à PostgresSQL 9.6 sur Centos 6 (VPS Vultr)

#9 17/10/2016 12:02:10

Re : Connexion distante à PostgresSQL 9.6 sur Centos 6 (VPS Vultr)

#10 17/10/2016 12:06:21

Re : Connexion distante à PostgresSQL 9.6 sur Centos 6 (VPS Vultr)

Pied de page des forums

PostgreSQL.fr

À propos

Nous contacter

Groupes Locaux

Réseaux Sociaux