Comprendre SSH en 30 min : Tutoriel complet et sécurisation

Vous souhaitez comprendre ce qu’est SSH et pourquoi il est devenu incontournable pour administrer un serveur, un ordinateur à distance et comment les hackers interagissent avec ? Le protocole SSH (Secure Shell) est aujourd’hui l’outil de référence pour établir des connexions sécurisées, transférer des fichiers ou encore protéger vos échanges contre les pirates. Mais mal configuré, il peut aussi devenir une porte d’entrée idéale pour des attaques et mettre en danger vos données.

Dans ce tutoriel complet, nous allons vous expliquer simplement le fonctionnement de SSH, ses principaux usages, les risques liés à une mauvaise configuration et surtout les bonnes pratiques à appliquer pour sécuriser vos accès.

Que vous soyez débutant ou administrateur expérimenté, vous trouverez ici toutes les clés pour utiliser SSH efficacement et protéger vos serveurs contre les cybermenaces.

Qu’est-ce que SSH ?

SSH, pour Secure Shell, est un protocole qui permet d’ouvrir une session chiffrée entre une machine cliente et une machine distante (un serveur, un ordinateur, …). Ce chiffrement protège vos identifiants, vos commandes et vos fichiers contre l’interception.

Dans la pratique, SSH est le couteau suisse de l’administration système : il sert à se connecter, transférer des fichiers, créer des tunnels sécurisés et automatiser des déploiements.

Avant SSH, beaucoup utilisaient Telnet ou FTP en clair. Ces protocoles exposaient les mots de passe au moindre écouteur réseau. SSH a résolu ce problème en chiffrant bout à bout la communication. Vous pouvez l’utiliser sous Linux, macOS et Windows, aussi bien pour votre serveur que pour un poste de travail. Bien configuré, SSH est très sûr. Mal configuré, il peut devenir une porte d’entrée pour un attaquant et transformer votre serveur en relais d’attaques.

Ce tutoriel vous accompagne étape par étape pour comprendre SSH, l’installer, l’utiliser, le sécuriser, et réagir en cas d’incident.

À la fin de ce tutoriel, vous saurez générer des clés, vous connecter sans mot de passe, durcir la configuration de votre service SSH, transférer des fichiers de manière sûre, mettre en place des tunnels, surveiller les connexions et appliquer les bonnes pratiques indispensables. L’objectif est de rester simple et clair, sans jargon inutile, tout en vous donnant des commandes concrètes et des explications courtes pour chaque action.

Les bases d’une connexion SSH

Le principe de SSH est d’établir une session chiffrée entre un client et un serveur. Le serveur fait tourner un service, souvent sshd (OpenSSH Server), qui écoute par défaut sur le port 22. Le client initie la connexion et s’authentifie soit avec un mot de passe, soit avec une clé. Une fois la session ouverte, vous tapez des commandes à distance comme si vous étiez devant la machine.

Pour vérifier si le serveur écoute, vous pouvez utiliser :

# Sur le serveur
sudo systemctl status ssh
# ou
sudo service ssh status
# Vérifier le port
sudo ss -tulnp | grep ssh

Pour vous connecter depuis votre machine locale, utilisez la forme la plus simple :

ssh utilisateur@adresse_du_serveur

Lors de la première connexion, SSH vous demande de vérifier l’empreinte de la clé du serveur. Cette étape protège contre les attaques de type homme-du-milieu (Man-in-the-middle). Si l’empreinte correspond à ce que votre hébergeur documente, validez. SSH stocke ensuite cette information dans ~/.ssh/known_hosts pour éviter les alertes à chaque connexion.

Vous pouvez préciser un port personnalisé si le serveur n’écoute pas sur 22 :

ssh -p 2222 utilisateur@adresse_du_serveur

Vous pouvez aussi activer le mode verbeux pour diagnostiquer une connexion capricieuse :

ssh -vvv utilisateur@adresse_du_serveur

Cette commande affiche les étapes de négociation cryptographique, d’authentification et d’ouverture de session. Elle est précieuse pour comprendre pourquoi une clé n’est pas acceptée ou pourquoi le serveur refuse votre connexion.

Prenons un exemple concret pour que ce soit clair :

• Votre nom d’utilisateur sur le serveur est alban.
• L’adresse IP du serveur est 192.168.1.100.

La commande SSH serait alors :

ssh [email protected]

Déroulement

Vous tapez la commande dans votre terminal. La première fois, le terminal vous demandera de confirmer l’empreinte du serveur :

The authenticity of host '192.168.1.100 (192.168.1.100)' can't be established.
ECDSA key fingerprint is SHA256:xxxxxxxxxxxx.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Vous tapez yes et appuyez sur Entrée. Ensuite, on vous demande le mot de passe pour l’utilisateur alban sur ce serveur :

[email protected]'s password:

Vous le tapez (rien ne s’affiche pour des raisons de sécurité) et appuyez sur Entrée. Une fois connecté, vous verrez le prompt du serveur :

alban@serveur:~$

À partir de là, vous pouvez exécuter des commandes directement sur ce serveur distant, comme si vous étiez devant.

Ce que permet SSH

SSH n’est pas qu’une console distante. C’est une boîte à outils.

Vous pouvez transférer des fichiers de manière sécurisée. La commande scp copie un fichier ou un dossier entre votre machine et le serveur, en réutilisant le tunnel chiffré de SSH. Par exemple, pour envoyer un fichier local vers le serveur :

scp fichier.txt utilisateur@adresse_du_serveur:/home/utilisateur/

Pour récupérer un dossier du serveur vers votre machine, avec copie récursive :

scp -r utilisateur@adresse_du_serveur:/var/logs ./logs_serveur

Vous pouvez préférer rsync pour synchroniser des dossiers de façon efficace. rsync ne transfère que les différences, ce qui est plus rapide et plus économe en bande passante :

rsync -avz ./site/ utilisateur@adresse_du_serveur:/var/www/site/

SSH sait aussi créer des tunnels chiffrés. Un tunnel local redirige un port de votre machine vers un service distant accessible depuis le serveur. C’est utile pour consulter en sécurité un service interne (par exemple une base de données) sans l’exposer sur Internet.

# Tunnel local : vous ouvrez http://localhost:8080 chez vous,
# SSH transporte et cible le port 80 du serveur
ssh -L 8080:localhost:80 utilisateur@adresse_du_serveur

Un tunnel distant fait l’inverse : il ouvre un port sur le serveur qui pointe vers un service local de votre poste, pratique pour partager un service de développement sans l’exposer en direct.

# Tunnel distant : le port 9000 du serveur pointe vers votre port local 3000
ssh -R 9000:localhost:3000 utilisateur@adresse_du_serveur

Un proxy dynamique transforme votre session SSH en proxy SOCKS. Vous pouvez alors router le trafic d’un navigateur à travers le serveur, pour tester l’accès depuis un autre pays par exemple.

ssh -D 1080 utilisateur@adresse_du_serveur

Enfin, SSH est la fondation de nombreuses automatisations. Les déploiements, sauvegardes et tâches planifiées s’appuient sur des clés et des commandes non interactives, ce qui permet d’exécuter des actions fiables et reproductibles.

Les méthodes d’authentification

La sécurité d’une connexion SSH repose sur l’authentification. Deux approches existent.

• Avec un mot de passe, vous saisissez votre secret à chaque connexion. C’est simple, mais exposé aux attaques par force brute et au vol de mots de passe. Pour un serveur exposé à Internet, cette méthode est à éviter.

• Avec une clé SSH, vous utilisez une paire cryptographique : une clé privée, à garder secrète sur votre machine, et une clé publique, à copier sur le serveur. Lors de la connexion, le serveur envoie un défi que seule votre clé privée peut résoudre. Cette méthode est beaucoup plus résistante aux attaques automatiques.

Pour générer une clé moderne et rapide, privilégiez Ed25519 :

ssh-keygen -t ed25519 -C "[email protected]"

Si vous devez rester compatible avec des systèmes anciens, vous pouvez générer une clé RSA robuste :

ssh-keygen -t rsa -b 4096 -C "[email protected]"

Le programme vous demande où stocker la clé ; laissez le chemin par défaut ~/.ssh/id_ed25519 ou ~/.ssh/id_rsa. Il vous invite ensuite à définir une passphrase. Mettez-en une : si quelqu’un copie votre clé privée, la passphrase l’empêchera de l’utiliser.

Copiez ensuite la clé publique sur le serveur :

ssh-copy-id utilisateur@adresse_du_serveur

À défaut, copiez manuellement le contenu de ~/.ssh/id_ed25519.pub dans le fichier ~/.ssh/authorized_keys du compte distant. Assurez-vous des bons droits :

# Sur le serveur
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Pour éviter de retaper la passphrase à chaque connexion, utilisez l’agent SSH qui garde la clé en mémoire chiffrée pendant votre session utilisateur.

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

Vous pouvez également créer un fichier de configuration côté client pour simplifier vos commandes. Créez ~/.ssh/config et déclarez des hôtes :

Host prod
    HostName adresse_du_serveur
    User utilisateur
    Port 22
    IdentityFile ~/.ssh/id_ed25519

Ensuite, connectez-vous simplement :

ssh prod

Cette configuration rend l’usage au quotidien plus confortable et réduit les erreurs de frappe.

Qu’est ce qu’une passphrase ?

Une passphrase est essentiellement un mot de passe long et sécurisé, souvent utilisé pour protéger une clé privée SSH ou d’autres clés de chiffrement.

