Groupes de sécurité et SSH : ouvrir l'accès à votre instance

Votre instance est lancée, elle a une IP flottante… et pourtant la connexion SSH échoue avec « Connection timed out » ? Dans 9 cas sur 10, la cause est le groupe de sécurité. Sur FelCloud, comme sur tout cloud OpenStack, le pare-feu bloque par défaut tout le trafic entrant venant d'Internet. Ce guide explique ce que fait exactement le groupe default, comment ouvrir le port 22 proprement, et comment se connecter en SSH sans erreur.

Qu'est-ce qu'un groupe de sécurité OpenStack ?

Un groupe de sécurité est un pare-feu virtuel appliqué à chaque interface réseau de vos instances. Il est composé de règles qui autorisent un type de trafic. Tout ce qui n'est pas explicitement autorisé est bloqué.

Chaque règle définit :

• Direction : Ingress (trafic entrant vers l'instance) ou Egress (trafic sortant).
• Protocole : TCP, UDP ou ICMP (le ping).
• Port : par exemple 22 pour SSH, 80 et 443 pour un site web.
• Source (Remote) : qui a le droit d'entrer. Soit une plage d'adresses (CIDR) comme 0.0.0.0/0 (tout Internet) ou 41.x.x.x/32 (une seule adresse), soit un autre groupe de sécurité.

Une instance peut avoir plusieurs groupes : leurs règles s'additionnent. Les modifications s'appliquent immédiatement, sans redémarrer l'instance.

Le groupe « default » : ce qu'il autorise vraiment

C'est ici que beaucoup d'utilisateurs se trompent. Le groupe default est créé automatiquement dans chaque projet et appliqué aux instances si vous n'en choisissez pas d'autre. Son comportement :

Autrement dit : avec le seul groupe default, votre instance n'est pas joignable en SSH depuis votre ordinateur, même avec une IP flottante. Ce n'est pas une panne, c'est une protection voulue. Il faut ajouter une règle d'entrée.

Étape 1 — Créer un groupe de sécurité dédié

Plutôt que de modifier default, créez un groupe par usage : c'est plus lisible et plus sûr.

1. Dans le menu Network, ouvrez Security Groups.
2. Cliquez sur Create Security Group, donnez un nom explicite (par exemple ssh-access) et validez.
3. Ouvrez le groupe : l'onglet Rules ne contient que deux règles Egress (IPv4 et IPv6). Votre instance peut sortir sur Internet, mais rien ne peut encore entrer.
4. Cliquez sur Create Rule pour ajouter l'accès SSH.

Étape 2 — Ajouter la règle SSH (port 22)

Dans la fenêtre Create Rule, remplissez les champs dans l'ordre :

1. Protocol : Custom TCP Rule.
2. Direction : Ingress (le trafic qui entre vers l'instance).
3. Ether Type : IPv4.
4. Port Type : Custom.
5. Port/Port Range : 22.
6. Remote Type : CIDR.
7. Remote IP Prefix : votre adresse IP publique suivie de /32 (par exemple 41.226.10.25/32). Vous la trouvez en cherchant « quelle est mon IP » dans votre navigateur. À défaut, 0.0.0.0/0 ouvre SSH au monde entier : pratique pour un test, à éviter en production.
8. Cliquez sur OK. La règle apparaît dans la liste et s'applique immédiatement.

Trois pièges fréquents dans les listes déroulantes :

• Protocol : choisissez Custom TCP Rule, pas All TCP ni All Proto, qui ouvriraient tous les ports.
• Direction : Egress ne sert à rien ici, le trafic sortant est déjà autorisé.
• Remote Type : CIDR filtre par adresse IP ; Security Group autorise les instances d'un autre groupe (utile entre un serveur web et une base de données).

Ajoutez de la même façon les règles utiles à votre service :

Étape 3 — Associer le groupe à votre instance

Un groupe de sécurité n'a aucun effet tant qu'il n'est pas attaché à une instance.

• À la création : dans l'onglet Network Config, cochez ssh-access dans la liste Security Group (en plus de default). Voir notre guide pour créer une instance cloud.
• Sur une instance existante : dans Compute → Instances, ouvrez le menu More de l'instance, puis l'action de gestion des groupes de sécurité, et ajoutez ssh-access. Le changement est immédiat.

Étape 4 — Se connecter en SSH avec votre clé SSH

Vérifiez d'abord les trois prérequis : l'instance est Active, elle possède une IP flottante (voir créer votre réseau privé et votre IP flottante), et le groupe ssh-access lui est associé.

Utilisez la clé SSH choisie (ou téléchargée) à la création de l'instance : c'est elle, et non un mot de passe, qui vous identifie.

Sur Linux ou macOS, protégez votre clé puis connectez-vous :

chmod 400 ~/Téléchargements/demo_key.pem
ssh -i ~/Téléchargements/demo_key.pem ubuntu@197.5.133.85

Sur Windows 10/11, ouvrez PowerShell (le client SSH est intégré) :

ssh -i C:\Users\vous\Downloads\demo_key.pem ubuntu@197.5.133.85

Le nom d'utilisateur dépend de l'image choisie, et c'est la deuxième erreur la plus fréquente : ce n'est jamais root.

Une fois connecté, passez administrateur avec sudo -i. Pour un dépannage sans réseau, l'action Console de la liste des instances reste disponible.

Dépannage : les messages d'erreur SSH et leur solution

Bonnes pratiques de sécurité

• Limitez SSH à votre IP (/32) plutôt qu'à 0.0.0.0/0 : les robots scannent le port 22 en permanence.
• Un groupe par rôle : ssh-access, web, db-internal. Combinez-les selon l'instance.
• Pour une base de données, utilisez comme source un autre groupe de sécurité plutôt qu'un CIDR : seuls vos serveurs web y accèdent.
• Ne supprimez pas les règles sortantes sans raison, sinon l'instance ne pourra plus se mettre à jour.
• Conservez votre clé privée en lieu sûr : FelCloud ne la stocke pas et ne peut pas la renvoyer.

Pour aller plus loin, la documentation officielle d'OpenStack Neutron détaille le fonctionnement des groupes de sécurité.

En résumé

Le groupe default laisse sortir votre instance mais bloque tout ce qui vient d'Internet. Pour vous connecter : créez un groupe de sécurité OpenStack dédié, ajoutez une règle TCP 22 limitée à votre IP, associez-le à l'instance, puis connectez-vous avec la bonne clé et le bon utilisateur. Quatre gestes, et l'erreur « Connection timed out » appartient au passé.