Le serveur OpenSSH sur Debian

Qu'est-ce qu'OpenSSH ?

OpenSSH est une suite d'outils permettant d'établir des connexions sécurisées entre des hôtes via le protocole SSH (Secure Shell).

Il est indispensable sur les serveurs Linux en production aujourd'hui, étant une solution native du monde BSD. De nombreux protocoles reposent sur les communications chiffrées avec SSH.
SSH remplace notamment Telnet ou rlogin, qui ne chiffrent pas les données transmises.

Grâce à SSH, la communication (y compris l'authentification et le transfert de données) est chiffrée, ce qui protège vos informations sensibles (mots de passe, commandes, transferts de fichiers) contre d'éventuelles interceptions.

Sur Debian, le serveur SSH s'appuie généralement sur le paquet openssh-server, qui met à disposition le démon sshd permettant d'accepter des connexions entrantes.
Le client SSH, lui, est fourni par le paquet openssh-client.

Installation du serveur SSH sur Debian

Si vous avez suivi l'article d'installation d'un serveur sous Debian, alors le serveur openSSH est déjà installé.
Si vous n'aviez pas coché la case, alors il vous faut l'installer manuellement, comme ci-dessous :

• Mettre à jour la liste des dépôts et les paquets (passez en root)

apt update
apt upgrade -y

Installer le serveur OpenSSH :

apt install openssh-server -y

Vérifier que le service est lancé et activé au démarrage :

systemctl status ssh
systemctl enable ssh

Par défaut, le démon SSH écoute sur le port 22.
Après l'installation, vous pouvez déjà vous connecter à ce serveur depuis une autre machine munie d'un client SSH (comme Windows 11 par exemple. Sachez que seul le client OpenSSH est installé sur Windows.
C'est le client OpenSSH qui permet de se connecter à un machine distante sur laquelle le serveur OpenSSH est installé.
Mais on ne peut pas se connecter à une machine distante qui n'a que le client OpenSSH installé.
Le serveur OpenSSH, peut bien entendu, être également installé sur Windows.).

Se connecter depuis un poste client

Pour se connecter à un serveur SSH depuis un autre poste (Linux, macOS, ou même Windows depuis le Terminal Windows), on utilise la commande ssh.
La syntaxe de base est :

ssh [utilisateur]@[adresse_ip_ou_nom_de_domaine]

Exemple :
Si vous avez un utilisateur nommé alice sur une machine distante dont l'adresse est 192.168.1.10, la connexion se fera ainsi :

ssh alice@192.168.1.10

Lors de la première connexion, le client vous demandera de confirmer l'empreinte de la clefs du serveur (host key). Ensuite, vous devrez entrer le mot de passe de l'utilisateur distant.

Il existe un autre cas de figure pour la connexion, lorsque le port d'écoute SSH sur le serveur OpenSSH a été volontairement modifié :

ssh -p[numéro du port] [utilisateur]@[adresse_ip_ou_nom_de_domaine]

La connexion par clefs SSH

La connexion par clefs (authentification par clef publique/privée) est considérée comme plus sécurisée que la simple authentification par mot de passe. Elle consiste à générer une paire de clefs (une privée, que vous conservez sur votre machine cliente, et une publique, que vous déposez sur le serveur), afin de vous authentifier sans transmettre de mot de passe.

Il s'agît du principe de chiffrement par clefs asymétriques dont nous reparlerons.
Pour vous l'expliquer en 2 mots :
Vous créez une paire de clefs (une publique et une privée) sur votre poste client et vous envoyez votre clef publique au serveur distant auquel vous souhaitez vous connecter.

Génération de la paire de clefs sur le client

Sur le poste client, exécutez :

ssh-keygen -t ed25519

(Vous pouvez utiliser -t rsa pour RSA, mais ED25519 est plus moderne et recommandé.)

Durant le processus de création des clefs, il vous est demandé d'entrer une passphrase.
Ne le faîtes pas pour commencer.
Cette passphrase ajoute une couche de sécurité supplémentaire : non seulement vous utilisez un fonctionnement par clefs asymétriques, mais en plus, vous rajoutez un mot de passe par-dessus.
Pour nos besoins "éducatifs", je vous demande de ne pas le faire.
En production en revanche, c'est incontournable !

Cette commande génère un couple de clefs, généralement dans ~/.ssh/ :

• La clef privée : ~/.ssh/id_ed25519
• La clef publique : ~/.ssh/id_ed25519.pub

Note: Ne partagez jamais la clef privée. C'est la clef publique qui est destinée à être partagée - au serveur (ou plus généralement, à la machine distante à laquelle on souhaite se connecter).
De plus, rien ne vous empêche de générer une paire de clefs SSH sur un serveur A, dans le but de vous connecter depuis ce serveur à un serveur B. Vous devrez donc envoyer votre clef publique du serveur A au serveur B.

C'est celui qui veut se connecter, qui envoie sa clef publique.

Dépôt de la clef publique sur le serveur

Pour ajouter (envoyer) la clef publique au serveur distant et ainsi autoriser l'authentification par clef, utilisez la commande ssh-copy-id depuis votre client :

ssh-copy-id -i ~/.ssh/id_ed25519.pub alice@192.168.1.10

Cette commande va copier la clef publique dans le fichier ~/.ssh/authorized_keys de l'utilisateur alice directement sur le serveur distant. Une fois fait, vous pourrez vous connecter sans saisir de mot de passe :

ssh alice@192.168.1.10

Problème ! ssh-copy-id n'existe pas sur Windows.
Depuis un poste client Windows, vous ne pouvez pas utiliser cette commande pour envoyer directement votre clef publique au serveur distant. Cette commande n'est disponible que dans les environnements Linux/BSD/Unix.
Il vous faut impérativement utiliser la commande PowerShell suivante : (vous y adaptez simplement l'utilisateur et l'adresse IP du serveur distant. Ici "adminweb" et "192.168.10.104")

type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh adminweb@192.168.10.104 "mkdir -p ~/.ssh && tr -d '\r' >> ~/.ssh/authorized_keys"

Sécurisation de la connexion SSH

Il est vivement recommandé de renforcer la sécurité de votre serveur SSH. Pour cela, vous pouvez modifier le fichier de configuration /etc/ssh/sshd_config. Après chaque modification du contenu de ce fichier, pensez à redémarrer le service SSH :

sudo systemctl restart ssh

Un mot concernant Ubuntu Serveur.
Depuis la 22.04 (merci Jérôme ;-)), le service est éclaté en 2.
Pour le redémarrer et appliquer les modifications du fichier /etc/ssh/sshd_config, il faut faire :