• Différence avec un mot de passe classique :
  • Un mot de passe est souvent court (6 à 12 caractères).
  • Une passphrase est plus longue, souvent composée de plusieurs mots ou d’une phrase entière, ce qui la rend beaucoup plus difficile à deviner ou à casser par force brute.
• Utilisation en SSH :
  • Quand vous créez une paire de clés SSH (ssh-keygen), on vous demande de mettre une passphrase.
  • La clé privée sur votre ordinateur sera chiffrée avec cette passphrase.
  • Même si quelqu’un vole votre clé privée, il ne pourra pas l’utiliser sans connaître la passphrase.

Exemple simple :
Au lieu d’un mot de passe classique comme :

azerty123 

Une passphrase pourrait être :

MonChienMangeDesBiscuitsEn2025! 

C’est long, mémorisable, mais très sécurisé.

Comment les pirates utilisent SSH

Les pirates savent que beaucoup de serveurs exposent SSH et que certains sont mal configurés. Ils scannent Internet pour repérer les ports ouverts, testent des combinaisons d’identifiants, exploitent des mots de passe faibles et cherchent des clés mal protégées. Ils profitent aussi des configurations laxistes : autorisation du compte root, absence de pare-feu, absence de mécanismes anti-bruteforce, protocole ou algorithmes faibles non désactivés.

Une attaque par force brute sur un mot de passe, c’est quand quelqu’un essaie de deviner un mot de passe en testant toutes les combinaisons possibles, une par une, jusqu’à trouver la bonne. C’est un peu comme essayer chaque clé d’un trousseau pour ouvrir une porte. Plus le mot de passe est court ou simple, plus il est facile à trouver. À l’inverse, un mot de passe long et complexe prendrait beaucoup de temps, voire des années, pour être découvert par ce type d’attaque.

Il existe des outils et des logiciels qui permettent d’automatiser les attaques par force brute, mais il faut être très clair : les utiliser contre des systèmes dont vous n’avez pas la permission est illégal et puni par la loi.

Pour comprendre comment ça fonctionne :

• Ces outils testent très rapidement des milliers ou millions de combinaisons de mots de passe.
• Certains utilisent des dictionnaires de mots de passe courants pour accélérer le processus (on appelle ça une attaque par dictionnaire).
• D’autres peuvent combiner lettres, chiffres et symboles pour tester toutes les combinaisons possibles.

Exemples d’outils connus utilisés légalement à des fins de test de sécurité : Hydra, John the Ripper, Hashcat, etc..

Dans un contexte légal, ces outils sont utilisés par les pentesters ou les administrateurs pour vérifier la sécurité des mots de passe de leur propre système.

Une fois connectés, ils agissent comme des utilisateurs légitimes. Ils installent des outils pour rester discrets et persistants. Ils ajoutent leurs clés dans authorized_keys, créent de nouveaux comptes, plantent des cronjobs, modifient des services, et utilisent votre machine pour lancer des scans, attaquer d’autres serveurs, miner de la cryptomonnaie ou exfiltrer des données.

Un cronjob, c’est un programme ou une commande que l’on configure pour s’exécuter automatiquement à des moments précis sur un serveur. Dans le hacking, un cronjob peut être utilisé pour lancer régulièrement une action malveillante, comme envoyer des données volées, essayer de deviner des mots de passe, ou maintenir un accès à un système compromis. En gros, c’est un moyen d’automatiser des tâches répétitives sans avoir besoin d’être connecté en permanence.

Ils peuvent également transformer votre serveur en relais. Ils se connectent d’abord chez vous via SSH, puis utilisent votre adresse IP pour attaquer d’autres cibles, ce qui brouille les pistes et expose votre réputation. Les journaux des victimes remonteront votre adresse, pas la leur, ce qui peut déclencher des blocages ou des signalements par les fournisseurs de services.

Il arrive aussi que l’attaque démarre ailleurs. Un compte de développeur compromis sur un laptop peut livrer une clé privée non protégée. L’attaquant réutilise la clé pour se connecter à vos serveurs. D’où l’importance de sécuriser les postes clients, de mettre une passphrase sur les clés et de révoquer rapidement une clé perdue ou suspecte.

Outils de travail et de vérification utiles au quotidien

Pour travailler efficacement avec SSH, quelques commandes et habitudes vous feront gagner du temps.

Commencez par surveiller qui est connecté et ce qui se passe. Les commandes who et w affichent les sessions actives. lastmontre l’historique des connexions. Les journaux d’authentification se trouvent dans /var/log/auth.log sur Debian/Ubuntu et dans le journal système sur d’autres distributions.

who
w
last -n 10
sudo journalctl -u ssh --since "today"

Vérifiez les ports en écoute et les processus associés. ss et lsof sont précieux pour repérer un service inattendu.

sudo ss -tulnp
sudo lsof -i -P -n | grep LISTEN

Pour auditer votre configuration SSH, l’outil ssh-audit peut identifier des algorithmes faibles ou des options obsolètes. Installez-le via votre gestionnaire de paquets ou un environnement Python, exécutez-le contre votre serveur et suivez ses conseils.

