En ce qui concerne l'informatique à distance, SSH est l'un des protocoles les plus populaires et les plus sécurisés. SSH est un protocole réseau cryptographique qui établit une connexion sécurisée avec des appareils distants. Lors de la connexion à un appareil distant, un utilisateur peut exécuter des commandes sur le shell distant. SSH est très courant chez les administrateurs réseau et système.
Ce guide de type aide-mémoire présente un aperçu de SSH, quelques méthodes courantes de connexion avec SSH et diverses configurations SSH.
Aperçu de SSH
SSH est l'acronyme de Secure Shell. Certains appellent également SSH Secure Socket Shell. SSH est le moyen le plus courant d'accéder à un serveur distant. Lors de la connexion à un système distant à l'aide de SSH, vous vous connectez à un compte existant. Une fois connecté, vous aurez accès à une session shell. Toutes les commandes exécutées le seront sur la machine distante et le résultat sera affiché sur votre terminal local.
La connexion SSH suit un modèle client-serveur. Le système distant doit exécuter le démon SSH pour accepter les connexions SSH distantes. Le démon SSH écoute sur des ports spécifiques, authentifie les demandes de connexion et génère l'environnement approprié lorsque les conditions sont remplies.
Pour ce guide, nous avons configuré deux serveurs Ubuntu. Le serveur principal sera configuré pour se connecter au serveur secondaire. Le serveur secondaire sera configuré pour accepter les connexions SSH du serveur principal. Ces adresses IP de serveurs seront utilisées tout au long de ce guide :
-
Principal : 31.171.250.121
-
Secondaire : 31.171.250.130
Pour commencer, vous pouvez jeter un œil à nos guides détaillés sur comment utiliser SSH pour se connecter à un serveur distant sous Ubuntu et comment configurer votre serveur Linux pour utiliser l'authentification par clé SSH. Maintenant, commençons !
Authentification SSH
Il existe deux principaux types d'authentification SSH. La méthode traditionnelle consiste à utiliser un mot de passe. Elle est moins sécurisée et fortement déconseillée. La seconde méthode utilise les clés SSH. Les clés SSH offrent une sécurité très robuste et sont fortement recommandées.
Bien que l'authentification par mot de passe soit plus simple à comprendre et à configurer, elle est facilement exploitable. Par exemple, des robots automatisés peuvent utiliser la force brute pour s'introduire dans un système. Les clés SSH sont des clés cryptographiques. Chaque clé comporte deux parties – une clé privée et une clé publique. La clé publique peut être partagée n'importe où sans aucune inquiétude. Cependant, la clé privée doit rester protégée.
Pour utiliser les clés SSH comme méthode d'authentification, le système distant doit disposer d'une copie de la clé publique installée. Des copies des clés privée et publique doivent également être installées sur le système local. Par défaut, les clés publiques sont répertoriées dans le fichier suivant. Chaque utilisateur unique possède une copie unique de ce fichier :
|
1 |
~/.ssh/authorized_keys |
Voici comment fonctionne le processus d'authentification :
-
Le système client envoie une demande de connexion au système distant. Il indique également quelle clé SSH utiliser.
-
Le système distant vérifie si la clé publique est répertoriée dans authorized_keys.
-
Si la clé existe, une chaîne aléatoire est générée et chiffrée à l'aide de la clé publique. Le message chiffré ne peut être déchiffré qu'à l'aide de la clé privée.
-
Dès réception de la chaîne, le client la déchiffrera.
-
En combinant la chaîne et l'identifiant de session précédemment négocié, un hachage MD5 est généré. Le client envoie le hachage MD5 au système distant.
-
Le système distant connaît la chaîne aléatoire et l'identifiant de session. Si le hachage MD5 correspond, la connexion est autorisée.
Clés SSH
Dans ce guide, la clé SSH sera le point central de l'authentification. Cette section se concentrera donc sur la façon de travailler avec les clés SSH.
-
Générer une paire de clés SSH
Par défaut, un système Linux n'a pas de clé SSH installée. Cependant, le système peut contenir des clés SSH générées/installées précédemment. En supposant qu'il n'y ait pas de clé SSH antérieure, nous devons générer une nouvelle paire de clés SSH publique et privée. SSH prend en charge de nombreux algorithmes cryptographiques pour générer des clés SSH, par exemple RSA, DSA, ECDSA et EdDSA. RSA est l'algorithme par défaut et préféré.
-
Générer une paire de clés RSA normale
Pour générer une paire de clés SSH, exécutez la commande suivante :
|
1 |
ssh-keygen |
L'invite vous demandera où stocker la paire de clés. Comme mentionné, il s'agira d'une paire de clés RSA. Si aucune valeur n'est saisie, SSH l'enregistrera dans l'emplacement par défaut /home/demo/.ssh/id_rsa.
L'étape suivante consiste à saisir une phrase de passe. Il est recommandé d'utiliser une phrase de passe. La longueur de la phrase de passe est arbitraire. Elle ajoute une couche de sécurité. Cependant, SSH permet de générer des clés sans aucune phrase de passe. Appuyez simplement sur Entrée si vous souhaitez des clés sans phrase de passe.
Le résultat final fournit les informations clés suivantes :
-
L'emplacement de la clé privée ( /root/.ssh/id_rsa). Elle ne doit jamais être partagée.
-
L'emplacement de la clé publique ( /root/.ssh/id_rsa.pub). Elle peut être partagée en toute sécurité avec n'importe qui.
-
L'empreinte numérique de la clé.
-
Une image aléatoire de la clé. L'idée est que s'il y a un compromis avec les clés, vous pourrez probablement le savoir en remarquant tout changement dans l'image de la clé.
-
Générer une paire de clés RSA avec un nombre de bits différent
Par défaut, les clés SSH sont de 2048 bits. Pour la sécurité, cela est considéré comme suffisant. Cependant, nous pouvons spécifier manuellement d'utiliser un nombre de bits différent. Plus la valeur en bits est élevée, plus la clé est forte.
Exécutez la commande suivante pour générer une paire de clés SSH de 4096 bits. La plupart des serveurs prennent en charge les clés SSH de 4096 bits. Si la clé est trop grande, elle risque de ne pas être acceptée pour des raisons de protection contre les attaques DDoS :
|
1 |
ssh-keygen -b 4096 |
Comme nous avions déjà généré une paire de clés, SSH vous demandera s'il faut écraser la précédente. Le reste du processus est le même que pour la génération d'une paire de clés normale.
-
Modifier la phrase de passe de la clé privée
Nous pouvons modifier la phrase de passe de la clé privée. Le processus nécessite que vous connaissiez la phrase de passe actuelle. Pour modifier la phrase de passe, exécutez la commande suivante :
|
1 |
ssh-keygen -p |

