Linux Basics E02 : SSH (Configuration, Génération d’une nouvelle clé SSH, etc...)

Qu’est-ce qu’un accès SSH ?

#

SSH pour Secure SHell est un protocole réseau sécurisé qui permet de se connecter à distance à une machine Linux pour la contrôler en ligne de commande via un terminal/console.

Concrètement, SSH vous permet :

• De prendre le contrôle d’un serveur distant comme si vous étiez physiquement devant lui,
• D’exécuter des commandes à distance (installer des logiciels, gérer des fichiers, configurer le système),
• De Transférer des fichiers de manière sécurisée (via SCP ou SFTP),
• D’administrer des serveurs situés n’importe où dans le monde.

Fonctionnement simple

#

graph LR;
A[Mon ordinateur]-->B((Internet))--Connexion chiffrée-->C[Serveur Linux distant Serveur SSH]

Pourquoi “Secure” ?

#

Contrairement à son prédécesseur Telnet, SSH chiffre toutes les communications : vos identifiants, vos commandes et les données échangées sont protégés contre l’interception. C’est devenu la méthode standard pour administrer les serveurs Linux à distance.

SSH est votre “porte d’entrée sécurisée” pour gérer un serveur Linux sans avoir à y être physiquement.

Les bonnes pratiques

#

Authentification et accès

#

Utiliser l’authentification par clés SSH :

• Désactiver l’authentification par mot de passe (PasswordAuthentication no),
• Générer des paires de clés robustes (ED25519 ou RSA 4096 bits),
• Protéger les clés privées avec une passphrase (comprendre mot de passe).

Restreindre l’accès root :

• Interdire la connexion root directe (PermitRootLogin no),
• Utiliser sudo pour les privilèges élevés,
• Créer des comptes utilisateurs dédiés.

Limiter les utilisateurs autorisés :

• Utiliser AllowUsers ou AllowGroups pour spécifier qui peut se connecter sur la machine,
• Exemple : AllowUsers admin deployer

Configuration réseau

#

Changer le port par défaut :

• Modifier le port 22 vers un port non standard (ex: 2222),
• Cela peut réduire la surface d’attaque automatisée.

Limiter les interfaces d’écoute :

• Utiliser ListenAddress pour spécifier les IP autorisées
• Exemple : ListenAddress 192.168.1.10

Configurer un pare-feu :

• Utiliser iptables, ufw ou firewalld,
• N’autoriser SSH que depuis des IP spécifiques si possible,
• Implémenter un rate limiting contre le brute force.

Connexion SSH via une paire de clés privée et publique

#

1. Génération de la paire de clés privée et publique

   ssh-keygen

   Le client crée une paire : une clé privée (secret, reste sur le client) et une clé publique (partageable que l'on va copier sur la machine distante sur laquelle on veut avoir l'accès SSH).

   ssh-keygen fourni un prompt pour vous aider.
2. Installation de la clé publique

   ssh-keygen

   La clé publique est copiée dans /home/<username>/.ssh/authorized_keys (~/.ssh/authorized_keys) du compte cible sur le serveur (permissions strictes requises).
3. Négociation de la connexion

   ssh-keygen

   Le client initie une connexion TCP au serveur SSH. Les deux parties négocient les paramètres cryptographiques (algorithme de chiffrement, échange de clés).
4. Authentification par défi/solution

   ssh-keygen

   Le serveur vérifie dans /home/<username>/.ssh/authorized_keys (~/.ssh/authorized_keys) si la clé publique du client est autorisée.

   • Le serveur envoie un défi chiffré ou demande une signature,
   • Le client utilise sa clé privée pour signer le défi,
   • Le serveur vérifie la signature avec la clé publique correspondante. Si la vérification réussit, l’authentification est acceptée.
5. Établissement du canal sécurisé

   ssh-keygen

   Une fois authentifié, un canal chiffré est établi pour toute la session (shell, tunnels, transfert de fichiers).

Points clés :

• La clé privée doit rester secrète et idéalement protégée par une passphrase,
• Les permissions des répertoires/fichiers SSH doivent être strictes (ex. ~/.ssh 700, authorized_keys 600),
• Les clés modernes recommandées : ED25519 (ou RSA 4096 si nécessaire),
• L’authentification par clé remplace les mots de passe et permet l’usage de contrôles supplémentaires (agent SSH, 2FA, etc).

Algorithmes de clés SSH

#

Voici les recommandations en 2025 :

Comparatif des algorithmes

#

ED25519 — Le choix recommandé

#

ssh-keygen -t ed25519 -C "username"

Avantages :

• Sécurité basée sur les courbes elliptiques (Curve25519),
• Clés très courtes (256 bits) mais extrêmement robustes,
• Génération et vérification de signature très rapides,
• Résistant aux attaques par canal auxiliaire (timing attacks),
• Implémentation simple = moins de risques de bugs.

ECDSA — Alternative acceptable

#

ssh-keygen -t ecdsa -b 521 -C "votre-email@exemple.com"

Tailles disponibles : 256, 384 ou 521 bits (privilégier 521)

Avantages :

• Bonne sécurité avec des clés compactes,
• Meilleure compatibilité qu’ED25519 sur certains systèmes.

Inconvénients :

• Dépend de l’implémentation des courbes NIST (potentielles faiblesses théoriques),
• Vulnérable aux attaques par canal auxiliaire si mal implémenté.

⚠️ RSA — Pour la compatibilité uniquement

#

