OpenSSH : Configuration du serveur SSH

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. Sous Linux, les services relisent leurs configurations lorsqu'ils démarrent, ensuite elles sont mises en mémoire et les fichiers de configuration ne sont plus relus jusqu'au prochain redémarrage. Pour faire prendre en compte une modification de configuration, il faut donc passer par la case redémarrage du service.

Note : Certains processus et services acceptent le "reload", il s'agit alors de recharger la configuration d'une application sans la redémarrer complètement, cela évite de couper les connexions en cours par exemple, ce qui est plus pratique. C'est notamment le cas de Apache ou d'OpenSSH.

Pour rappel, on peut redémarrer le service OpenSSH avec la commande suivante (sous Debian 8 et CentOS 7) :

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. Spécifier la version du protocole SSH

Nous l'avons vu dans le module précédent, la version du protocole SSH à utiliser aujourd'hui est la version 2, la version 1 ayant connu des problèmes de sécurité assez sévère il y a de ça plusieurs années maintenant. 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

Il s'agit normalement de la configuration par défaut du serveur OpenSSH. Celui-ci était facile, passons à des paramètres plus importants 😉

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.

Cela pour une raison simple, il existe sur internet une quantité importante de robots qui scannent les ports 22 de toutes les IP publiques pour y trouver un serveur SSH à exploiter, en changeant le port par défaut de votre service SSH, vous vous protégerez d'un grand nombre de robots qui automatisent scans et attaques.

Note : Lorsque l'on change le port d'écoute du service SSH, il faut bien sûr retenir le numéro de port qui sera à utiliser par nos clients pour ouvrir une connexion SSH, mais aussi ne pas oublier de spécifier ce port lors du lancement d'une connexion SSH par un client. En effet par défaut, les clients SSH visent le port 22, il faut donc signaler au client (la commande "ssh" sous Linux ou Putty sous Windows) que le port à utiliser est un autre port. Nous verrons cela un peu plus tard.

Il est important d'éviter de configurer notre port sur la plage des "well known ports" dont nous venons de parler. Pour rappel, il s'agit des ports du numéro 0 à 1023. Mettons par exemple notre service SSH en écoute sur le port 7256, ainsi un attaquant souhaitant s'en prendre à notre service SSH aura déjà plus de difficulté à le trouver, ralentissant ainsi ses attaques.

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 :

On voit donc que notre service "sshd" écoute à présent sur le port 7256 en IPv4 et en IPv6

Note : Ici, la partie de la commande "| column -t" n'impacte pas la sortie de la commande "ss", il s'agit juste d'avoir un meilleur affichage. Une petites astuce si vous utilisez Linux couramment 😉

Par soucis de simplicité vis-à-vis du reste du cours, je repositionnerais mon service OpenSSH en écoute sur le port 22 pour les exemples suivants. 🙂

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

Il peut arriver que votre serveur Linux ait plusieurs interfaces réseau, ainsi que plusieurs IP. C'est par exemple le cas même lorsque l'on dispose d'une seule interface réseau car le serveur écoute sur l'IPv4 mais aussi sur l'IPv6 comme nous le voyons sur la capture d'écran vue un peu plus haut.

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 :

Ici, mon serveur Linux a deux interfaces. Si je démarre OpenSSH sans modifier sa configuration et que je regarde avec la commande "ss" quels ports sont ouverts et sur quelles interfaces, je vais voir la sortie suivante :

Ici, on remarque que mon serveur SSH écoute sur le port 22 en IPv4 et en IPv6. En IPv4, on remarque la notation suivante :

*:22

Ici, l'étoile "*" signifie "toutes les interfaces". Cela signifie, en suivant mon schéma, que si je tente d'établir une connexion SSH sur l'IP 192.168.10.131:22 ou 192.168.240.132:22 cela fonctionnera.

Note : La notation 192.168.10.131:22 est une notation courante pour spécifier une IP et un port (IP:port).