Même sans cet outil, vérifier votre sshd_config contre une liste d’algorithmes modernes reste un bon réflexe.

Pour simplifier l’usage côté client, organisez votre ~/.ssh/config avec des alias par environnement, des clés dédiées par projet et des sauts via bastion si nécessaire. Le saut de machine, appelé ProxyJump, permet de n’exposer SSH qu’un seul point d’entrée.

Host bastion
    HostName bastion.exemple.com
    User admin
    IdentityFile ~/.ssh/id_ed25519

Host prod-app*
    User deploy
    ProxyJump bastion
    IdentityFile ~/.ssh/id_ed25519_projetA

Avec cette configuration, vous pouvez rejoindre prod-app01 via le bastion sans ouvrir de ports sur toutes les machines internes.

Pour transférer des dossiers complexes avec permissions, combinez tar et SSH pour des migrations propres :

# Sur la machine source
tar czf - /var/www/site | ssh deploy@serveur 'tar xzf - -C /var/www/'

Pour des sauvegardes automatisées, associez rsync et des clés limitées à une commande, comme montré plus haut. Programmez une tâche cron côté serveur de sauvegarde et stockez les archives avec des dates, puis vérifiez régulièrement que la restauration fonctionne.

Si vous gérez Windows, utilisez le client OpenSSH inclus dans les versions récentes ou l’outil PuTTY si nécessaire. Sous macOS et Linux, le client OpenSSH est déjà disponible. Pour Windows Server, vous pouvez activer le service OpenSSH Server via les fonctionnalités facultatives, puis appliquer les mêmes principes de sécurité que sous Linux.

Tunnels SSH et cas d’usage concrets

Un tunnel SSH encapsule une connexion vers un service dans le canal chiffré entre votre machine et le serveur. Trois types existent : local, distant et dynamique.

Un tunnel local vous permet d’accéder à un service distant comme s’il tournait sur votre machine. Par exemple, si une base MySQL écoute sur le serveur mais n’est pas exposée publiquement, vous pouvez ouvrir un tunnel local et pointer votre client MySQL vers localhost.

ssh -L 3307:localhost:3306 admin@serveur-base

Votre client se connecte à 127.0.0.1:3307, SSH transporte le flux vers localhost:3306 sur le serveur, et vous n’avez rien ouvert sur Internet. C’est simple et sûr.

Un tunnel distant est utile lorsque vous souhaitez accéder à un service tournant sur votre machine locale depuis un serveur. C’est courant pour partager un serveur de développement vers une machine distante sans exposer votre poste sur le réseau.

ssh -R 8081:localhost:3000 admin@serveur

Ici, serveur:8081 redirige vers localhost:3000 sur votre poste. C’est pratique pour montrer un prototype à un collègue connecté au serveur. Ne laissez pas ce type de tunnel ouvert inutilement ; fermez la session quand vous avez fini.

Un proxy dynamique transforme votre client SSH en proxy SOCKS, ce qui vous permet de router des applications réseau à travers le serveur. Configurez votre navigateur pour utiliser localhost:1080 comme proxy SOCKS et tout le trafic du navigateur passe par le serveur.

ssh -D 1080 admin@serveur

Dans tous les cas, souvenez-vous que le forwarding peut être désactivé côté serveur avec AllowTcpForwarding no si vous ne l’utilisez pas, ce qui limite une surface d’attaque. Si vous avez besoin de forwarding, ouvrez-le seulement sur les comptes concernés et surveillez les usages.

Transfert de fichiers sécurisé : SCP, SFTP et rsync

Vous avez trois approches principales pour déplacer des fichiers avec SSH.

Des formations informatique pour tous !

Débutant ou curieux ? Apprenez le développement web, le référencement, le webmarketing, la bureautique, à maîtriser vos appareils Apple et bien plus encore…

Formateur indépendant, professionnel du web depuis 2006, je vous accompagne pas à pas et en cours particulier, que vous soyez débutant ou que vous souhaitiez progresser. En visio, à votre rythme, et toujours avec pédagogie.

Découvrez mes formations Qui suis-je ?

scp est direct et simple. Il copie des fichiers ou des dossiers d’un point A à un point B. Il ne gère pas la reprise sur erreur ni la synchronisation intelligente. Pour envoyer un fichier avec progression :

scp -v fichier.iso admin@serveur:/srv/isos/

rsync est l’outil idéal pour synchroniser des répertoires. Il ne transfère que les différences. Pour cloner un site :

rsync -avz --delete ./site/ admin@serveur:/var/www/site/

L’option --delete supprime côté serveur ce qui n’existe plus côté source, ce qui garde les deux côtés identiques. Utilisez-la avec prudence et commencez par un --dry-run pour simuler l’opération.