ssh-keygen -t rsa -b 4096 -C "votre-email@exemple.com"

Pourquoi RSA est en déclin :

• Clés volumineuses (4096 bits vs 256 pour ED25519),
• Génération et vérification plus lentes,
• Les clés RSA < 2048 bits sont considérées cassables,
• RSA 2048 bits est le minimum absolu (à éviter si possible).

❌ DSA — À proscrire

#

Résumé des commandes de génération

#

# ✅ RECOMMANDÉ : ED25519
ssh-keygen -t ed25519 -C "username"

# ✅ ACCEPTABLE : ECDSA 521 bits
ssh-keygen -t ecdsa -b 521 -C "username"

# ⚠️ COMPATIBILITÉ : RSA 4096 bits
ssh-keygen -t rsa -b 4096 -C "username"

# ❌ À ÉVITER : DSA (obsolète)
# ssh-keygen -t dsa  # NE PAS UTILISER

Génération d’une nouvelle clé SSH

#

Vous pouvez générer une nouvelle clé SSH sur votre ordinateur local. Après avoir généré la clé, vous pouvez ajouter la clé publique à votre serveur.

ssh-keygen fourni un prompt pour vous aider

Ajouter une passphrase à votre clé sinon une clef ssh est plus dangereuse qu’une connexion SSH via mot de passe

Usage basique :

ssh-keygen -t ed25519 -C "username"

• -t : Type de clef / Algorithme utilisé (rsa, dsa, ecdsa),
• -b : Longeur de clef (dépend de l’algo: ici ecdsa 521).

En spécifiant la localisation de sortie :

ssh-keygen -t ed25519 -C "username" -f /home/<username>/.ssh/my-ssh-key

• -f : localisation de sortie.

Ajout de celle-ci à l’hôte distant

#

Ajout de la clé publique sur le host distant :

cat /home/<username>/.ssh/my-ssh-key.pub >> /home/<username>/.ssh/authorized_keys

ssh-copy-id -i /home/<username>/.ssh/my-ssh-key.pub user@monhost

On ajuste les permissions sur la machine distante sur le dossier /home/<username>/.ssh et le fichier authorized_keys :

chown <username>:<username> /home/<username>/.ssh && chmod 600 /home/<username>/.ssh/authorized_keys

Paramètres de configuration du serveur SSH

#

Sur un serveur tout juste installé, on s’assure que le serveur SSH est installé sur la machine distante :

sudo apt update && sudo apt install openssh-server openssh-client

sudo dnf install -y openssh-server openssh-clients

Une fois la clé envoyée à la machine distante, on peut modifier la configuration SSH.

Dans /etc/ssh/sshd_config :

# TCP port to bind to
# Change to a high/odd port if this server is exposed to the internet directly
Port 22
# Bind to all interfaces (change to specific interface if needed)
ListenAddress 0.0.0.0

# Force SSHv2 Protocol
Protocol 2

# Authorized Keys
# ssh-keygen -t ed25519 -C "username" -f /home/<username>/.ssh/my-ssh-key
HostKey /etc/ssh/ssh_host_ed25519_key
AuthorizedKeysFile .ssh/authorized_keys

# Public key authentication + Password authentication
# Two-Factor Authentication in OpenSSH v6.2+
PubkeyAuthentication yes
# AuthenticationMethods password
AuthenticationMethods publickey

# Disable root SSH access
PermitRootLogin no

# Client timeout
ClientAliveInterval 60
ClientAliveCountMax 100

# Compression (only after authentication)
Compression delayed

# Logging
SyslogFacility AUTH
LogLevel INFO

# Attack limitations
MaxAuthTries 3
MaxSessions 3
MaxStartups 5:30:20

AllowUsers username

# Authentication must happen within 30 seconds
LoginGraceTime 30

PasswordAuthentication no
PermitEmptyPasswords no

# Check user folder permissions before allowing access
StrictModes yes

# Message Authentication Code (Hash, only SHA2-512)
# SHA-256 included for compat with PuTTY-WinCrypt clients
MACs hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,umac-128-etm@openssh.com

# Ciphers (only secure AES-256)
Ciphers aes256-ctr,aes128-gcm@openssh.com,aes128-ctr,aes192-ctr,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com

# Key Exchange algorithms (Elliptic Curve Diffie-Hellman)
# DH-SHA-256 included for compat with PuTTY-WinCrypt clients
KexAlgorithms diffie-hellman-group18-sha512,curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes

# Disable unused authentication schemes
HostbasedAuthentication no
ChallengeResponseAuthentication no
KerberosAuthentication no
GSSAPIAuthentication no
UsePAM yes

# X11 support
X11Forwarding no

# Don't show Message of the Day
PrintMotd no

# TCPKeepAlive (non-tunneled, disabled)
TCPKeepAlive no

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

Subsystem sftp internal-sftp

On sauvegarde et on teste si la configuration est bonne et qu’elle ne fait pas planter le service :

sudo sshd -t

Si on n’a pas de retour, tout va bien, on peut redémarrer le service :

sudo systemctl restart ssh

sudo systemctl restart sshd

Utilisation

#

Vous utilisez un client SSH (comme ssh en ligne de commande ou PuTTY sous Windows) pour vous connecter au serveur avec une commande du type :

• Via login/mot de passe :

  ssh utilisateur@adresse-du-serveur
  

• Via clé SSH :

  ssh -i /home/<username>/.ssh/my-ssh-key utilisateur@adresse-du-serveur