Par soucis de sécurité, de conception ou d'architecture, il peut être intéressant de pouvoir dire : "Mon serveur possède deux IPs, mais je souhaite qu'OpenSSH n'écoute que les tentatives de connexions entrantes sur la deuxième IP et pas sur la première". Pour cela, il faut déjà connaître l'IP et l'interface (eth0, eth1, etc.) sur laquelle vous souhaitez restreindre votre écoute. En restant dans le contexte du dernier schéma, je décide de n'écouter que sur le port 22 de l'interface eth1 qui possède l'IP 192.168.240.132. 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 va ensuite sauvegarder notre modification et redémarrer le service SSH.

Note : Je ne l'ai pas encore mentionné dans ce cours, mais n'hésitez pas à commenter vos fichiers de configuration ! Cela permet de rapidement s'y retrouver, pour vous comme pour un autre administrateur qui serait amener à y mettre le nez. Les commentaires dans les fichiers de configuration Linux doivent démarrer par un "#"

A présent, si l'on regarde à nouveau les ports en écoute avec la commande "ss" sur notre serveur :

ss -ntpl | grep ssh

Nous aurons la vue suivante :

Nous avons donc clairement ici l'information recherchée, notre service SSH n'écoute plus que sur le port 22 de l'interface possédant l'IP 192.168.240.132. Si quelqu'un tente d'accéder à notre service SSH via d'autres ports, cela ne fonctionnera pas.

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

Un serveur Linux peut posséder plusieurs dizaines d'utilisateurs et de groupes, la plupart seront des utilisateurs créés par des applications comme "mysql" ou "apache", d'autres seront des utilisateurs réels que vous aurez créé pour vos amis et vos collaborateurs, un utilisateur est toujours présent sur les serveurs Linux : root.

Une petite précision que je n'ai pas encore clairement annoncée dans ce cours. Étant donné que le rôle de SSH est d'ouvrir un terminal sur le serveur Linux de la même façon que nous le ferions s'y nous étions physiquement devant le serveur, la base d'utilisateur utilisée par SSH est la base utilisateur Linux (ceux se trouvant dans le fichier /etc/passwd).

L'utilisateur root possède tous les droits sur le serveur. Par sécurité et depuis peu, l'authentification en "root" est interdite depuis les connexions SSH dans la configuration par défaut d'OpenSSH.

Pourquoi interdire les connexions SSH depuis root par défaut ?

Le service SSH est un service très prisé des attaquants et pirates informatiques, celui-ci permet d'avoir directement la main sur le serveur comme si l'on se trouvait dans la même pièce que lui. Il se trouve que le service SSH peut être vulnérable aux attaques de type Brute Force, qui consistent à tester, pour un utilisateur donné, une grande quantité de mots de passe choisis plus ou moins au hasard en pariant sur le fait qu'au bout d'un certain moment, on tombera forcément sur le bon.

Le problème étant que si l'attaque par brute force est un succès sur le compte "root", cela devient très dangereux pour le serveur attaqué car il se retrouve entièrement dans les mains du pirate. Par sécurité, il est donc interdit de s'y connecter en root. Si un attaquant décide de brute forcer un accès SSH, il devra dans un premier temps trouver le nom d'un utilisateur valide (autre que root, qui est le seul utilisateur présent sur toutes les machines Linux du monde) et s'il parvient ensuite à trouver une combinaison login:mot de passe valide, il se retrouvera avec un nombre restreint de droit sur le serveur. Ce qui est un moindre mal.

Permettre à root de s'authentifier en SSH

Je vais ici vous montrer comment permettre à root de se connecter en SSH en changeant la configuration par défaut du service OpenSSH. Néanmoins je vous déconseille très fortement de le faire sur un environnement en production, l'interdiction de l'authentification root est une protection non négligeable du service SSH.

Si cette configuration doit être utilisée, cela doit être dans des contextes limités dans le temps et la configuration "habituelle" et courante doit toujours interdire les connexions root en SSH (Exemple : l'initialisation et la configuration d'un nouveau serveur).