SFTP est un sous-système de SSH offrant un mode interactif et des clients graphiques. Vous pouvez ouvrir une session SFTP :

sftp admin@serveur

Puis naviguer, put pour envoyer, get pour récupérer. Pour un environnement multi-utilisateur, vous pouvez chrooter des comptes SFTP pour les enfermer dans un dossier, ce qui évite l’accès au reste du système. Dans sshd_config, créez un groupe, assignez les utilisateurs et déclarez un bloc Match Group avec ChrootDirectory. Testez soigneusement les permissions, car SFTP est strict sur les droits.

On peut dire que déplacer ou transférer des fichiers avec SSH ressemble à utiliser un client FTP, mais avec quelques différences importantes :

• FTP classique (File Transfer Protocol) envoie les fichiers sans chiffrement → les données (et mots de passe) circulent en clair sur le réseau.
• SFTP (SSH File Transfer Protocol) ou SCP (Secure Copy Protocol) passent par SSH → tout est sécurisé et chiffré.

Exemple avec SCP : transférer un fichier site.zip de votre ordinateur vers un serveur :

scp site.zip [email protected]:/var/www/html/

Exemple avec SFTP (plus interactif, comme un mini-client FTP en ligne de commande) :

sftp [email protected]

Puis vous pouvez utiliser des commandes comme put fichier.txt ou get fichier.txt pour envoyer ou télécharger des fichiers.

En résumé, c’est similaire à FTP dans l’usage, mais comme ça passe par SSH, c’est beaucoup plus sécurisé.

Connecter deux ordinateurs entre eux grâce à SSH

Jusqu’ici, nous avons vu comment utiliser SSH pour se connecter à un serveur distant. Mais SSH peut aussi servir à établir une connexion sécurisée entre deux ordinateurs classiques, par exemple entre votre machine personnelle et l’ordinateur portable d’un collègue. Cela permet de prendre le contrôle d’une autre machine comme si vous étiez assis devant elle, tout en gardant vos échanges sécurisés.

Comprendre le principe

Quand vous utilisez SSH pour relier deux ordinateurs, l’un d’eux joue le rôle de « serveur SSH », c’est-à-dire qu’il attend la connexion, tandis que l’autre joue le rôle de « client SSH », celui qui initie la connexion. Concrètement, cela signifie que l’ordinateur qui doit être accessible doit avoir un service SSH installé et actif. Le second ordinateur, celui qui se connecte, n’a besoin que du programme ssh pour établir la liaison.

Exemple concret

Imaginons que vous ayez deux ordinateurs dans le même réseau domestique. Le premier, que nous appellerons « Ordinateur A », est sous Linux et vous voulez pouvoir y accéder depuis le second, « Ordinateur B », qui est sous Windows.

Sur l’Ordinateur A (Linux), vous devez vérifier que le service SSH est bien installé et activé. Pour cela, vous ouvrez un terminal et tapez :

sudo apt install openssh-server sudo systemctl enable ssh sudo systemctl start ssh 

Après ces commandes, votre ordinateur A est prêt à recevoir des connexions SSH.

Toujours sur l’Ordinateur A, vous devez connaître son adresse IP pour pouvoir vous y connecter. Tapez :

ip a 

Supposons que l’adresse IP trouvée soit 192.168.1.50.

Sur l’Ordinateur B (Windows), ouvrez un terminal PowerShell et utilisez la commande suivante pour vous connecter :

ssh [email protected] 

Ici, utilisateur doit être remplacé par le nom d’utilisateur de la session Linux de l’Ordinateur A.

La première fois, Windows vous demandera d’accepter la clé de sécurité. Répondez « yes » pour établir la confiance. Ensuite, entrez le mot de passe de l’utilisateur Linux de l’Ordinateur A.

À partir de ce moment, vous contrôlez l’Ordinateur A depuis l’Ordinateur B comme si vous y étiez connecté directement. Toutes les commandes que vous tapez dans le terminal Windows s’exécutent sur l’ordinateur Linux.

Cas pratique

Imaginez que vous soyez dans une autre pièce de la maison et que vous vouliez lancer une sauvegarde ou consulter un fichier stocké sur votre ordinateur principal sans vous déplacer. Grâce à SSH, vous vous connectez rapidement à votre machine depuis votre portable et exécutez les commandes nécessaires. Tout cela se fait en sécurité, car SSH chiffre les échanges entre les deux ordinateurs.

Comment un hacker peut cibler un ordinateur avec SSH et comment s’en protéger

SSH n’est pas réservé aux serveurs. Beaucoup d’ordinateurs personnels et de petits appareils (comme un Raspberry Pi ou un NAS) utilisent aussi SSH pour faciliter la gestion à distance. Cela représente un confort certain, mais c’est également une porte potentielle pour un pirate si la configuration est mal sécurisée.

Comment un hacker s’y prend pour viser un ordinateur par SSH

