OpenSSH : Configuration du serveur SSH

Introduction :
Par défaut, le serveur OpenSSH est directement fonctionnel et utilisable, c'est ce
qui rend OpenSSH et les échanges SSH simples d'utilisation et rapides à mettre
en place dans les environnements Linux. Pour avoir une maîtrise plus concrète
de SSH et d'OpenSSH, nous allons étudier ensemble la configuration du
serveur OpenSSH, nous verrons quels paramètres peuvent être utilisés pour
changer le port d'écoute d'SSH ou gérer des permissions de connexion par
exemple, mais aussi bien d'autres choses !
Pour commencer, notez que le répertoire du service OpenSSH se trouve
dans /etc/ssh, on pourra y trouver les fichiers suivants dans la configuration par
défaut :
 moduli : Il s'agit d'un fichier contenant des informations utilisées par le
système de chiffrement, nous parlerons des systèmes de chiffrements
utilisés lors des connexions SSH un peu plus tard, tachons pour l'instant de
comprendre ce qu'il est possible de faire avec SSH. 
 ssh_config : Il s'agit du fichier de configuration du client (openssh-client).
Et oui ! Rappelez vous, SSH est un système client-serveur et par défaut, ssh
serveur et client sont installés.
 sshd_config : Il s'agit du fichier de configuration du serveur OpenSSH, c'est
ce fichier qui va nous intéresser dans cette partie du cours.
 ssh_host_* : Il s'agit de fichier contenant certaines clés qui seront utilisées
lors des différents processus de chiffrement.
Comme nous l'avons vu, nous nous intéresserons ici particulièrement au
fichier /etc/ssh/sshd_config. Pour information le "d" de sshd est une marque
courante des configurations serveur car il se rapporte à "daemon" qui est la
façon dont on désigne des applications qui tournent sur un serveur Linux.
Comme pour la plupart des services Linux, une modification de la configuration
nécessite un redémarrage du service en question.
systemctl restart sshd

Pour recharger la configuration, ce qui aura le même effet dans notre contexte,
on utilisera cette commande :
systemctl reload sshd

I. Installer OpenSSH
Si ce n'est pas le cas, installons-le ! Sous Debian
apt-get update
apt-get install openssh-server

Sous CentOS:
yum update

yum install openssh-server

Voila, OpenSSH est maintenant présent sur votre machine Linux. Nous allons
pouvoir jouer un peu avec !
II. Gestion basiques d'OpenSSH
Dans tous les cas, nous pourrons voir l'état du du service SSH avec la
commande "systemctl", le serveur est-il en fonctionnement (actif, activé) ou non
?:
systemctl status sshd

Voici ce que l'on pourra voir si le serveur est effectivement déjà en route :

Sinon, il suffira de le démarrer avec la commande suivante :

systemctl start sshd

Par extension, pour arrêter le service il faudra utiliser la commande suivante :

systemctl stop sshd

Et pour le redémarrer :
systemctl restart sshd

Je ne l'ai pas encore mentionné, mais le service SSH écoute par défaut sur le
port 22 en TCP. Nous pouvons alors voir, sur notre serveur Linux, que le
service est bien en écoute sur ce port :
ss -lntp |grep "22"
Ici, la commande "ss" (anciennement connue sous le nom de "netstat") permet
de visualiser l'état des ports et des connexions du serveur sous les systèmes
Unix.
L'option "-l" permet de ne lister que les ports en écoute, l'option "-n" permet
d'afficher les ports de manière numérique, et non leur translation habituelle
(exemple "telnet" à la place de "23") et l'option "-t" permet de ne lister que les
ports TCP, l'option "-p" permet enfin de lister les processus derrière chaque
ports :

Ici, on voit donc que le port 22 est bien écoute, en IPv4 ("*:22") et
en IPv6 (":::22"). On voit également que c'est le processus "sshd" qui est
derrière, aucun doute, il s'agit bien de notre serveur SSH.

II. Spécifier la version du protocole SSH

Pour vérifier que la configuration du serveur OpenSSH n'acceptera que les
interlocuteurs discutant avec la version 2 du protocole SSH, il faut se rendre
dans le fichier de configuration OpenSSH puis vérifier la ligne suivante :
Protocol 2

II. Changer le port d'écoute d'SSH