Après ce petit rappel de sécurité, voyons comment autoriser les connexions root 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

La directive est ici assez claire "Autoriser le login Root". Dans le premier cas, la ligne est commentée et c'est donc la valeur par défaut ("no") qui s'applique. Dans le deuxième (que l'on rencontre sur les distributions Debian, entre autre), elle permet l'authentification "root" mais sans mot de passe. Nous verrons par la suite que le mot de passe n'est pas la seule façon utilisable pour authentifier un utilisateur, on peut également passer par un système de clé, réputé comme plus sûr.

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 ! 🙂

Après avoir effectué cette modification (en adaptant les noms d'utilisateurs à votre situation), vous pourrez redémarrer OpenSSH pour ensuite tenter une connexion avec un utilisateur dans la liste des utilisateurs autorisés, puis un utilisateur qui n'est pas dans la liste, le second devrait se faire refuser l'accès.

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

Ici, l'option "-a" permet de garder les groupes auxquels l'utilisateur appartient déjà, "-G" permet de spécifier le nouveau groupe dont fera parti l'utilisateur

Vous pouvez voir les groupes présents sur votre système en listant le fichier /etc/groups et les groupes auxquels est affecté un utilisateur via la commande suivante :

groups "utilisateur"

Voici un exemple :

groups mickael

Voici ce que l'on pourra voir :

Ici, l'utilisateur "mickael" fait donc partie du groupe "mickael" et du groupe "ssh_allowed", tout comme l'utilisateur "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

On peut bien sur mixer les deux, par exemple

allowGroups ssh_allowed

allowUsers marie

Enfin, pour compliquer un peu la chose, on peut effectuer l'opération inverse en refusant explicitement certains utilisateurs ou certains groupes et en acceptant tous les autres. La politique est alors "tout ce qui n'est pas explicitement interdit est autorisé" (ce que l'on appelle une liste noire) :

DenyUsers marie abdel

DenyGroups ssh_not_allowed

Bon, ça se complique un peu je suis d'accord ;). Notez que ces directives ne sont pas obligatoires et contribuent au renforcement de la sécurité de votre serveur, ce qui n'est pas à négliger, connaître l'existence de ces directives vous permettra de maîtriser totalement cet outil qu'est SSH et OpenSSH.

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 :

Dans ce fichier, nous distinguons les lignes qui traitent du SSH (avec un processus sshd[XXXX]) et celles qui traitent d’autres processus (processus su, cron, etc.), toutes concernent une authentification. Les lignes qui nous intéressent sont toutes celles qui ont un processus identifié en sshd.

Nous distinguons rapidement plusieurs trames de lignes. Celles-ci contiennent des informations différentes, mais des constructions similaires.

On trouve tout d'abord l'horodatage (date + heure) de l'apparition de l’événement, le nom de la machine (ce qui est utile lorsque l'on centralise les logs de plusieurs machines dans un même endroit), suivi du processus ayant généré l’événement (sshd dans notre cas), l'identifiant de ce processus (PID) puis l’événement.

Dans le cadre de l'étude des logs SSH, nous pouvons trouver différentes trames, nous allons les détailler ici.

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.

Vous savez maintenant observer le démarrage du service OpenSSH dans les logs, cela vous permettra par exemple de savoir quand il a été démarré ou redémarré mais aussi sur quelle(s) IP ou port il a été en écoute.

Pour finir, on pourra repérer l'extinction du service SSH via la ligne suivante dans les logs :

May 1 15:52:41 itc-serveur-01 sshd[2129]: Received signal 15; terminating.

Pour rappel, le "signal 15" sous Linux est le signal envoyé aux processus par le système pour leur demander de s'éteindre proprement (en fermant correctement les connexions réseau ouvertes, etc.), il est également appelé SIGTERM.

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.

Nous retrouvons notre numéro de processus (2130) sur ces deux lignes. Dès qu’une connexion en mode authentifié est acceptée, le numéro de processus SSH reste le même pour toute cette session. Ainsi, nous pouvons voir quand elle commence avec la ligne précédente, et quand elle finit avec cette ligne :

May 1 15:36:10 itc-serveur-01 sshd[2130]: pam_unix(sshd:session): session closed for user mickael

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]