Lorsqu’un utilisateur active SSH sur son PC et le laisse accessible depuis Internet, cet ordinateur devient repérable comme n’importe quel serveur. Les hackers utilisent des logiciels de scan d’adresses IP afin de détecter toutes les machines où le port SSH (par défaut le port 22) est ouvert.

Voici quelques outils très utilisés par les administrateurs (et aussi par les hackers) pour scanner les ports SSH et vérifier s’ils sont ouverts :

Nmap

• Description : Outil incontournable de scan réseau. Il permet de détecter les machines en ligne, d’identifier les ports ouverts (dont le port SSH 22), et même d’obtenir des informations sur la version du service SSH en cours.
• Exemple de commande :nmap -p 22 192.168.1.10 → Vérifie si le port 22 (SSH) est ouvert sur la machine 192.168.1.10.

Masscan

• Description : Connu comme le scanner de ports le plus rapide au monde. Il peut balayer l’ensemble d’Internet en quelques minutes. Il est souvent utilisé pour rechercher toutes les machines avec un SSH ouvert.
• Exemple de commande :masscan -p22 192.168.1.0/24 --rate=1000 → Scanne tout le sous-réseau 192.168.1.0/24 pour voir qui a SSH activé.

Shodan (outil en ligne)

• Description : Ce n’est pas un programme en local mais un moteur de recherche spécialisé pour l’Internet des objets et les services exposés. En tapant port:22 dans Shodan, on obtient une liste d’ordinateurs et serveurs accessibles via SSH partout dans le monde.
• Utilisation :
  • Accéder à https://www.shodan.io
  • Faire une recherche comme :port:22 country:FR → Montre les machines en France avec SSH ouvert.

⚠️ Ces outils sont à double usage : un administrateur système les utilise pour sécuriser son réseau, tandis qu’un pirate peut s’en servir pour trouver des cibles.

Une fois cette machine trouvée, le pirate essaie généralement une attaque par force brute sur le compte de l’utilisateur principal. Par exemple, si vous avez un ordinateur sous Linux avec un utilisateur appelé « alban », le hacker peut tester automatiquement des milliers de mots de passe associés à ce nom.

Si l’ordinateur accepte encore les connexions SSH en tant que « root », le pirate s’attaquera à ce compte directement, car il donne les pleins pouvoirs. Une seule erreur de mot de passe faible suffira pour lui ouvrir un accès complet.

Il existe également des cas où un hacker profite d’une clé SSH abandonnée ou non protégée sur une ancienne machine. Si une clé privée est récupérée (par un malware ou par négligence), il peut se connecter à distance sans avoir besoin de mot de passe.

Enfin, certains pirates surveillent les réseaux domestiques mal sécurisés. Par exemple, si vous redirigez le port SSH de votre box Internet vers votre PC, sans filtrage ni restrictions, votre ordinateur devient une cible facile.

Comment sécuriser un ordinateur personnel exposé via SSH

La première règle est de ne jamais utiliser de mots de passe simples. Même si c’est pour votre propre PC, il est crucial de choisir un mot de passe long, complexe et unique. Cela bloque déjà la majorité des attaques automatiques.

Ensuite, il faut désactiver la connexion directe en root. Sur un ordinateur, il est plus sûr de se connecter en tant qu’utilisateur normal et d’employer sudo uniquement quand c’est nécessaire.

Le meilleur choix reste d’utiliser des clés SSH. Votre ordinateur acceptera uniquement une clé publique correspondant à votre clé privée personnelle, ce qui empêche pratiquement toute tentative de connexion frauduleuse.

Il est également conseillé de changer le port SSH par défaut (22) pour un autre numéro, par exemple 22022. Ce n’est pas une protection infaillible, mais cela réduit considérablement les scans automatiques.

Enfin, vous pouvez limiter l’accès en configurant votre pare-feu afin que seules certaines adresses IP (comme celle de votre autre ordinateur ou de votre réseau domestique) soient autorisées à se connecter en SSH.

Exemple concret de protection

Imaginons que vous ayez un Raspberry Pi connecté à votre box Internet pour héberger un petit site personnel. Vous avez activé SSH pour y accéder à distance. Sans précaution, n’importe qui sur Internet pourrait tenter de se connecter.
Pour sécuriser la situation, vous configurez SSH pour :

• refuser l’accès root
• n’accepter que les connexions avec clé SSH
• fonctionner sur le port 22022 au lieu du port 22
• limiter les connexions entrantes au seul réseau de votre domicile

De cette manière, même si un hacker scanne votre adresse IP, il n’arrivera pas à trouver de point d’entrée exploitable.

Sécurité avancée : second facteur, bastion et hygiène des clés

Pour renforcer encore SSH, ajoutez un second facteur d’authentification. Vous pouvez activer une authentification TOTP via PAM avec un module type Google Authenticator.