La commande vous invitera à saisir l'emplacement de la clé privée. Appuyez sur Entrée si la clé est stockée à l'emplacement par défaut. Saisissez la phrase de passe actuelle. Si elle est acceptée, vous pourrez alors en désigner une nouvelle.
-
Afficher l'empreinte numérique d'une clé SSH
Chaque paire de clés SSH partage une empreinte cryptographique. Cette empreinte peut être utilisée pour identifier des clés uniques. Cela peut être utile dans de nombreuses situations. Exécutez la commande suivante pour vérifier l'empreinte d'une clé SSH :
|
1 |
ssh-keygen -l |

Saisissez l'emplacement de la clé. Appuyez sur Entrée si la clé est stockée à l'emplacement par défaut.
Copier la clé publique
La paire de clés SSH est prête à sécuriser les connexions distantes. Pour que le système distant accepte la clé SSH pour l'authentification, il doit disposer d'une copie de la clé publique. Il existe plusieurs façons de copier la clé publique sur le serveur distant.
-
Utiliser ssh-copy-id
L'outil ssh-copy-id fait partie du paquet OpenSSH. C'est le moyen par défaut de copier la clé publique SSH. C'est simple et facile à utiliser. Exécutez la commande suivante pour transférer une copie de la clé publique :
|
1 |
ssh-copy-id <username>@<secondary_server_ip> |