Ces lignes nous indiquent qu’une authentification selon un utilisateur incorrecte a été tentée (précisant le nom d’utilisateur et l’IP cliente). Il faut aussi souligner le numéro de processus qui peut être là aussi intéressant (2349).

May 1 16:29:56 itc-serveur-01 sshd[2400]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.10.1 user=mickael

May 1 16:29:58 itc-serveur-01 sshd[2400]: Failed password for mickael from 192.168.10.1 port 56774 ssh
2

La première de ces deux lignes nous indique que le client a tenté une connexion avec l’utilisateur « mickael » avec un mot de passe invalide, précisant son IP, la version SSH, la date, etc.

Le numéro de processus est important. Cela peut mettre en avant une tentative de brute-forcing du mot de passe SSH par un utilisateur qui n’y a normalement pas accès. Des applications de sécurité telles que Fail2ban (que nous verrons plus loin dans le cours 😉 ) utilisent ces informations pour bannir les IP qui se trompent trop de fois de mot de passe, c'est là toute l'importance des logs, de leur observation, leur analyse et leur compréhension.

Pam_unix est le module par défaut utilisé pour les authentifications sous Linux.

VI. Bannière de connexion SSH

Lorsqu’une connexion en SSH ou en terminal “physique” à un serveur est établie, vous aurez peut-être remarqué qu'un message s’affiche juste après que vous vous soyez authentifié :

Ce message ne présente que peu d'intérêt, il est appelé "motd" pour "Message Of the Day". On y trouve un texte fixe concernant GNU/Linux ainsi qu'une information dynamique sur la dernière connexion SSH effectuée avec cet utilisateur ainsi que l'IP du client ayant établie cette connexion, appelé "LastLog".

Cependant, ce MOTD par défaut peut être personnalisé afin d’afficher des informations utiles ou adresser un message important à l’utilisateur. Nous allons voir comment modifier ce message.

Les modifications de ce paramètre s’effectuent non pas dans la configuration SSH mais la configuration du système. La bannière d’origine ou modifiée ne s’affiche pas seulement lors d’une connexion SSH mais également lors de l’ouverture d’une session en terminal directement sur la machine physique. On doit donc se rendre dans le fichier “/etc/motd” pour y trouver le message par défaut :

Pour modifier le message qui sera affiché lors d'une connexion (en terminal, pas seulement en SSH), il suffit de modifier le contenu de ce fichier, par exemple :

Le changement prendra effet immédiatement sans un quelconque redémarrage. Lors de l’ouverture d’une session en SSH, on voit un message supplémentaire s’afficher :

Nous pouvons également voir le "LastLog", c'est la date et l'heure de la dernière connexion de cet utilisateur en SSH ainsi que l'IP du client ayant établie la connexion. Cette information est affichée par défaut par OpenSSH. Pour supprimer cette notification, on se rend dans le fichier sshd_config pour y trouver la ligne suivante :

PrintLastLog yes

On remplacera simplement "yes" par "no".

Note : Vous n’êtes pas obligé d’effectuer cette modification si vous souhaitez afficher le nom du dernier utilisateur qui s’est connecté en SSH. Il s'agit juste d'une possibilité offerte par OpenSSH présentée ici.

Comme à notre habitude, on redémarrera OpenSSH après cette modification de configuration SSH.

Dans ce chapitre, nous avons étudié les principaux points de configuration du service OpenSSH. Certaines configurations, plus spécifiques et plus complexes seront toujours à découvrir. Ce que nous avons vu ici vous permettra d'être pleinement opérationnel dans des situations techniques. Dans le prochain chapitre, nous verrons ensemble toutes les possibilités offertes par SSH dans le cadre du transfert sécurisé de fichier.