Tunneling SSH

Si votre base de données n'est pas accessible directement depuis votre machine (car elle se trouve dans un VPC, derrière un bastion ou accessible uniquement via un hôte de saut (jump host) d'entreprise), vous pouvez vous connecter via un tunnel SSH. QoreDB utilise le client OpenSSH natif de votre système, le comportement correspond donc à ce que vous obtiendriez de ssh -L sur la ligne de commande.

Quand vous avez besoin d'un tunnel

Vous avez besoin d'un tunnel chaque fois que :

• La base de données écoute sur une adresse IP privée qui n'est pas routable depuis votre ordinateur.
• La base de données se trouve dans un VPC et seul le bastion a une adresse IP publique.
• Un pare-feu bloque les connexions directes au port de la base de données depuis l'extérieur du réseau.
• Les règles de conformité exigent que tout accès passe par un jump host audité.

Vous n'avez pas besoin d'un tunnel si votre base de données a un point de terminaison public (RDS public, Atlas public, etc.) et que votre adresse IP est sur liste blanche (allowlisted) ; une connexion standard fonctionnera.

Configuration rapide

Dans la boîte de dialogue de connexion, développez la section Tunnel SSH (SSH tunnel) et remplissez les détails du bastion. QoreDB configure un transfert de port local et y connecte le pilote de la base de données de manière transparente.

Authentification

Deux méthodes d'authentification sont prises en charge.

Fichier de clé (recommandé)

Pointez QoreDB vers votre fichier de clé privée (généralement sous ~/.ssh/). Si la clé est chiffrée avec une phrase secrète, fournissez-la ; QoreDB la stocke dans le coffre-fort chiffré, jamais en texte clair.

C'est la méthode recommandée, à la fois pour la sécurité et parce qu'elle correspond à votre flux de travail SSH normal.

Mot de passe

Cela fonctionne pour les hôtes hérités qui ne prennent pas en charge l'authentification par clé. À éviter si possible ; les mots de passe sont plus faibles contre les attaques par force brute.

Vérification de la clé d'hôte (Host key)

Chaque connexion SSH vérifie la clé d'hôte du bastion par rapport à votre fichier ~/.ssh/known_hosts. QoreDB propose trois stratégies :

• accept_new (par défaut pour les nouvelles connexions) : accepte et épingle une nouvelle clé d'hôte la première fois, génère une erreur si elle change plus tard. Cela correspond au StrictHostKeyChecking=accept-new d'OpenSSH.
• strict : refuse de se connecter si l'hôte n'est pas déjà dans known_hosts. Le plus sécurisé ; utile dans les environnements avec une distribution gérée de known_hosts.
• insecure_no_check : accepte n'importe quelle clé d'hôte sans vérification. Pratique pour les environnements de test éphémères, mais vulnérable aux attaques de type man-in-the-middle (MITM). À éviter pour tout ce qui est sensible.

Le accept_new par défaut est un compromis sensé : protection contre le MITM après la première connexion, sans configuration manuelle.

Saut de proxy (Chaîne de bastions)

Certains réseaux exigent de passer par plusieurs hôtes de saut (jump hosts) pour atteindre la base de données. QoreDB prend en charge cela via le champ Proxy jump, qui reflète l'indicateur -J d'OpenSSH.

user1@jump1.example.com:22,user2@jump2.example.com

Vous pouvez lister un ou plusieurs hôtes intermédiaires, séparés par des virgules. QoreDB passe par eux dans l'ordre avant d'atteindre l'hôte SSH final configuré dans la boîte de dialogue.

Délais d'attente et keepalive

Trois champs optionnels ajustent la résilience du tunnel :

Ils ont des valeurs par défaut raisonnables. Ajustez-les si vous avez un réseau instable ou un pare-feu strict qui supprime de manière agressive les connexions inactives.

Comportement en cas d'erreurs

Si le processus SSH ne peut pas démarrer le tunnel (échec d'authentification, hôte injoignable, clé rejetée, etc.), QoreDB affiche directement l'erreur standard d'OpenSSH. La même erreur que vous verriez si vous aviez exécuté ssh -v -L … … sur la ligne de commande.

Les modes d'échec les plus courants :

Vérification avec l'interface de ligne de commande OpenSSH

Si un tunnel ne démarre pas depuis QoreDB, le moyen le plus rapide de déboguer est de le reproduire sur la ligne de commande. L'équivalent exact de ce que QoreDB configure est :

ssh -L 15432:HOTE_BD:5432 -i ~/.ssh/id_ed25519 user@BASTION
# Connectez ensuite QoreDB directement à localhost:15432 (pas de section SSH activée)

Si ssh -L fonctionne mais que QoreDB ne fonctionne pas, le problème se situe dans la configuration du tunnel de QoreDB. Si ssh -L ne fonctionne pas non plus, le problème est en amont (réseau, configuration du bastion, clé, etc.).

Où aller ensuite

• Coffre-fort et profils pour organiser de nombreuses connexions, y compris celles qui partagent le même bastion
• Guides spécifiques aux pilotes PostgreSQL, MySQL, MongoDB