Vous avez besoin du mot de passe du compte utilisateur distant pour terminer le processus. En cas de succès, un message de réussite s'affichera.
-
Utiliser une connexion SSH
Si l'utilisation de l'outil ssh-copy-id n'est pas disponible mais que le serveur principal peut se connecter au serveur secondaire via SSH, nous pouvons alors utiliser une autre astuce pour copier la clé. Il s'agit de rediriger le contenu de la clé publique via la commande SSH vers le côté distant. Notez que si le répertoire ~/.ssh n'existe pas sur le système distant, cela risque de ne pas fonctionner :
|
1 |
cat ~/.ssh/id_rsa.pub | ssh <username>@<secondary_server_ip> "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys" |
-
Copier manuellement
Si une connexion distante n'est pas possible, le seul processus restant consiste à ajouter manuellement la clé publique au serveur distant. Tout d'abord, récupérez le contenu de la clé publique :
|
1 |
cat ~/.ssh/id_rsa.pub |
Sur le serveur distant, placez la clé à l'emplacement approprié :
|
1 2 3 |
mkdir -pv ~/.ssh echo <public_key> >> ~/.ssh/authorized_clés |
Utiliser SSH
Maintenant que la clé publique est configurée, nous sommes prêts à utiliser SSH pour nous connecter à distance.
-
Connexion à un système distant
La première étape consiste à apprendre à se connecter au système distant à l'aide de SSH. Cela suppose que le système local et le système distant autorisent tous deux le trafic SSH. Pour vous connecter au système distant, saisissez ce qui suit :
|
1 |
ssh <secondary_server_ip> |

Pour vous connecter à un utilisateur spécifique sur le serveur distant, utilisez plutôt la structure suivante :
|
1 |
ssh <username>@<secondary_server_ip> |

S'il s'agit de la première connexion au serveur, SSH peut afficher un avertissement. Saisissez yes pour poursuivre la connexion. Si le compte distant est protégé par un mot de passe, vous devrez saisir le mot de passe. Si la clé SSH est protégée par une phrase secrète, vous devrez également saisir la phrase secrète.
-
Connexion à un port différent
Par défaut, SSH fonctionne sur le port 22. Le client SSH supposera la valeur de port par défaut lors de la connexion au système distant. Cependant, si le système distant écoute sur un port différent pour le trafic SSH, cela ne fonctionnera pas. Dans une telle situation, nous devons déclarer manuellement le numéro de port. Pour déclarer le port spécifique, utilisez l'option -p :
|
1 |
ssh -p <port> <username>@<secondary_server_ip> |
Déclarer manuellement le port à chaque fois est contre-productif. Nous pouvons modifier la valeur du port par défaut de manière permanente. Pour ce faire, ouvrez le fichier de configuration SSH. Si le fichier n'existe pas, la commande suivante le créera :
|
1 |
nano ~/.ssh/config |
Ensuite, ajoutez les lignes suivantes :
|
1 2 3 4 5 |
Host <remote_alias> HostName <remote_hostname> Port <port_value> |
-
Exécution de commandes sur le serveur distant
Maintenant que la connexion est établie, toute commande que vous exécutez sur le terminal local sera transmise au serveur distant. Tout résultat généré sera envoyé au terminal local.
S'il s'agit d'une seule commande à exécuter, nous pouvons la lancer sans effectuer de connexion SSH complète. Il suffit de déclarer la commande après l'instruction de connexion SSH :
|
1 |
ssh <username>@<secondary_server_ip> <command_to_run> |
-
Ajout d'une clé à un agent SSH
Si la clé SSH possède une phrase secrète, vous devrez la saisir à chaque connexion au système distant. Répéter cette opération est contre-productif. Nous pouvons laisser un agent SSH s'en charger. Il s'agit d'un petit utilitaire qui stocke la clé privée après la saisie de la phrase secrète. La clé privée sera disponible pendant la session du terminal. Pour démarrer l'agent SSH, exécutez la commande suivante :
|
1 |
eval $(ssh-agent) |

Le programme s'exécute en arrière-plan. Il vous suffit d'ajouter votre clé privée à l'agent. Exécutez la commande suivante :
|
1 |
ssh-add |