Le principe est d’exiger, en plus de la clé ou du mot de passe, un code à usage unique qui change toutes les 30 secondes. Ce mécanisme complique la tâche d’un attaquant même en cas de fuite d’une clé privée.

Vous pouvez aussi utiliser des clés matérielles compatibles FIDO2/PKCS#11. OpenSSH sait signer des challenges avec des jetons matériels, ce qui ancre la sécurité dans un dispositif physique. C’est particulièrement recommandé pour les comptes à hauts privilèges.

Mettez en place un bastion SSH : une machine intermédiaire exposée publiquement et durcie, par laquelle passent toutes les connexions. Aucune autre machine n’expose SSH sur Internet.

Sur le bastion, activez des journaux détaillés, une authentification renforcée, des alertes et des règles de pare-feu strictes. Côté client, utilisez ProxyJump pour rendre le passage transparent. Ce modèle réduit la surface d’attaque et facilite l’audit.

Adoptez une hygiène stricte des clés : une clé par personne et par projet, une passphrase pour chaque clé, une révocation rapide en cas de départ ou de perte, et une revoyure régulière du contenu des authorized_keys. N’utilisez pas la même clé partout.

Diagnostic, surveillance et réponse à incident

Surveillez les journaux SSH au quotidien. Recherchez les connexions anormales, les tentatives en rafale, les accès en dehors des heures habituelles et les changements de clé. Un simple grep aide déjà :

sudo grep -i "Failed password" /var/log/auth.log | tail
sudo grep -i "Accepted publickey" /var/log/auth.log | tail

Mettez en place des alertes. Un service comme logwatch envoie un résumé quotidien. Vous pouvez également brancher journald sur un collecteur central pour corréler les événements de plusieurs machines. Sur des environnements plus grands, un SIEM devient pertinent.

Si vous suspectez une compromission, déconnectez le serveur d’Internet, conservez les journaux, montez un disque en lecture seule pour analyser, et partez du principe que les secrets stockés sont exposés. Réinitialisez les clés et les mots de passe, déployez une image propre et restaurez des données vérifiées. Ensuite, corrigez la faille qui a permis l’accès, durcissez sshd_config, ajoutez fail2ban, aménagez le pare-feu et revoyez le processus d’attribution des accès.

Au quotidien, vérifiez les processus et connexions réseau. Repérez un binaire ou un port inhabituels. Assurez-vous que les services qui n’ont pas besoin d’Internet n’y sont pas exposés. Fermez les ports inutiles, y compris côté IPv6 si vous ne l’utilisez pas.

Cas pratiques

Vous allez maintenant effectuer trois opérations concrètes autour de SSH. Suivez les étapes dans l’ordre.

Premier cas : connexion par clé sans mot de passe

Sur votre poste, générez une clé Ed25519 avec passphrase. Vérifiez que le fichier ~/.ssh/id_ed25519 existe et que ~/.ssh/id_ed25519.pub contient la clé publique. Copiez la clé publique sur le serveur avec ssh-copy-id. Testez immédiatement :

ssh utilisateur@serveur

Vous devez entrer la passphrase de la clé la première fois. Ajoutez ensuite la clé à l’agent avec ssh-add pour une session confortable. Une fois la connexion validée, éditez /etc/ssh/sshd_config et positionnez PasswordAuthentication no. Testez une nouvelle connexion dans un second terminal avant de fermer la session initiale.

Deuxième cas : synchroniser un site avec rsync

Placez-vous dans le dossier du projet. Lancez un --dry-run pour vérifier ce que rsync ferait sans écrire. Ajustez l’option --delete si vous souhaitez un miroir exact.

Lancez la synchronisation réelle. Répétez pour chaque déploiement. Si vous avez un compte dédié aux déploiements, limitez sa clé avec l’option command=dans authorized_keys pour empêcher un usage hors du script de déploiement.

Troisième cas : consulter un service interne via un tunnel local

Supposez que votre application écoute sur localhost:8080 sur le serveur et n’est pas exposée.

Ouvrez un tunnel local avec ssh -L 8080:localhost:8080 utilisateur@serveur.

Ouvrez votre navigateur sur http://localhost:8080.

Une fois le test terminé, déconnectez la session. Vous n’avez rien changé au pare-feu, mais vous avez accédé au service en toute sécurité.

Check-list de sécurité SSH à appliquer dès aujourd’hui

Cette section est volontairement une liste, car elle sert de mémo à cocher.

1. Générer une clé Ed25519 avec passphrase et la charger via ssh-agent.
2. Copier la clé publique sur le serveur avec ssh-copy-id et tester la connexion.
3. Désactiver PasswordAuthentication et PermitRootLogin dans sshd_config.
4. Restreindre les utilisateurs autorisés avec AllowUsers ou AllowGroups.
5. Activer un pare-feu et n’ouvrir que le port SSH utilisé, côté IPv4 et IPv6.
6. Installer et configurer fail2ban avec un maxretry et un bantime adaptés.
7. Choisir des algorithmes modernes dans sshd_config et bannir les anciens.
8. Mettre à jour régulièrement le système et OpenSSH.
9. Surveiller les journaux d’authentification et mettre en place des alertes.
10. Gérer le cycle de vie des clés : une clé par personne et par projet, révocation rapide.

