TawaKnow LogoTawaKnow
AWSDevOpsFavorisContribuer

© 2026 TawaKnow. Tous droits réservés.

Mentions LégalesPolitique de confidentialitéContribuer
Pratiques DevOps
0/29 chapitres0%
1.

Introduction au DevOps

2.

Introduction à Linux

3.

Système de Fichiers Linux

4.

Interface en Ligne de Commande (CLI)

5.

Gestionnaire de Paquets Linux

6.

Vim — Éditeur de Texte CLI

7.

Utilisateurs & Groupes Linux

8.

Permissions & Propriété des Fichiers

9.

Shell Scripting Bash

10.

Variables d'Environnement Linux

11.

Réseau Linux

12.

SSH — Secure Shell

13.

Introduction à Git & Contrôle de Version

14.

Configurer un Dépôt Git

15.

Flux de Travail Git — add, commit, push, pull

16.

Branches Git & Merge Requests

17.

Git Avancé — Commandes, .gitignore & Bonnes Pratiques

18.

Outils de Build & Gestionnaires de Paquets

19.

Build Tools, Docker & CI/CD

20.

Introduction à Nexus — Gestionnaire de Dépôts d'Artifacts

21.

Installer et Configurer Nexus sur un Serveur

22.

Nexus — Repositories, Publication et API REST

23.

Introduction aux Containers & Docker

24.

Commandes Docker & Registries

25.

Dockerfile — Créer des Images Docker

26.

Docker Compose, Volumes & Bonnes Pratiques

27.

Introduction à Jenkins & CI/CD

28.

Installer et Configurer Jenkins

29.

Jenkins Pipeline & Jenkinsfile

...SSH — Secure Shell
CoursPratiques DevOpsSSH — Secure Shell
Chapitre 12/29

SSH — Secure ShellSSH — Secure Shell

5 min de lecture
Total: ~5 min
Progression du cours0/29 chapitres

SSH — Secure Shell

SSH (Secure Shell) est un protocole réseau qui permet à deux ordinateurs de communiquer de manière sécurisée via un réseau non sécurisé (Internet).


Qu'est-ce que SSH ?