Saisissez la phrase secrète pour terminer l'opération.
-
Transfert des identifiants SSH
Nous pouvons également configurer SSH pour se connecter d'un serveur à un autre sans mot de passe. Cela peut être très efficace, en particulier lorsque l'on travaille avec de nombreux serveurs distants. Pour y parvenir, nous devons transférer les identifiants SSH. Le transfert des identifiants SSH nécessite que le serveur distant soit configuré pour accepter une connexion depuis la machine/le serveur local. Ensuite, il vous suffit de vous connecter au premier serveur en utilisant l'option -A. Elle transfère vos identifiants aux serveurs pour la session en cours :
|
1 |
ssh -A <username>@<secondary_server_ip> |
Configurations du serveur distant
Cette section contient certaines des configurations courantes côté serveur pour vous aider à améliorer les réponses du serveur et la sécurité des connexions.
-
Désactivation de l'authentification par mot de passe
Si les clés SSH sont configurées et que la connexion SSH fonctionne comme prévu, il est alors possible de désactiver l'authentification par mot de passe en toute sécurité. La configuration suivante cessera de demander un mot de passe lorsqu'un utilisateur se connecte via SSH. Sur le serveur distant, ouvrez le sshd_config fichier avec le privilège root/sudo :
|
1 |
sudo nano /etc/ssh/sshd_config |
Ensuite, recherchez l'entrée PasswordAuthentication. Si la ligne est commentée, décommentez-la. Modifiez la valeur par no :
|
1 |
PasswordAuthentication no |

Enregistrez le fichier et fermez l'éditeur. Pour que les modifications prennent effet, redémarrez le service SSH :
|
1 |
sudo service ssh restart |
Si le système est CentOS/Fedora, utilisez plutôt la commande suivante :
|
1 |
sudo service sshd restart |
-
Changer le port SSH
Comme mentionné précédemment, SSH utilise le port 22 pour échanger le trafic SSH. Cependant, selon certains administrateurs système, il est préférable d'attribuer un port différent pour SSH. Cela peut aider à lutter contre les bots automatisés qui inondent le port. Pour changer le port d'écoute de SSH, ouvrez le fichier sshd_config :
|
1 |
sudo nano /etc/ssh/sshd_config |
Recherchez l'entrée Port. Si elle est commentée, décommentez-la. Ensuite, modifiez la valeur par une autre valeur. La valeur du port est un entier non signé de 16 bits (0-65535) :
|
1 |
Port 1024 |

Enregistrez le fichier et fermez l'éditeur. Pour appliquer la modification, redémarrez le démon SSH :
|
1 |
sudo service ssh restart |
Sur CentOS/Fedora, exécutez plutôt la commande suivante :
|
1 |
sudo service sshd restart |
-
Limitation des utilisateurs
Nous pouvons configurer quels comptes d'utilisateurs peuvent se connecter en utilisant SSH. Cela implique également de modifier le fichier sshd_config . Ouvrez le fichier avec les privilèges sudo/root :
|
1 |
sudo nano /etc/ssh/sshd_config |
Recherchez l'entrée AllowUsers. Ajoutez les utilisateurs autorisés :
|
1 |
AllowUsers <user_1> <user_2> |

Enregistrez le fichier et fermez l'éditeur. Redémarrez le démon SSH pour que les modifications prennent effet :
|
1 |
sudo service ssh restart |
Sur CentOS/Fedora, exécutez plutôt la commande suivante :
|
1 |
sudo service sshd restart |
-
Limitation des groupes
Tout comme pour la limitation des utilisateurs, nous pouvons également déterminer quel groupe d'utilisateurs peut se connecter au système via SSH. Ouvrez le fichier sshd_config :
|
1 |
sudo nano /etc/ssh/sshd_config |
Utilisez l'entrée AllowGroups pour ajouter un groupe d'utilisateurs spécifique qui peut utiliser SSH :
|
1 |
AllowGroups <user_group> |

Enregistrez le fichier et fermez l'éditeur. Redémarrez le démon SSH pour que les modifications prennent effet :
|
1 |
sudo service ssh restart |
Pour CentOS/Fedora, exécutez plutôt la commande suivante :
|
1 |
sudo service sshd restart |
Notez que si un utilisateur est ajouté ou supprimé du groupe d'utilisateurs, le démon SSH doit être redémarré. Sinon, les modifications du groupe ne seront pas effectives.
-
Désactiver la connexion root
Si vous avez accès à un utilisateur disposant des privilèges sudo, il est alors recommandé de désactiver la connexion root via SSH. Ouvrez le fichier sshd_config :
|
1 |
sudo nano /etc/ssh/sshd_config |
Modifiez la valeur de l'entrée PermitRootLogin par no :
|
1 |
PermitRootLogin no |