Questions fréquentes et réponses courtes

Vous pouvez vous demander si le changement de port suffit. Non, ce n’est pas une protection en soi, mais cela réduit les tentatives automatiques. Il faut l’associer à des clés, un pare-feu et fail2ban.

Vous hésitez entre RSA et Ed25519. Choisissez Ed25519 pour sa sécurité et ses performances. RSA 4096 reste compatible avec des vieux systèmes.

Vous utilisez Windows. Le client OpenSSH est intégré aux versions récentes. Activez-le dans les fonctionnalités Windows et utilisez PowerShell pour les commandes ssh, scp et sftp. Pour un usage graphique, un client SFTP comme WinSCP s’intègre bien.

Vous souhaitez un second facteur. Un module TOTP ou une clé matérielle FIDO2 sont deux bonnes options. Testez d’abord sur un compte secondaire pour éviter de vous enfermer dehors.

Vous avez beaucoup de serveurs. Mettez en place un bastion et centralisez les logs. Utilisez des alias Host et ProxyJump dans ~/.ssh/config. Automatisez la distribution et la révocation des clés.

Faire de SSH un atout, pas un risque

SSH est un protocole mature et robuste. Utilisé correctement, il vous offre une sécurité élevée et une grande souplesse pour administrer vos systèmes, transférer des fichiers, créer des tunnels et automatiser vos opérations. Sa force vient de la cryptographie, mais votre responsabilité est d’appliquer des règles simples : préférer les clés aux mots de passe, interdire l’accès root, maintenir votre système à jour, surveiller l’activité et limiter ce qui n’est pas utilisé.

Ce tutoriel vous a montré pas à pas comment installer, configurer, utiliser et durcir SSH, comment détecter des signaux faibles d’attaque et comment réagir. Commencez par mettre en place l’authentification par clé, basculez ensuite vers une configuration durcie, ajoutez un pare-feu et fail2ban, puis affinez avec des options comme AllowUsers, des algorithmes modernes et des restrictions dans authorized_keys. Si vous travaillez en équipe, formalisez la gestion des clés et des accès. Si vous administrez de nombreux serveurs, adoptez un bastion et centralisez les journaux.

En suivant ces étapes, vous réduirez fortement les risques sans perdre en productivité. Vous garderez la main sur vos systèmes et éviterez que SSH ne devienne un point faible. Prenez l’habitude de réviser votre configuration tous les trimestres, de supprimer les accès inutiles et de tester vos procédures de restauration. C’est cette discipline, plus que n’importe quel outil isolé, qui rend un environnement durablement sûr.

Extraits de configuration et commandes utiles

Extrait ~/.ssh/config côté client pour simplifier la vie :

Host bastion
    HostName bastion.exemple.com
    User admin
    IdentityFile ~/.ssh/id_ed25519
    ServerAliveInterval 30
    ServerAliveCountMax 3

Host prod-app01
    HostName 10.0.1.21
    User deploy
    ProxyJump bastion
    IdentityFile ~/.ssh/id_ed25519_projetA

Extrait /etc/ssh/sshd_config côté serveur, durci et commenté :

# Authentification
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
ChallengeResponseAuthentication no
UsePAM yes
PubkeyAuthentication yes

# Comptes autorisés
AllowUsers admin deploy

# Algorithmes modernes
HostKeyAlgorithms ssh-ed25519,rsa-sha2-512,rsa-sha2-256
KexAlgorithms curve25519-sha256,[email protected]
Ciphers [email protected],[email protected]
MACs [email protected],[email protected]

# Forwarding
AllowAgentForwarding no
X11Forwarding no
AllowTcpForwarding no
PermitTunnel no

# Logs
LogLevel INFO

Commandes de base pour surveiller et diagnostiquer :

# Qui est connecté et depuis quand
w
who
last -n 20

# Journal SSH aujourd'hui
sudo journalctl -u ssh --since "today"

# Ports en écoute
sudo ss -tulnp

# Tunnels actifs dans le process courant (client)
ps aux | grep ssh

Modèle minimal pour fail2ban côté Debian/Ubuntu :

[sshd]
enabled   = true
port      = 22
logpath   = /var/log/auth.log
backend   = systemd
maxretry  = 5
findtime  = 10m
bantime   = 1h

Avec ces briques, vous avez tout le nécessaire pour travailler proprement avec SSH, de l’initiation à la mise en production sécurisée !

Alban

Fondateur de l’agence Créa-troyes.
Intervenant en Freelance.
Contactez-moi

crea-troyes.fr