Documentation PostgreSQL 9.6.24 > Administration du serveur > Configuration du serveur et mise en place > Connexions tcp/ip sécurisées avec des tunnels ssh tunnels | |
Connexions tcp/ip sécurisées avec ssl | Enregistrer le journal des événements sous Windows |
Il est possible d'utiliser ssh pour chiffrer la connexion réseau entre les clients et un serveur PostgreSQL™. Réalisé correctement, ceci fournit une connexion réseau sécurisée, y compris pour les clients non SSL.
Tout d'abord, assurez-vous qu'un serveur ssh est en cours d'exécution sur la même machine que le serveur PostgreSQL™ et que vous pouvez vous connecter via ssh en tant qu'un utilisateur quelconque. Ensuite, vous pouvez établir un tunnel sécurisé vers le serveur distant. Un tunnel sécurisé écoute sur un port local et envoie tout le trafic vers un port de la machine distante. Le trafic envoyé vers le port distant peut arriver sur son adresse localhost ou vers une autre adresse liée si désirée , il n'apparaît pas comme venant de votre machine locale. Cette commande crée un tunnel sécurisé de la machine cliente vers la machine distante foo.com :
ssh -L 63333:localhost:5432 joe@foo.com
Le premier numéro de l'argument -l, 63333, est le numéro de port local du tunnel ; cela peut être tout port inutilisé. (IANA réserve les ports 49152 à 65535 pour une utilisation privée.) Le nom ou l'adresse IP après ça est l'adresse distante liée à laquelle vous vous connectez, par exemple localhost, ce qui est la valeur par défaut. Le deuxième nombre, 5432, est la fin distante du tunnel, autrement dit le numéro de port du serveur de bases de données. Pour vous connecter au serveur en utilisant ce tunnel, vous vous connectez au port 63333 de la machine locale :
psql -h localhost -p 63333 postgres
Sur le serveur de bases de données, il semblera que vous êtes l'utilisateur joe sur l'hôte foo.com en vous connectant à l'adresse liée localhost dans ce contexte, et il utilisera la procédure d'authentification configurée pour les connexions de cet utilisateur et de cet hôte. Notez que le serveur ne pensera pas que la connexion est chiffrée avec SSL car, en effet, elle n'est pas chiffrée entre le serveur SSH et le serveur PostgreSQL™. Cela ne devrait pas poser un risque de sécurité supplémentaire parce que les deux serveurs sont sur la même machine.
Pour réussir la configuration du tunnel, vous devez être autorisé pour vous connecter via ssh sur joe@foo.com, comme si vous aviez tenté d'utiliser ssh pour créer une session de terminal.
Vous pouvez aussi configurer la translation de port de cette façon :
ssh -L 63333:foo.com:5432 joe@foo.com
mais alors le serveur de la base de données verra la connexion venir de son interface foo.com qui n'est pas ouverte par son paramétrage par défaut listen_addresses = 'localhost'. Ceci n'est pas habituellement ce que vous êtes.
Si vous devez vous connecter au serveur de bases de données via un hôte de connexion, une configuration possible serait :
ssh -L 63333:db.foo.com:5432 joe@shell.foo.com
Notez que de cette façon la connexion de shell.foo.com à db.foo.com ne sera pas chiffrée par le tunnel SSH. SSH offre un certain nombre de possibilités de configuration quand le réseau est restreint. Merci de vous référer à la documentation de SSH pour les détails.
Plusieurs autres applications existantes peuvent fournir des tunnels sécurisés en utilisant une procédure similaire dans le concept à celle que nous venons de décrire.