Votre machine locale          Serveur distant
(SSH client)        ──SSH──►  (SSH server)
                    chiffré
  • SSH chiffre toutes les communications (protection contre l'interception)
  • Modèle client-serveur : le client se connecte au serveur SSH
  • Principalement utilisé via la ligne de commande

Cas d'usage typiques

  • Se connecter à un serveur cloud (AWS EC2, VM Azure, DigitalOcean...)
  • Installer et configurer des logiciels sur un serveur distant
  • Copier des fichiers vers/depuis un serveur
  • Pipelines CI/CD (Jenkins, GitLab CI) qui déploient sur des serveurs distants

SSH et le port 22

Le service SSH tourne par défaut sur le port 22.

Règle de pare-feu recommandée pour SSH :
Type   Protocol  Port  Source
SSH    TCP       22    195.1.20.1    ← Restreindre à des IPs connues !

SSH est très puissant. Autoriser 0.0.0.0/0 (tout Internet) sur le port 22 expose votre serveur aux attaques par force brute. Toujours restreindre SSH à des adresses IP spécifiques.


2 méthodes d'authentification

1. Nom d'utilisateur & Mot de passe

ssh alice@192.168.1.10       # Se connecter en tant qu'alice
  • L'administrateur crée un compte sur le serveur distant
  • L'utilisateur se connecte avec ses identifiants
  • Simple mais moins sécurisé (risque de brute force)

2. Paire de clés SSH (recommandé)

Paire de clés = Clé privée + Clé publique

Clé privée : SECRET, stockée sur votre machine locale (~/.ssh/id_rsa)
Clé publique : PARTAGEABLE, copiée sur le serveur (~/.ssh/authorized_keys)
Votre machine                    Serveur distant
~/.ssh/id_rsa (privée)           ~/.ssh/authorized_keys
~/.ssh/id_rsa.pub (publique) ──► (contient votre clé publique)

Connexion SSH :
  Client envoie sa clé publique
  Serveur vérifie dans authorized_keys
  → Accès accordé (sans mot de passe !)

La clé privée ne quitte JAMAIS votre machine. Si quelqu'un obtient votre clé privée, il peut se connecter à votre place.


Générer une paire de clés SSH

# Générer une paire de clés (sur votre machine locale)
ssh-keygen -t rsa -b 4096 -C "alice@email.com"

# Les fichiers créés :
~/.ssh/id_rsa          # Clé PRIVÉE (ne jamais partager !)
~/.ssh/id_rsa.pub      # Clé PUBLIQUE (à copier sur les serveurs)

# Permissions correctes (OBLIGATOIRES)
chmod 600 ~/.ssh/id_rsa         # Clé privée : seulement le propriétaire
chmod 644 ~/.ssh/id_rsa.pub     # Clé publique : lisible par tous

Copier la clé publique sur le serveur

# Méthode 1 : commande automatique
ssh-copy-id alice@192.168.1.10

# Méthode 2 : manuelle
cat ~/.ssh/id_rsa.pub
# Copier le contenu, puis sur le serveur :
echo "votre-clé-publique" >> ~/.ssh/authorized_keys

Se connecter via SSH

# Connexion basique
ssh alice@192.168.1.10

# Avec une clé spécifique
ssh -i ~/.ssh/ma-cle.pem alice@192.168.1.10

# Avec un port personnalisé
ssh -p 2222 alice@192.168.1.10

# Exécuter une commande distante sans ouvrir de session
ssh alice@192.168.1.10 "df -h"
ssh alice@192.168.1.10 "sudo systemctl restart nginx"

Fichiers importants SSH

Côté CLIENT (~/.ssh/)
├── id_rsa              # Clé privée (chmod 600)
├── id_rsa.pub          # Clé publique
├── known_hosts         # Serveurs connus (vérification contre usurpation)
└── config              # Configuration des connexions SSH

Côté SERVEUR (~/.ssh/)
└── authorized_keys     # Clés publiques autorisées à se connecter

Configuration du serveur SSH
└── /etc/ssh/sshd_config    # Paramètres du démon SSH

known_hosts — Vérification du serveur

À la première connexion, SSH vous demande de confirmer l'identité du serveur. La clé du serveur est stockée dans ~/.ssh/known_hosts.

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

Cela protège contre les attaques man-in-the-middle (usurpation de serveur).

authorized_keys — Clés autorisées

Chaque ligne = une clé publique autorisée à se connecter à ce compte.


SSH pour les services (Jenkins, CI/CD)

Scénario : Jenkins déploie sur un serveur applicatif

1. Créer un utilisateur "jenkins" sur le serveur applicatif
2. Générer une paire de clés SSH sur le serveur Jenkins
3. Copier la clé publique dans authorized_keys du serveur applicatif

CI Server (Jenkins)              Serveur applicatif
├── ~jenkins/.ssh/id_rsa  ──►   ~jenkins/.ssh/authorized_keys
└── Pipeline Jenkinsfile          (déploiement automatique)

Configuration SSH (/etc/ssh/sshd_config)

# Désactiver la connexion root directe (IMPORTANT)
PermitRootLogin no

# Désactiver l'authentification par mot de passe (utiliser seulement les clés)
PasswordAuthentication no

# Port personnalisé (moins exposé aux scans)
Port 2222

# Recharger SSH après modification
sudo systemctl restart sshd

Bonnes pratiques sécurité SSH

  • Préférer les clés SSH aux mots de passe
  • Désactiver PermitRootLogin dans /etc/ssh/sshd_config
  • Restreindre le port 22 aux IPs de confiance dans le pare-feu
  • Utiliser des mots de passe forts si les clés ne sont pas possibles :
    • Ne jamais réutiliser le même mot de passe
    • Configurer une expiration des mots de passe
    • Utiliser un gestionnaire de mots de passe
  • Désactiver SSH si le service n'est pas nécessaire
  • Mettre à jour régulièrement le logiciel SSH
  • Sauvegarder régulièrement les données (rsync est populaire sous Linux)

À retenir

  • SSH = protocole de communication sécurisé et chiffré entre deux machines
  • Port 22 = port standard SSH → à restreindre aux IPs connues dans le pare-feu
  • 2 méthodes : username/password (simple) ou paire de clés SSH (recommandé)
  • Clé privée = secrète, reste sur votre machine (chmod 600)
  • Clé publique = partagée sur les serveurs dans authorized_keys
  • ssh user@serveur = se connecter ; ssh-keygen = générer une paire de clés
  • ~/.ssh/known_hosts = vérification des serveurs (protection usurpation)
  • ~/.ssh/authorized_keys = liste des clés publiques autorisées sur le serveur
  • PermitRootLogin no dans /etc/ssh/sshd_config = sécurité de base obligatoire
Précédent
Réseau Linux
Suivant
Introduction à Git & Contrôle de Version
Sur cette page
PrécédentSuivant