Sécurisation-SSH.md 24 KB

Sécurisation SSH

Je vais baser cette partie sur plusieurs tutoriels auxquels vous voudrez bien vous référer pour avoir des explications plus poussées que celles que je vais donner.

Références

Vous pouvez trouver plein d'autres références en français ou anglais en utilisant votre moteur de recherche préféré.

Création d'une clef personnalisée

Nous allons créer une clef spécifique à notre mini serveur.

Auparavant, nous allons vérifier le hostname de notre machine. Si vous l'avez configuré avec raspi-config, il y a de grandes chances que le résultat ne soit pas bon.

Sous Debian, le hostname est composé de 2 parties situées dans 2 fichiers différents.

  • /etc/hosts (contient le nom complet, FQDN)
  • /etc/hostname (ne contient que le petit nom de la machine, sans le domaine)

Test du hostname (sur notre raspi)

pi@piras:~ $ hostname -f
piras.yojik.net
pi@piras:~ $ hostname
piras
pi@piras:~ $

Le fichier /etc/hostname ne doit contenir que le nom de la machine, pas le domaine : ici, piras, et c'est ce que renvoie la commande hostname.

pi@piras:~ $ cat /etc/hostname
piras
pi@piras:~ $

hostname -f renvoie le "fqdn", ou nom complet de la machine, ici, piras.yojik.net.

La référence complète du nom se trouve dans le fichier /etc/hosts.

pi@piras:~ $ cat /etc/hosts
127.0.0.1    localhost
::1          localhost ip6-localhost ip6-loopback
ff02::1      ip6-allnodes
ff02::2      ip6-allrouters

127.0.1.1    piras.yojik.net piras
pi@piras:~ $

Pour l'instant, c'est l'adresse 127.0.1.1 qui est utilisée comme référence du nom, mais nous changerons ça dès que nous aurons configuré une adresse IPV4 et IPV6 fixe.

Création de notre clef personnalisée (sur le desktop, pas sur le raspi!)

Nous utiliserons la commande :

