Sécuriser l’accès SSH à un serveur Linux avec une clé ED25519

Il y a plusieurs façons de s’authentifier via une connexion SSH auprès d’un serveur Linux, les 2 principales sont :

• par mot de passe
• par l’échange de clés publique et privée

Pour peu que vous utilisiez régulièrement le même mot de passe et qu’il soit piraté ou cracké par brute force, le mot de passe n’est clairement pas ce qu’il y a de mieux pour sécuriser l’accès à un serveur.

L’accès via des clés est clairement préférable mais encore faut-il choisir le bon type de clé et que le serveur SSH soit correctement sécurisé.

Pour vérifier la sécurité de votre serveur SSH, vous pouvez utiliser le site ssh-audit. Voici ce que ca donne avec une installation par défaut :

Création et mise en place d’une clé ssh ED25519

Commençons par créer une paire de clé privée/publique ED25519. Connectez-vous à votre serveur SSH en non-root et tapez la commande suivante :

$ ssh-keygen -o -a 100 -b 521 -t ed25519 -f ~/.ssh/id_ed25519 -C "ed25519-key-2020-08-22"

Il vous sera demandé d’entrer une passphrase, c’est le mot de passe qui permettra de déchiffrer votre clé privée donc ne la perdez pas.

Explication des options utilisées :
-C : permet d’ajouter un commentaire à la clé. Je mets le type de clé et la date
-t : spécifie le type de clé
-o : sauvegarde la clé dans le nouveau format openssh au lieu de l’ancien format PEM
-a : plus le nombre est élevé et plus la vérification de la passphrase sera lente et donc résistante aux attaques par brut-force.
-f : précise le répertoire de sortie de la clé
-b : spécifie le nombre de bits de la clé. Avec un type RSA un minimum de 4096 bits est conseillé. Avec l’ed25519 une clé 521 bits est suffisamment costaud.

Dans votre dossier personnel un dossier .ssh/ a été créé et doit contenir 3 fichiers :

$ ll ~/.ssh/
-rw-r--r-- 1 petitsurfeur petitsurfeur  104 Aug 22 15:12 authorized_keys     << fichier contenant les clés publiques des utilisateurs autorisés à se connecter
-rw------- 1 petitsurfeur petitsurfeur  464 Aug 22 14:48 id_ed25519     << la clé privée qui ne devra jamais perdre ou communiquer
-rw-r--r-- 1 petitsurfeur petitsurfeur  104 Aug 22 14:48 id_ed25519.pub     << la clé publique qui pourra être partagée

Si besoin, modifiez les permissions :

$ chmod 0700 ~/.ssh
$ chmod 0600 ~/.ssh/id_ed25519
$ chmod 0644 ~/.ssh/authorized_keys

Si vous comptez vous connecter à ce serveur depuis votre poste client, ajoutez la clé publique dans le fichier autorized_keys.

Pour copier la clé publique sur un serveur cible, 2 solutions :

$ ssh-copy-id -i ~/.ssh/id_ed25519.pub login@IP_SERVER -p [PORT]

Ou bien copier le contenu du fichier id_ed25519.pub dans le fichier autorized_keys du ou des serveurs distants. Voici un exemple de contenu du fichier en question après avoir copié la clé :

$ cat authorized_keys
ssh-ed25519 AAAAC3NzaC[...]Y45 ed25519-key-2020-08-22

Commençons par faire une sauvegarde du fichier /etc/ssh/sshd_config et du fichier /etc/ssh/sshd_config.d/ubuntu.conf puisque dans mon cas le fichier de configuration se trouve dans /etc/ssh/sshd_config.d/ubuntu.conf.

# cp /etc/ssh/sshd_config /etc/ssh/sshd_config.SAVE
cp /etc/ssh/sshd_config.d/ubuntu.conf /etc/ssh/sshd_config.d/ubuntu.conf.SAVE

Vérifier que la plupart des lignes du fichier /etc/ssh/sshd_config sont bien commentées et

[...]
Include /etc/ssh/sshd_config.d/*.conf
[...]

Collez le contenu suivant dans le fichier /etc/ssh/sshd_config.d/ubuntu.conf :

# Interface & Port
Port 3022
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 petitsurfeur
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 yes

#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

Quelques explications des variables :

PermitRootLogin :: Refuser les login depuis le root.
PasswordAuthentication :: Refuser l’identification par mot de passe.
PubkeyAuthentication :: N’accepter QUE l’authentification par clé.
Port :: Changer le port par défaut du SSH.
LogLevel :: Augmentation du niveau de log.
Protocol :: On force l’usage du protocol niveau 2.
On retire le support ECDSA & RSA.
AllowUsers :: Déclaration des utilisateurs systèmes pouvant se connecter.
Prise en compte de l’IPv4 & IPv6.

ATTENTION : Vous pouvez redémarrer le service SSHD et ouvrir de nouvelles sessions pour vérfier l’accès mais surtout ne quittez pas votre session SSH actuelle avant d’être sûr que tout est bien paramétré, sous peine de perdre toute possibilité de connexion.

Une fois le fichier enregistré, relancez le service openssh.

$ sudo systemctl restart sshd.service

Pour vous connecter en SSH, pensez à préciser le nouveau port avec l’option -p :

# IPv4
ssh login@IP_SERVER -p SSH_PORT

# IPv6
ssh -6 login@IP_SERVER -p SSH_PORT

3 éléments doivent encore être pris en compte pour sécuriser les échanges :

• Ciphers : Le chiffrement utilisé.
• KexAlgorithms : Les algorithmes utilisés pour l’échange de clé.
• 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.

Commençons par régénérer 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 ""

Poursuivons avec le retrait des moduli Diffie-Hellman faibles :

$ sudo awk '$5 >= 3071' /etc/ssh/moduli > /etc/ssh/moduli.safe
$ sudo mv -f /etc/ssh/moduli.safe /etc/ssh/moduli

Restriction des ciphers, clés d’échange et codes d’authentification :

$ sudo echo -e "\nKexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512\nCiphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr\nMACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com\nHostKeyAlgorithms ssh-ed25519,ssh-ed25519-cert-v01@openssh.com,sk-ssh-ed25519@openssh.com,sk-ssh-ed25519-cert-v01@openssh.com" >> /etc/ssh/sshd_config.d/ubuntu.conf

Redémarrez le service

$ sudo systemctl restart sshd.service

Tester le serveur

Vous pouvez maintenant relancer un test du serveur en allant sur le site ssh-audit. Voici ce que ce la devrait donner :

Si comme moi vous utilisez Putty pour vous connecter au serveur, vous allez devoir convertir la clé privée avant de pouvoir vous connecter.

Commencez par récupérer les clés publique et privée sur votre ordinateur (ex dans Mes Documents/keys)

Téléchargez et lancez ensuite l’application Putty Key Generator (puttygen.exe)

Ouvrez votre clé privée et tapez ensuite le passphrase.

Un message vous indiquera que vous devez la convertir pour Putty en cliquant sur Save private key. Choisissez un nouveau nom (ex: ed25519-key-2020-08-22_priv_putty.ppk).

Configurer Putty

Lancez Putty et charger la session, modifiez le port si besoin puis allez dans Connection / SSH / Auth et sélectionnez votre clé privée.

Sauvegardez et lancez la session