SSL/TLS et tunnel SSH

Deux problèmes différents, deux onglets différents dans la boîte de dialogue de connexion. SSL/TLS chiffre la connexion à la base de données elle-même. Un tunnel SSH fait passer une connexion non chiffrée par un serveur auquel vous faites déjà confiance.

Vous pouvez utiliser les deux à la fois.

SSL/TLS

Les bases de données cloud — AWS RDS, Supabase, PlanetScale, Azure SQL — l’exigent généralement.

Cochez Activer SSL/TLS, puis choisissez un mode :

Mode	Effet
Désactivé	Aucun chiffrement. Non recommandé
Préférer	Utiliser SSL si le serveur le prend en charge, sinon connexion en clair
Exiger	Toujours utiliser SSL, sans vérifier le certificat
Vérifier la CA	SSL, avec vérification du certificat par rapport à la CA
Vérification complète	SSL, vérification de la CA et du nom d’hôte

Pour SQL Server, le même réglage s’appelle Niveau de chiffrement.

Certificats

Trois chemins de fichiers facultatifs vous permettent de fournir vos propres éléments :

• Certificat CA — nécessaire pour Vérifier la CA et Vérification complète lorsque le serveur utilise une CA privée.
• Certificat client et Clé privée — pour les serveurs qui exigent un TLS mutuel.

Accepter les certificats auto-signés ignore entièrement la validation du certificat. Cela fait fonctionner une machine de développement en quelques secondes, mais supprime la protection que TLS devait apporter — ne le laissez pas activé pour une connexion de production.

Tunnel SSH

Avec un tunnel, NabuSQL se connecte d’abord au serveur SSH et fait passer la connexion à la base par celui-ci. C’est ainsi que l’on atteint une base qui n’écoute que sur localhost sur une machine distante.

L’hôte et le port sont résolus sur le serveur SSH

L’hôte et le port de l’onglet Général sont interprétés du point de vue du serveur SSH. Pour une base qui tourne sur la même machine que le serveur SSH, cela signifie localhost et le port habituel de la base — pas l’adresse publique du serveur.

Cochez Activer le tunnel SSH et renseignez :

• Hôte, Port et Nom d’utilisateur du serveur SSH.
• Authentification : Mot de passe ou Clé.
• Pour l’authentification par clé : le chemin du fichier de clé privée, plus une phrase secrète si la clé est chiffrée.

Un exemple concret

Un serveur PostgreSQL sur db.example.com accepte SSH, mais la base elle-même n’écoute que sur 127.0.0.1:5432 :

Onglet	Champ	Valeur
Général	Hôte	127.0.0.1
Général	Port	5432
Tunnel SSH	Hôte	db.example.com
Tunnel SSH	Port	22
Tunnel SSH	Nom d’utilisateur	votre utilisateur SSH

Dépannage

Connexion refusée via un tunnel — l’hôte de la base est résolu sur le serveur SSH. Vérifiez que la valeur fonctionne en lançant psql -h <hôte> une fois connecté à ce serveur.

Certificate verify failed — le serveur présente un certificat signé par une CA que votre système ne connaît pas. Fournissez le certificat CA plutôt que de passer en Exiger.

Clé SSH refusée — vérifiez que le fichier de clé privée correspond bien à la clé publique dans authorized_keys, et qu’une phrase secrète est saisie si la clé en a une.

Pas de SSH et le port de la base est fermé ? Typique de l’hébergement mutualisé — voir Tunnel HTTP.