sh-keygen -o -a 100 -t ed25519 -f ~/.ssh/piras_ed25519 -C "clef SSH de l'utilisateur pi du Raspi"
  • -o : Sauvegarde votre clé dans le nouveau format openssh au lieu de l’ancien format PEM
  • -C : insertion d'un commentaire (ce que vous voulez, votre adresse émail ...).
  • -f : nom du fichier à produire
  • -a : le nombre de tours de la clef de dérivation (plus il est élevé, plus il est difficile de la craquer en force brute, mais aussi plus c'est lent)

    eric@aldebaran:~$ ssh-keygen -o -a 100 -t ed25519 -f ~/.ssh/piras_ed25519 -C "eric@yojik.eu"
    Generating public/private ed25519 key pair.
    Enter passphrase (empty for no passphrase):
    Enter same passphrase again:
    Your identification has been saved in /home/eric/.ssh/piras_ed25519
    Your public key has been saved in /home/eric/.ssh/piras_ed25519.pub
    The key fingerprint is:
    SHA256:yyDsyczL9W1QTTn9d5o0hwZ5A0bdMnCJgK9cniCeR0c eric@yojik.eu
    The key's randomart image is:
    +--[ED25519 256]--+
    |         ..o=O.o |
    |        . E.B.O .|
    |         o o + * |
    |   .  . o = . = =|
    |    o..=SB . o =o|
    |   = ooo=.o   o  |
    |    * ..o.       |
    |   . o . ..      |
    |    o   ...      |
    +----[SHA256]-----+
    

Si vous allez dans ./.ssh, vous trouverez ceci :

eric@aldebaran:~/.ssh$ ls -l
total 44
-rw------- 1 eric eric  751  7 avril  2011 id_dsa
-rw-r--r-- 1 eric eric  604  7 avril  2011 id_dsa.pub
-rw------- 1 eric eric 1766  1 avril  2013 id_rsa
-rw-r--r-- 1 eric eric  396  1 avril  2013 id_rsa.pub
-rw-r--r-- 1 eric eric 3728 29 nov.  12:20 known_hosts
-rw------- 1 eric eric  444 11 déc.  18:17 piras_ed25519
-rw-r--r-- 1 eric eric   95 11 déc.  18:17 piras_ed25519.pub
eric@aldebaran:~/.ssh$ 

Nous voyons les clefs privées et publiques que nous avons créées. (ainsi que d'anciennes clefs ...) Vérifiez les permissions, mais normalement les commandes ci-dessus les attribuent comme attendu (voir plus bas).

Copie de la clef sur le serveur

Nous utiliserons la commande : ssh-copy-id

eric@aldebaran:~$ ssh-copy-id -i ~/.ssh/piras_ed25519.pub pi@192.168.111.32
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/eric/.ssh/piras_ed25519.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
pi@192.168.111.32's password: 

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'pi@192.168.111.32'"
and check to make sure that only the key(s) you wanted were added.

eric@aldebaran:~$

Vérifions la présence de notre clef sur notre raspi, dans le fichier authorized_keys :

pi@piras:~/.ssh $ cat authorized_keys 
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIAdDDO3ni4DHIxqfRaNZ4SBudrSlRoQjLm/fd2SSjxtM eric@yojik.eu
pi@piras:~/.ssh $

C'est bon, elle est là !

Essai de connexion avec notre nouvelle clef

eric@aldebaran:~$ ssh -i ~/.ssh/piras_ed25519 'pi@192.168.111.32'
Linux piras 5.4.51+ #1333 Mon Aug 10 16:38:02 BST 2020 armv6l

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Fri Dec 11 18:46:55 2020 from 192.168.111.150
pi@piras:~ $

ça marche ... j'ai précisé la clef SSH à utiliser avec l'option -i nom_de_la_clef.

Configuration de ssh sur la machine de travail

Je possède plusieurs clefs qui sont spécifiques à certains serveurs (ceux dans ma cave, et ceux sur internet). Nous allons rajouter une configuration pour permettre la sélection automatique de la bonne clef pour chaque serveur.

Cela se fait dans le fichier ~/.ssh/config

Le schéma à utiliser est le suivant :

eric@aldebaran:~$ cat ./.ssh/config
Host piras piras.yojik.net
    HostName 192.168.111.32
    IdentityFile ~/.ssh/piras_ed25519
    User pi

Host adara adara.yojik.eu
    HostName adara.yojik.eu
    IdentityFile ~/.ssh/id_rsa
    User ericadmin

eric@aldebaran:~$ 

Cela me permet de me connecter avec la commande :

ssh piras

Voilà à quoi ressemble mon répertoire ~/.ssh :

eric@aldebaran:~$ tree .ssh
.ssh
├── adara
│   ├── adara_ed25519
│   └── adara_ed25519.pub
├── aijan
│   ├── aijan_ed25519
│   └── aijan_ed25519.pub
├── alya
│   ├── alya_ed25519
│   └── alya_ed25519.pub
├── atom
│   ├── atom_ed25519
│   └── atom_ed25519.pub
├── config
├── id_dsa
├── id_dsa.pub
├── id_ed25519
├── id_ed25519.pub
├── id_rsa
├── id_rsa.pub
├── known_hosts
├── mynas2
│   ├── mynas2_ed25519
│   └── mynas2_ed25519.pub
├── mynas3
│   ├── mynas3_ed25519
│   └── mynas3_ed25519.pub
├── ns1
│   ├── ns1_ed25519
│   └── ns1_ed25519.pub
├── ns2
│   ├── ns2_ed25519
│   └── ns2_ed25519.pub
├── piras
│   ├── piras_ed25519
│   └── piras_ed25519.pub
└── polis
    ├── polis_ed25519
    └── polis_ed25519.pub

J'ai mis l'adresse IP ; j'aurai pu mettre le nom FQDN du serveur, mais je le ferai une fois les adresses IP fixées.

Modifions les permissions pour qu'elles soient conformes à ce que demande SSH. (en fait, les bonnes permissions étaient déjà appliquées par la commande ssh-keygen). Si vous organisez votre structure de répertoires comme ci-dessus, ajustez les permissions comme ceci :

Si vous créez un répertoire nommé ~/.ssh/piras ajustez les droits du répertoire comme suit :

chmod 700 ~/.ssh/piras

Et pour les clefs privées/publiques :

chmod 600 ~/.ssh/config
chmod 600 ~/.ssh/piras/piras_ed25519
chmod 600 ~/.ssh/piras/piras_ed25519.pub

Test de connexion

eric@aldebaran:~$ ssh piras
Linux piras 5.4.51+ #1333 Mon Aug 10 16:38:02 BST 2020 armv6l

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Fri Dec 11 18:49:37 2020 from 192.168.111.150
pi@piras:~ $ 

Ça marche ;)

Amélioration

Nous allons modifier temporairement (et le re-modifierons une fois les adresses fixées) notre fichier /etc/hosts sur notre machine de travail pour pouvoir utiliser la méthode par nom plutôt que par adresse IP. Ajoutons la référence à notre raspi :

eric@aldebaran:~$ cat /etc/hosts
127.0.0.1    localhost
127.0.1.1    aldebaran.yojik.net    aldebaran

192.168.111.32  piras.yojik.net piras

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
eric@aldebaran:~$ 

Modification de ./.ssh/config :

eric@aldebaran:~$ cat ./.ssh/config
Host piras piras.yojik.net
    HostName piras.yojik.net
    IdentityFile ~/.ssh/piras_ed25519
    User pi

Host adara adara.yojik.eu
    HostName adara.yojik.eu
    IdentityFile ~/.ssh/id_rsa
    User ericadmin

eric@aldebaran:~$ 

Test :

eric@aldebaran:~$ ssh piras
The authenticity of host 'piras.yojik.net (192.168.111.32)' can't be established.
ECDSA key fingerprint is SHA256:DjB1teyxsYAZzGBV8BIXiG5+UAb3JU5SHp7vu/xArG8.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'piras.yojik.net' (ECDSA) to the list of known hosts.
Linux piras 5.4.51+ #1333 Mon Aug 10 16:38:02 BST 2020 armv6l

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Fri Dec 11 19:17:50 2020 from 192.168.111.150
pi@piras:~ $ 

L'adresse de notre raspi a été ajoutée au fichier ./.ssh/known_hosts

Modification du fichier /etc/ssh/sshd_config

Nous allons modifier ce fichier pour plus de sécurité :

  • pas de connexion de l'utilisateur root
  • connexion uniquement par clef (pas par login/mot de passe)
  • suppression du support des protocoles non sûrs
  • autorisation de connexion sur liste blanche
  • connexion en IPV4 et IPV6

Tout d'abord, sauvegarde du répertoire /etc/ssh :

pi@raspberrypi:/etc $ sudo cp -R ssh ssh.orig
pi@raspberrypi:/etc $

Ensuite, création du nouveau fichier (après installation de vim, mais vous pouvez prendre l'éditeur de votre choix, nano par exemple qui est installé par défaut):

Pour installer vim, tapez : sudo apt install vim

Voilà une copie du fichier de conf du site troxyworld dont j'ai déjà donné les références :

# Interface & Port
Port 61022
AddressFamily any
ListenAddress 0.0.0.0
ListenAddress ::

HostKey /etc/ssh/ssh_host_ed25519_key

Protocol 2

SyslogFacility AUTHPRIV
LogLevel VERBOSE

# Authentication restriction
LoginGraceTime 30s
PermitRootLogin no
StrictModes yes
MaxAuthTries 3
MaxSessions 5

PubkeyAuthentication yes
AllowUsers hmichael
AuthorizedKeysFile  .ssh/authorized_keys .ssh/authorized_keys2

HostbasedAuthentication no
IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
PermitEmptyPasswords no
PasswordAuthentication no

# Change to no to disable s/key passwords
ChallengeResponseAuthentication no

UsePAM yes

AllowAgentForwarding no
AllowTcpForwarding no
GatewayPorts no
X11Forwarding no
PermitTTY yes
PermitUserEnvironment no
PrintMotd no
PrintLastLog no

#TCPKeepAlive yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#ShowPatchLevel no
UseDNS yes
PidFile /var/run/sshd.pid
MaxStartups 10:30:100
PermitTunnel no
#ChrootDirectory none
VersionAddendum none

# no default banner path
Banner none

# Accept locale-related environment variables
AcceptEnv LANG LC_*

# override default of no subsystems
Subsystem   sftp   /usr/libexec/openssh/sftp-server

Et voici une version par Synthic:

# Utilisation de la version 2 du protocole SSH
Protocol 2
# Utilisation du port 22. Il est possible de le modifier
Port 22
# Interdit à root de s'identifier
PermitRootLogin no
PermitEmptyPasswords no
# On indique ici la liste des utilisateurs ayant la permission d'utiliser SSH
AllowUsers utilisateur
# Nombre d'essais avant fermeture de la connexion
MaxAuthTries 3
UsePAM no
# Authentification par clés
PubkeyAuthentication yes
# Lieux où sont stockées les clés publiques --> /home/user/.ssh/authorized_keys
AuthorizedKeysFile .ssh/authorized_keys
ChallengeResponseAuthentication yes
# Désactivation de l'authentification par mot de passe
PasswordAuthentication no
IgnoreRhosts yes
HostbasedAuthentication no
AcceptEnv LANG LC_*
Subsystem       sftp    /usr/lib/openssh/sftp-server
PrintMotd no
Ciphers aes256-ctr,aes192-ctr,aes128-ctr
X11Forwarding no

Voilà mon fichier de configuration, à adapter suivant vos préférences (surtout n'oubliez pas d'ajuster le user dans l'option AllowUsers à votre cas particulier)

Pour ma part, je vais garder le port 22 ; je le changerai peut-être plus tard.

Protocol 2
Port 22

Blocage de root

PermitRootLogin no

Pas de mot de passe vide

PermitEmptyPasswords no

Seul l'utilisateur pi est autorisé

AllowUsers pi

Connexion uniquement pas clef

PubkeyAuthentication yes

Modification et limite des tentatives de connexion

LoginGraceTime 30s
PermitRootLogin no
StrictModes yes
MaxAuthTries 3
MaxSessions 5

Les fichiers de clef autorisés

AuthorizedKeysFile      .ssh/authorized_keys .ssh/authorized_keys2

Voici la copie du fichier complet :

pi@raspberrypi:~ $ cat /etc/ssh/sshd_config
#   $OpenBSD: sshd_config,v 1.103 2018/04/09 20:41:22 tj Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options override the
# default value.

Port 22
#AddressFamily any
# A décommenter après test sur sur site d'audit, car nos réglages ne permettent
# que de se connecter à partir de notre réseau local
# Si vous voulez que votre serveur soit accessible à partir de l'extérieur
# gardez les valeurs par défaut (ou les options commentées)
#ListenAddress 0.0.0.0
#ListenAddress ::
# Nouveaux réglages
# ListenAddress 192.168.111.0
# ListenAddress 2a01:e0a:d0:3c20::0

# On ne permet que la connexion avec une clef forte
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key

# Ciphers and keying
#RekeyLimit default none

# Logging
# Modification du niveau de logging pour plus de détails
#SyslogFacility AUTH
SysLogFacility AUTHPRIV
#LogLevel INFO
LogLevel VERBOSE

# Authentication:

# C'est ici que l'on va ne permettre que l'accès par clef partagée
# et interdire l'accès par mot de passe
# De plus on configure le nombre d'essais et le délai de connexion
# à des valeurs plus courtes
LoginGraceTime 30s
PermitRootLogin no
StrictModes yes
MaxAuthTries 3
MaxSessions 5

PubkeyAuthentication yes

# Ajout d'une liste blanche d'utilisateurs autorisés à se connecter
# ici, seulement l'utilisateur pi
AllowUsers pi


# Expect .ssh/authorized_keys2 to be disregarded by default in future.
AuthorizedKeysFile  .ssh/authorized_keys .ssh/authorized_keys2

#AuthorizedPrincipalsFile none

#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
# Interdiction de connexion pas login/mot de passe
PasswordAuthentication yes
# Interdiction de mot de passe vides
PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes

# On va interdire le forwarding
AllowAgentForwarding no
AllowTcpForwarding no
GatewayPorts no
X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
# Pas de message d'acceuil de SSHD
PrintMotd no
#PrintLastLog yes
#TCPKeepAlive yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
# Utilisation du DNS
UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none

# no default banner path
#Banner none

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

# override default of no subsystems
Subsystem   sftp    /usr/lib/openssh/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
#   X11Forwarding no
#   AllowTcpForwarding no
#   PermitTTY no
#   ForceCommand cvs server
pi@raspberrypi:~ $ 

On redémarre sshd

sudo systemctl restart sshd.service

On teste si le service a bien redémarré sans erreurs :

pi@raspberrypi:~ $ sudo systemctl status sshd.service
● ssh.service - OpenBSD Secure Shell server
Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled)
Active: active (running) since Sun 2021-02-14 14:59:47 CET; 7s ago
    Docs: man:sshd(8)
        man:sshd_config(5)
Process: 523 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=0/SUCCESS)
Main PID: 524 (sshd)
    Tasks: 1 (limit: 269)
CGroup: /system.slice/ssh.service
        └─524 /usr/sbin/sshd -D

févr. 14 14:59:46 raspberrypi systemd[1]: Starting OpenBSD Secure Shell server...
févr. 14 14:59:46 raspberrypi sshd[524]: Server listening on 0.0.0.0 port 22.
févr. 14 14:59:47 raspberrypi sshd[524]: Server listening on :: port 22.
févr. 14 14:59:47 raspberrypi systemd[1]: Started OpenBSD Secure Shell server.
pi@raspberrypi:~ $ 

C'est bon.

Essai de connexion :

eric@aldebaran:~$ ssh piras
The authenticity of host 'piras.yojik.net (192.168.111.170)' can't be established.
ED25519 key fingerprint is SHA256:NW70QB3uNQ1cnrTQyfXG1Lu1iTDubEv6Oak4PK+DR1k.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'piras.yojik.net,192.168.111.170' (ED25519) to the list of known hosts.
Enter passphrase for key '/home/eric/.ssh/piras/piras_ed25519': 
Linux raspberrypi 5.10.11+ #1399 Thu Jan 28 12:02:28 GMT 2021 armv6l

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Sun Feb 14 15:02:55 2021 from 192.168.111.150
pi@raspberrypi:~ $

C'est bon.

Test sur le site d'audit :

Bien, après avoir effacé toutes les données personnelles de mon navigateur (données qui entraînent une erreur «The csrf token is invalid »), le test revient toujours avec une mauvaise note. D'où la suite. Les instructions pour améliorer sont également sur le site SSH-Audit.com recommendations

On va sécuriser les échanges en jouant sur 3 options supplémentaires :

  • Ciphers : Le chiffrement utilisé.
  • KexAlgorithms : Les algorithmes utilisés pour l’échange de clés.
  • MACs : Message Authentication code, c’est le code qui accompagnent les données échangées dans le but d’assurer leur intégrité pour être certain qu’elles n’ont subies aucune altération pendant/après la transmission.

Voilà les étapes à suivre (reprises quasi texto des sites déjà cités) :

  • Régénération de la clé ED25519 du serveur :

    sudo rm -f /etc/ssh/ssh_host_*
    sudo ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key -N ""
    
  • Retrait des moduli Diffie-Hellman faible :

    sudo awk '$5 >= 3071' /etc/ssh/moduli > /home/pi/moduli.safe
    sudo mv -f /home/pi/moduli.safe /etc/ssh/moduli
    
  • Désactivation des clés DSA/ECDSA & RSA si ce n’est pas déjà fait :

    sudo sed -i 's/^HostKey \/etc\/ssh\/ssh_host_\(dsa\|ecdsa\|rsa\)_key$/\#HostKey \/etc\/ssh\/ssh_host_\1_key/g' /etc/ssh/sshd_config
    
  • Restriction des ciphers, clés d’échange et des codes d’authentification :

    Ajoutez ceci à la fin du fichier /etc/sshd_config:

    KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512
    Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
    MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com
    
  • Redémarrage de sshd

    sudo systemctl restart sshd.service

Test sur le site ssh audit

Tout est OK ... nous sommes passés d'une note F à A+.

résultat

résultat

résultat

résultat

résultat

résultat

résultat