Vous n'êtes pas identifié(e).
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 = 5432Ctrl+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 ACCEPTEt 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
chien01Alors 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 -WJ'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)
Hors ligne
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
Julien.
https://rjuju.github.io/
Hors ligne
Merci beaucoup !
Désactiver le pare-feu rend effectivement possible l'accès distant à la base de données:
service iptables save
service iptables stopJ'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.6Hélas pare-feu bloque toujours la connexion.
Des idées pour aller de l'avant ?
Merci.
Hors ligne
que renvoie « iptables -L -n » ?
Julien.
https://rjuju.github.io/
Hors ligne
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 destinationBizarre 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.
Hors ligne
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 »
Julien.
https://rjuju.github.io/
Hors ligne
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 destinationToujours 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 ACCEPTainsi 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".
Hors ligne
[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.
J'ai encore tenté ceci :
iptables -I INPUT 1 -p tcp --dport 5432 -j ACCEPTainsi 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.
Julien.
https://rjuju.github.io/
Hors ligne
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 !
Hors ligne
Je confirme que cela fonctionne.
Ne me reste plus qu'à sécuriser davantage avec un filtrage sur l'adresse IP.
Hors ligne