sudo systemctl restart ssh.socket ssh.service

1. Changer le port par défaut

Le port standard est le 22. Les robots et attaquants essaient souvent ce port en premier.
Vous devrez le modifier en production, par exemple en 61435 :

Port 61435

Après modification et redémarrage du service ssh, vous vous connecterez ainsi :

ssh -p61435 alice@192.168.1.10

2. Désactiver l'accès root direct

Il est recommandé de ne pas autoriser le compte root à se connecter directement via SSH. Mieux vaut se connecter avec un utilisateur standard puis utiliser sudo :

PermitRootLogin no

On tolère parfois la connexion à root par clef SSH. Dans ce cas, on écrit :

PermitRootLogin prohibit-password

3. Autoriser uniquement la connexion par clef

Pour éviter les attaques par force brute sur les mots de passe, vous pouvez forcer l'utilisation des clefs :

PasswordAuthentication no
PubkeyAuthentication yes

Assurez-vous toutefois que vous avez déjà configuré votre connexion par clef et que cela fonctionne, sinon vous risquez de ne plus pouvoir vous connecter !

4. Limiter les utilisateurs autorisés

Vous pouvez spécifier une liste d'utilisateurs autorisés à se connecter via SSH :

AllowUsers alice bob

Seuls alice et bob pourront établir une connexion SSH.

5. Utiliser la fonctionnalité d'écoute sur une interface spécifique

Si votre serveur possède plusieurs interfaces réseau, vous pouvez forcer sshd à n'écouter que sur une seule d'entre elles :

ListenAddress 192.168.1.10

Il existe de très nombreuses autres instructions pour sécuriser SSH.
C'est un sujet particulièrement important.
Je ne vous ai présenté ici que le strict minimum. Nous approfondirons cela en cours.

Pour approfondir un tout petit peu, voici un autre article du blog
- Sécuriser l'accès en SSH