Par défaut, le service OpenSSH écoute sur le port TCP 22, le port 22 fait
maintenant partie des "well known port", ces ports qui sont "réservés" par des
applications connues. Cependant, une bonne pratique de sécurité consiste à
changer le port d'écoute du serveur SSH.
On revient donc dans notre fichier de configuration sshd_config pour y trouver
la ligne suivante :
Port 22

Ici, nous allons remplacer "22" par le numéro de port sur lequel nous souhaitons
mettre en écoute notre service SSH, dans notre cas "7256"
Port 7256

Il est alors nécessaire de redémarrer notre service SSH.

Note : Attention, si vous êtes connecté en SSH à ce moment-là, votre accès sera
coupé et il faudra établir une nouvelle connexion avec votre client en visant
cette fois si le port précisé dans la configuration du service OpenSSH.
Une fois que nous aurons redémarré notre service SSH, nous pourrons vérifier
que notre serveur est bien à l'écoute sur un port différent avec la commande "ss"
ss -lntp | grep ssh

Nous verrons alors le retour suivant :

III. Gérer l'IP d'écoute du serveur

Nous allons ici voir comment contrôler l'interface réseau ou l'IP sur laquelle on
souhaite mettre en écoute notre serveur. Cela peut répondre à différents
contextes comme celui-ci :

On se rend ensuite dans le fichier de configuration d'OpenSSH.

On y trouvera une ligne "ListenAddress ::" commentée et une ligne
"ListenAddress 0.0.0.0" commentée également. En dessous de ces deux lignes
auxquelles nous n'allons pas toucher, il faut rajouter la ligne suivante :
ListenAddress 192.168.240.132

On remarque également que l'écoute sur l'interface IPv6 n'est plus présente. Pour
la rajouter, on peut ajouter la ligne suivante dans la configuration d'OpenSSH :
ListenAddress ::

Cela est rarement nécessaire, mis à part si votre service informatique déploie et
utilise l'IPv6 au lieu de l'IPv4. Si ce n'est pas le cas, vous devriez par sécurité
désactiver l'IPv6 de votre serveur Linux (et pas seulement l'écoute d'OpensSSH)
Note : Une restriction plus avancée peut être faite avec IPtables par exemple,
nous pourrons voir ce cas de figure plus loin dans le cours. On pourra par
n'autoriser que quelques IP d'un réseau à venir se connecter en SSH.

IV. Autorisation et permission, gestion des groupes et utilisateurs

- Permettre à root de s'authentifier en SSH
Nous allons à nouveau nous rendre dans le fichier de configuration du serveur
OpenSSH (pour rappel : /etc/ssh/sshd_config) puis y trouver la ligne suivante :
# permitRootLogin yes

Ou cette ligne selon votre distribution :

permitRootLogin without-password

Dans les deux cas, si l'on souhaite autoriser les connexions en root via SSH, on
décommentera cette directive pour lui mettre la valeur "yes" :
permitRootLogin yes

Après un redémarrage d'OpenSSH, on pourra s'authentifier en tant que root sur

notre service SSH.
Permissions et interdictions des groupes et utilisateurs
Outre la gestion de l'utilisateur root, il est également possible de gérer de façon
très précise qui parmi vos utilisateurs pourra se connecter en SSH via les
directives "AllowUsers" et "AllowGroups". C'est ici une façon très précise et
juste de gérer les accès SSH.
Partons du principe suivant : sur mon serveur Linux, je dispose de 4 utilisateurs :
 mickael
 florian
 abdel
 marie
Je souhaite que Mickael et Florian puissent se connecter, mais pas Abdel, ni
Marie. De plus, si je rajoute un utilisateur à mon serveur plus tard, je n'ai pas
très envie d'avoir à penser de modifier la configuration d'OpenSSH pour lui
interdire l'accès SSH. On opte donc pour une politique du type "tout ce qui n'est
pas explicitement autorisé est interdit" (ce que l'on appelle un liste blanche).
Nous allons donc aller dans notre fichier de configuration OpenSSH pour y
ajouter la directive suivante :
allowUsers mickael florian
La directive AllowUsers permet donc de dire "ces utilisateurs peuvent se
connecter en SSH, pas les autres". En effet, lorsque la directive AllowUsers est
définie dans la configuration d'OpenSSH, tous les utilisateurs non spécifiés ne
peuvent plus se connecter en SSH. Si la directive est absente, on retrouve la
configuration par défaut dans laquelle tous les utilisateurs peuvent se connecter
en SSH !
Une autre possibilité est de gérer cela à l'aide des groupes utilisateurs Linux. En
effet, Linux permet de gérer des groupes d'utilisateurs, notamment utilisés lors
de la gestion des droits d'accès à des fichiers par exemple. Toujours avec nos
mêmes utilisateurs, nous allons créer un groupe "ssh_allowed" dans lequel nous
mettrons les utilisateurs mickael et florian :
addgroup ssh_allowed

