Quelques notes sur l’installation d’un serveur OpenSSH et comment générer ses clefs…
I Génération de clefs et emplacement
I.1 Introduction
L’authentification par clef nécessite d’avoir une clef privée et une clef publique.
La clef privée est à garder précieusement. En revanche la clef publique peut être communiquée sans restriction. Lors de l’authentification sur un serveur, c’est la clef publique qui sera donnée auparavant.
I.2 Génération d’une paire de clefs
Pour générer une paire de clefs il faut taper la commande suivante :
ssh-keygen -t rsa -b 4096 -C "test@example.mail"
Ce qui donne le résultat suivant :
Generating public/private rsa key pair.
Enter file in which to save the key (/home/xavior/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/xavior/.ssh/id_rsa
Your public key has been saved in /home/xavior/.ssh/id_rsa.pub
The key fingerprint is:
SHA256:lIvzPa0+b0Lz+R+GG5QxCsXNEoKY4WKJk5+qk7KKE+Q test@example.mail
The key's randomart image is:
+---[RSA 4096]----+
| .+ ...o+ |
| o oo . .oo o |
| + + . o. .o |
| .+ o o .. . + |
|o o o S . o |
|.E. o .o.. . |
| + ..oo.+ o |
|B oo+ + .|
|B+ .o=.o...|
+----[SHA256]-----+Avant de générer la paire de clefs, la commande demande un « passphrase », c’est à dire un mot de passe lié à cette clef. Il est possible de ne pas en donner
Ensuite la commande génère 2 clefs :
- une clef privée nommée id_rsa dans le répertoire ~/.ssh/
- une clef publique nommée id_rsa.pub dans le même répertoire.
Liste des clefs dans le répertoire ~/.ssh :
4 drwx------ 2 xavior xavior 4096 mars 13 17:06 .
4 drwxr-xr-x 38 xavior xavior 4096 mars 13 12:20 ..
4 -rw------- 1 xavior xavior 3434 mars 13 17:06 id_rsa
4 -rw-r--r-- 1 xavior xavior 743 mars 13 17:06 id_rsa.pub
On voit bien que la clef privée générée n’est visible que par l’utilisateur. En revanche la clef publique est visible par tous les autres.
Et le contenu d’une clef publique ressemble à ceci :
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDO50+/UB1+YL98/8in+/+DQv2kacw1NThgygTwbQakwTiMNHBpz4gWwpUyr287GSvsNz62ofccMqpji1+YAlBiU5Y4KhMToRdmeJdyCEZJGO3B2WX6kDMpOf52aIILxG8N8CUQk8zdAjYw0S4gql1A8NN7MLOmcTmNEgAtnTGg9eT1nIkilOWm4+iJ7PP/ig+3FHStsskDoBw2T7Fmjkp3AoEMTmIk7xCHqpls2DbVpM+WhwGQmjIB0latuifIgkzflHUc1vv6DvMZGJkhDzQrAttbx5sY++AAr6ygG8aAFRc4cAKCmqTGO+wVmOW3EzYkjOq00Od/lIWc819MImXn50MTWLc+2AD4nz3VmPVdf3OvLRW91/5mDSQGmX0kRUIpEKqsfN8R1frQdA8zZa8C8sebdZCTRLqn05ILEWzea8cYzz/vzA5PZJquHthSsxoOTkUm3c92mW/X97ME5cY78LkByJ22QlK5d7NsXmG2q3yp0gybylmxTxPiwdxlqRetIVr8XYeA9UQgH/khvTiULmQA+7Y3tau3MopUwYzNxzfDd+YULyw4HJW0fC86xQ7raNeca43SeHjhgELBhKU7FG5K8XVWtf6W8QVmOX6pqoH2GoKZ8pUL9gY5yVIAL+2VV2FLBx5wzuI68WXpDBKk6PfBxQs1sxBRq9H/zK4S7w== test@example.mailI.3 Pour aller plus loin
Dans l’exemple précédent il a été créé une paire de clefs de type RSA (option -t) et de longueur « 4096 » (option -b). Une longueur de 2048 bits aurait pu être suffisant. Attention avec cette longueur de clef car elle est, suivant les pays, peut être limitée.
Mais il existe d’autres algorithmes de chiffrement et qui sont :
- le DSA
- le RSA
- l’ ECC ou Elliptic curve cryptography : clefs dont le chiffrement est basée sur les courbes elliptiques. Elles ont de deux types :
- l’ECDSA ;
- l’ECDSA-SK ;
- l’ED25519 ;
- l’ED25519-SK.
Les clefs ECC sont plus petites en taille et permet un niveau de chiffrement équivalent et de sécurité à une clef RSA beaucoup plus grande. Pour exemple une clef RCC de taille de 256 bits équivaut une clef RSA de taille de 3072 bits. Moins longues elles permettent donc des délais de chiffrement et déchiffrement plus rapides également. Le revers de la médaille est que les anciennes systèmes ne savent pas gérer ce type de clef.
Ci-dessous quelque exemple de commandes pour générer les 4 types de clefs :
ssh-keygen -t rsa -b 4096
ssh-keygen -t dsa
ssh-keygen -t ecdsa -b 521
ssh-keygen -t ed25519A ce jour (2020) il est recommandé d’utiliser un chiffrement de type « ed25519 ».
Pour aller plus dans l’utilisation de la commande ssh-keygen : lien
II Serveur SSH
On considère que les comptes devront accéder au serveur sont déjà créés. Dans notre cas, l’utilisateur test a été créé dans ce sens.
II.1 Installation d’un serveur SSH
Nous allons voir comment installer un serveur ssh. Sous Ubuntu :
apt install -y openssh-serverRépondez aux questions (continent et ville) puis attendre la fin de l’installation.
les fichiers de configurations se trouvent dans /etc/ssh :
.
|-- moduli
|-- ssh_config
|-- ssh_config.d
|-- ssh_host_ecdsa_key
|-- ssh_host_ecdsa_key.pub
|-- ssh_host_ed25519_key
|-- ssh_host_ed25519_key.pub
|-- ssh_host_rsa_key
|-- ssh_host_rsa_key.pub
|-- ssh_import_id
|-- sshd_config
`-- sshd_config.d
Le fichier de configuration du serveur SHH est « sshd_config ».
II.2 Quelques éléments de configuration
II.2.1 le banner (message d’accueil)
Le banner est le message qui s’affiche au moment de la connexion lorsque l’on demande de s’identifier.
Par défaut il n’y pas de message. Pour en ajouter un il faut créer un fichier (dans notre cas /etc/ssh/banner.txt) contenant le message et déclarer l’option dans le fichier ssshd_config comme suivant :
Banner /etc/ssh/banner.txtLe résultat sera le suivant :
ssh test@127.0.0.1
Bienvenue sur le serveur via SSH.
L'accès au serveur est réservé aux ayants droits !
test@127.0.0.1's password: Une fois le bon mot de passe renseigné, le message suivant apparaît :
Welcome to Ubuntu 20.04.2 LTS (GNU/Linux 5.8.0-44-generic x86_64)
* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/advantage
This system has been minimized by removing packages and content that are
not required on a system that users do not log into.
To restore this content, you can run the 'unminimize' command.
Last login: Sun Mar 14 08:04:11 2021 from 192.168.80.1
OpenSSH-server utilise le message du jour de la distribution. Pour pouvoir le changer, il faut modifier les scripts situé dans /etc/update-motd.d :
.
|-- 00-header
|-- 10-help-text
|-- 50-motd-news
`-- 60-unminimizeEn en enlevant l’exécution sur les scripts puis en ajoutant le sien comme suivant :
8 drwxr-xr-x 1 root root 4096 Mar 14 08:16 .
8 drwxr-xr-x 1 root root 4096 Mar 14 06:53 ..
4 -rw-r--r-- 1 root root 1220 Dec 5 2019 00-header
4 -rw-r--r-- 1 root root 1157 Dec 5 2019 10-help-text
8 -rw-r--r-- 1 root root 5023 Aug 17 2020 50-motd-news
4 -rw-r--r-- 1 root root 356 Feb 17 01:18 60-unminimize
4 -rwxr-xr-x 1 root root 122 Mar 14 08:16 99-personalisationle fichier contenant le texte suivant :
#!/bin/sh
echo "----------------------------------------"
echo "- Accès au serveur : soyez prudent !!!-"
echo "----------------------------------------"Il est possible d’avoir ce type de résultat :
test@127.0.0.1's password:
----------------------------------------
- Accès au serveur : soyez prudent !!!-
----------------------------------------
Last login: Sun Mar 14 08:26:33 2021 from 192.168.80.1
Pour aller plus loin sur le mot du jour : lien
II.2.2 Authentification par clef
Nous allons maintenant voir l’authentification par clef et non plus par mot de passe.
Par défaut l’authentification par clef est activée. Dans le fichier de configuration la clé est la suivante :
#PubkeyAuthentication yesOpenssh va vérifier la présence ou non d’une clef autorisée dans le répertoire ~/.ssh/authorized_keys
Il faut donc connaitre sur le serveur l’emplacement HOME de l’utilisateur « test » :
cat /etc/passwd | grep test
test:x:1000:0::/home/ubuntu:/bin/bashAinsi nous allons créer le répertoire .ssh ainsi que le fichier de cet utilisateur (test):
mkdir /home/ubuntu/.ssh
touch /home/ubuntu/.ssh/authorized_keys
chmod 700 /home/ubuntu/.ssh
chmod 600 /home/ubuntu/.ssh/authorized_keys
chown test:root /home/ubuntu/.ssh/authorized_keys
chown test:root /home/ubuntu/.sshLe respect du positionnement de ces droits est imposé par la directive « StrictModes yes » dans le fichier de configuration. Il n’est pas du tout conseiller de mettre cette directive à no (sauf pour debugger par ex.)
Il faut maintenant copier la clef pulique sur le serveur. Nous allons la mettre dans le répertoire ~/.ssh.
Puis nous allons ajouter cette clef dans le fichier « authorized_keys » :
cat id_rsa.pub >> authorized_keys
rm id_rsa.pubAinsi une connexion ressemblera à celle-ci :
ssh test@127.0.0.1
Bienvenue sur le serveur via SSH.
L'accès au serveur est réservé aux ayants droits !
----------------------------------------
- Accès au serveur : soyez prudent !!!-
----------------------------------------
Last login: Sun Mar 14 11:05:34 2021 from 192.168.80.1
test@5c4aae25376b:~$
Comme aucune passphrase n’a été renseignée dans la clef, pas d’identification supplémentaire a été demandée. Néanmoins il faut une passphrase pour plus de sécurité notemment en cas de vol de la clef privée…
II.2.3 Enlever le mode d’authentification par mot de passe
Maintenant que nous avons vu l’authentification par clef, il est maintenant de sécuriser l’accès SSH en supprimant la possibilité de se connecter par mot de passe.
Pour cela, dans le fichier de configuration /etc/ssh/sshd_config, indiquer cette directive :
# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication noCe qui donne ce résultat si aucune clef est à fourni :
ssh test@127.0.0.1
Bienvenue sur le serveur via SSH.
L'accès au serveur est réservé aux ayants droits !
test@127.0.0.1: Permission denied (publickey).
II.2.4 N’authoriser que certains types de clefs
Nous allons voir comment n’accepter que certains types de clefs.
A ce jour et par défaut un serveur SSH accepte que ces types de clefs :
ecdsa-sha2-nistp256-cert-v01@openssh.com,
ecdsa-sha2-nistp384-cert-v01@openssh.com,
ecdsa-sha2-nistp521-cert-v01@openssh.com,
sk-ecdsa-sha2-nistp256-cert-v01@openssh.com,
ssh-ed25519-cert-v01@openssh.com,
sk-ssh-ed25519-cert-v01@openssh.com,
rsa-sha2-512-cert-v01@openssh.com,
rsa-sha2-256-cert-v01@openssh.com,
ssh-rsa-cert-v01@openssh.com,
ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,
sk-ecdsa-sha2-nistp256@openssh.com,
ssh-ed25519,sk-ssh-ed25519@openssh.com,
rsa-sha2-512,rsa-sha2-256,ssh-rsaNous allons voir comment réduire l’utilisation de clef que de type « ed25519 » par exemple.
Pour cela il faut modifier le fichier /etc/ssh/sshd_config et ajouter les directives suivantes :
PubkeyAcceptedKeyTypes ssh-ed25519-cert-v01@openssh.com,ssh-ed25519,sk-ssh-ed25519@openssh.comCe qui a pour effet immédiat avec une clef RSA :
ssh test@127.0.0.1
Bienvenue sur le serveur via SSH.
L'accès au serveur est réservé aux ayants droits !
test@127.0.0.1: Permission denied (publickey).Ce qui se comprend dans les fichiers log par les lignes suivantes :
Mar 14 11:46:06 5c4aae25376b sshd[467]: userauth_pubkey: key type ssh-rsa not in PubkeyAcceptedKeyTypes [preauth]
Mar 14 11:46:06 5c4aae25376b sshd[467]: Connection closed by authenticating user test 192.168.80.1 port 56042 [preauth]En revanche avec une clef ed25519 :
ssh test@127.0.0.1
Bienvenue sur le serveur via SSH.
L'accès au serveur est réservé aux ayants droits !
----------------------------------------
- Accès au serveur : soyez prudent !!!-
----------------------------------------Et on analysant les log, on voit bien que c’est une clef ed25519 qui a été utilisée, bien que le client et sur le serveur la clef RSA soit aussi présente pour l’utilisateur test.