Enregistrez le fichier et fermez l'éditeur. Redémarrez le démon SSH pour que la modification prenne effet :
|
1 |
sudo service ssh restart |
Sur CentOS/Fedora, exécutez plutôt la commande suivante :
|
1 |
sudo service sshd restart |
-
Redirection de l'affichage des applications X
Le démon SSH peut également rediriger l'affichage des applications X du serveur vers le client. Pour que cela fonctionne, cependant, le système distant doit avoir un système X Window configuré. Cette fonctionnalité doit également être activée dans la configuration SSH. Ouvrez le fichier de configuration SSH :
|
1 |
sudo nano /etc/ssh/sshd_config |
Modifiez la valeur de la directive X11Forwarding par yes :
|
1 |
X11Forwarding yes |

Enregistrez le fichier et fermez l'éditeur. Redémarrez le démon SSH pour que la modification prenne effet :
|
1 |
sudo service ssh restart |
Sur CentOS/Fedora, exécutez plutôt la commande suivante :
|
1 |
sudo service sshd restart |
Configurations du client
Dans cette section, découvrez quelques-unes des configurations courantes sur le client SSH.
-
Informations de connexion spécifiques au serveur
Sur le système local, nous pouvons définir les spécificités d'une connexion distante. Toutes les informations sont stockées dans le fichier de configuration situé à l'adresse ~/.ssh/config:
|
1 |
nano ~/.ssh/config |
Chaque bloc de système distant est signalé par le mot-clé Host suivi d'un alias. Toutes les directives spécifiques au système vont ici. Lors de la connexion au système distant, SSH les appliquera automatiquement. Pour une explication complète et détaillée de la configuration, consultez la page de manuel :
|
1 |
man ssh_config |

L'entrée pour une connexion distante suivra la structure suivante :
|
1 2 3 |
Host <remote_hostname> <directive> <value> |
-
Délai d'attente de la connexion
Il se peut que vous soyez déconnecté des sessions SSH avant d'être prêt à effectuer une action. Si le client n'envoie aucun paquet au serveur distant, la connexion expire après un certain temps. Pour éviter cela, nous pouvons configurer le client local pour qu'il envoie un paquet de temps en temps afin de maintenir la connexion active.
Ouvrez le fichier de configuration local :
|
1 |
nano ~/.ssh/config |
Sous l'entrée de connexion distante, ajoutez la directive ServerAliveInterval suivie de l'intervalle de paquet en secondes :
|
1 |
ServerAliveInterval 120 |

Enregistrez le fichier et fermez l'éditeur.
-
Désactivation de la vérification de l'hôte
Par défaut, lors de chaque tentative de connexion à un nouveau serveur, le client SSH signale l'empreinte numérique du démon SSH distant. C'est une fonctionnalité utile pour vérifier l'authenticité de l’hôte. Si un acteur malveillant tente d'usurper l'identité de l'hôte distant, celui-ci apparaîtra comme un nouveau serveur.
Désactiver cette fonctionnalité peut représenter un risque de sécurité majeur. En général, il est recommandé de laisser cette option activée. Dans certaines situations, cependant, désactiver la vérification de l'hôte peut s'avérer pratique. Ouvrez le fichier de configuration :
|
1 |
nano ~/.ssh/config |
Sous la section de l'hôte distant, ajoutez les directives suivantes :

|
1 2 3 |
StrictHostKeyChecking no UserKnownHostsFile /dev/null |
La première directive désactivera l'ajout automatique de nouveaux hôtes à la liste des hôtes connus, stockée dans le fichier known_hosts. La deuxième directive permet de ne pas avertir en cas de modification. Enregistrez le fichier et fermez l'éditeur.
-
Multiplexage SSH sur une seule connexion TCP
Parfois, l'établissement d'une connexion TCP peut prendre un certain temps. S'il est nécessaire d'établir plusieurs connexions vers la même machine, le multiplexage est une excellente fonctionnalité dont vous pouvez tirer parti. Le multiplexage SSH permet d'utiliser la même connexion TCP pour plusieurs sessions SSH. Cela réduit une partie de la charge de travail requise pour établir de nouvelles sessions. Limiter le nombre de connexions peut également aider.
Nous pouvons configurer manuellement une connexion multiplexée ou laisser SSH l'utiliser dès qu'elle est disponible. Ici, nous allons configurer SSH pour suivre la deuxième méthode. Ouvrez le fichier de configuration SSH :
|
1 |
nano ~/.ssh/config |
Ajoutez une définition d'hôte générique (wildcard) en haut du fichier. Cela garantit que le prochain ensemble de directives sera appliqué à toutes les connexions distantes. Ajoutez les directives suivantes :
|
1 2 3 4 5 |
ControlMaster auto ControlPath ~/.ssh/multiplex/%r@%h:%p ControlPersist 1 |