usermod -a -G ssh_allowed mickael

usermod -a -G ssh_allowed florian

On pourra donc aller spécifier dans la configuration OpenSSH que tous les
utilisateurs faisant partie de ce groupe pourront se connecter en SSH, pas les
autres, on ajoutera dans la configuration OpenSSH la ligne suivante pour ce faire
allowGroups ssh_allowed

V. Gestion des logs

Dans cette partie du cours, nous allons voir un nouvel aspect de la gestion du
service OpenSSH, la visualisation et la compréhension des logs. Si vous avez
effectué les manipulations, configurations et redémarrage expliqués depuis le
début du cours, nous avons généré normalement assez de logs pour avoir de quoi
étudier. Pas de panique sinon, je mettrai ici les captures d'écran nécessaires. �
Communément sous Linux et ses services, les logs permettent de retracer et
d'historiser la vie d'une application, on pourra y observer différents événements
comme des connexions ou déconnexions de session dans le cadre du service
SSH.
Où trouver les logs SSH ?
Sur la plupart des distributions Linux, ils sont stockés dans le répertoire /var/log.
Les logs SSH quant à eux, sont dans le fichier /var/log/auth.log, mais dans ce
fichier, il n’y a pas que les logs SSH qui s’y trouvent !
Voici un extrait du fichier /var/log/auth.log tel que l'on peut le trouver dans tous
les OS Linux :

Le démarrage et extinction du service

Lorsque l'on observe les logs SSH, le démarrage du service SSH peut être
observé via ces lignes :
May 1 15:52:41 itc-serveur-01 sshd[2230]: Server listening on 0.0.0.0 port 22.

May 1 15:52:41 itc-serveur-01 sshd[2230]: Server listening on :: port 22.

On y voit la date et l’heure du démarrage, le nom de la machine et

le numéro de processus affecté au service sshd. Ces deux lignes détaillent le
port et la plage IP sur laquelle le service écoute. Ici, toutes les IP sur le
port 22 en IPv4 (0.0.0.0) ainsi que toutes les IP sur le port 22 en IPv6 ( ::
signifiant 0000:0000:0000:0000:0000:0000:0000:0000). Si, comme nous
l'avons vu plus haut dans le cours, vous avez restreint l'écoute sur votre service
SSH sur une IP précise, les logs le préciseront également, exemple :
May 1 14:14:33 itc-serveur-01 sshd[1682]: Server listening on 192.168.240.132
port 22.

Les connexions valides

Les logs SSH détaillent aussi les connexions utilisateurs dont l’authentification
fût réussie, nous voyons ces informations dans ce type de ligne :
May 1 15:34:35 itc-serveur-01 sshd[2130]: Accepted password for mickael from
192.168.240.1 port 51668 ssh2

May 1 15:34:35 itc-serveur-01 sshd[2130]: pam_unix(sshd:session): session

opened for user mickael by (uid=0)

Dans la première ligne, le serveur nous indique que l'utilisateur "mickael" a

saisi un mot de passe correcte, ce qui lui permet une connexion, on observe
d'ailleurs des détails sur l'IP du client, le port client (qui a rarement un intérêt) et
la version du protocole SSH (qui doit toujours être la version 2 rappelez-vous
!). La seconde ligne indique qu'une session SSH a été ouverte pour
l'utilisateur "mickael".
Les mêmes informations sont présentes, on y rajoute l’UID qui est une notion
importante. l’UID permet d’identifier le nombre de connexions présentes
simultanément sur le service SSH. Ici avec la valeur “0“, aucune connexion
hormis la nôtre n’est active.
Les connexions invalides
Si nous sommes capables de voir les connexions correctement établies lors de
leur ouverture et de leur fermeture, OpenSSH est aussi capable de logguer
(mettre dans les logs), les tentatives de connexions infructueuses.
May 1 16:26:18 itc-serveur-01 sshd[2349]: Invalid user john from 192.168.10.1

May 1 16:26:18 itc-serveur-01 sshd[2349]: input_userauth_request: invalid user

john [preauth]