La première directive indique à SSH d'utiliser automatiquement le multiplexage dès qu'il est disponible. La deuxième directive établit le chemin d'accès au socket de contrôle. Ce socket sera créé lors de l'établissement de la première session. Les sessions suivantes suivront ce socket.
La dernière directive indique à SSH de laisser la connexion maître initiale en arrière-plan. Elle signifie également que les connexions TCP se termineront automatiquement une seconde après la dernière session SSH. Ensuite, créez le répertoire que nous avons déclaré dans le fichier de configuration :
|
1 |
mkdir -pv ~/.ssh/multiplex |
Enfin, le multiplexage devrait être actif.
Codes d'échappement SSH
Après avoir établi une connexion, il existe des moyens de contrôler le comportement de la connexion à l'aide de codes d'échappement.
-
Forcer les déconnexions
Êtes-vous bloqué sur une session SSH ? Les sessions SSH sont généralement gérées par le serveur. Si le serveur rencontre des problèmes, rester bloqué sur une session SSH inactive peut être frustrant. Heureusement, OpenSSH propose des commandes utiles pour gérer l'état de la connexion depuis le côté client.
Appuyez sur Entrée à deux reprises. Ensuite, entrez la commande suivante :
|
1 |
~. |
![]()
Ici, ~ est le caractère de contrôle. Après avoir exécuté cette commande depuis le client, la connexion devrait se fermer immédiatement.
-
Session SSH en arrière-plan
Nous pouvons également mettre une session SSH en arrière-plan. Une fois mise en arrière-plan, vous reviendrez à la session shell normale. Une fois votre travail terminé, vous pourrez à nouveau revenir au shell SSH. Notez que vous devez disposer d'une configuration de délai d'attente appropriée pour éviter une expiration de session pendant que la session SSH reste en arrière-plan. Pour mettre une session SSH en arrière-plan, entrez le caractère de contrôle suivi de Ctrl + Z:
|
1 |
~<Ctrl + Z> |

S'il s'agissait de votre tâche en arrière-plan la plus récente, vous pouvez alors la réactiver à l'aide de la commande suivante :
|
1 |
fg |
S'il y a plusieurs tâches en arrière-plan, nous pouvons alors les identifier à partir de la liste des tâches :
|
1 |
jobs |

Pour ramener la tâche cible au premier plan, notez la valeur de la tâche dans la première colonne. Ensuite, exécutez la commande suivante :
|
1 |
fg %<job_value> |
-
Modifier la configuration de la redirection de port
En utilisant le mécanisme de contrôle, nous pouvons modifier les règles de redirection de port à la volée. Une fois la connexion établie, nous pouvons créer ou supprimer des règles de redirection de port. Cela fait partie de l'interface en ligne de commande SSH.
Pour accéder à l'interface en ligne de commande SSH, exécutez la commande :
|
1 |
~C |
![]()
Pour lister les options disponibles, entrez la commande suivante :
|
1 |
-h |
Si la sortie est trop minimale, essayez d'augmenter le niveau de verbosité à l'aide de la commande de contrôle suivante :
|
1 |
~v |
Maintenant, exécutez à nouveau la commande -h :
|
1 |
-h |

Comme l'explique la sortie, il est assez simple de mettre en œuvre n'importe quelle redirection de port avec une simple commande. Par exemple, un tunnel peut également être détruit à l'aide de la commande kill, représentée par K dans la liste des commandes.
Dernières réflexions
Il est très courant de rencontrer SSH. C'est pourquoi apprendre SSH est très utile. Notre aperçu complet de SSH couvre les configurations SSH les plus importantes que les utilisateurs doivent connaître pour utiliser SSH au quotidien. Une fois maîtrisé, vous devriez être capable de travailler avec presque toutes les configurations de serveur SSH.
Bonne informatique !
Commentaires
Aucun commentaire pour l'instant. Soyez le premier.