Suite à un précédent article concernant la sécurisation d’un serveur linux, j’étais resté vague sur la mise en place de l’authentification ssh par clé privée.

L’authentification par clé privée augmente la sécurité d’un serveur au niveau du processus de connexion. Au lieu d’un simple couple identifiant / mot de passe, il faut désormais être en possession de deux informations secrètes à la fois :

• une clé privée (un fichier que vous conservez précieusement et surtout secrètement)
• un mot de passe que nous appelleront passphrase (pour décrypter la clé, et ainsi pouvoir l’utiliser)

Génération des clés

Pour mettre en place ce type d’authentification, il va falloir générer 2 clés : La clé privée et la clé publique.

La clé publique n’a pas besoin d’être secrète. C’est une clé qui est capable de reconnaître sa clé privée (cryptographie asymétrique). Cette clé sera donc placée sur le serveur afin qu’elle puisse vérifier notre clé privée lorsque nous voudrons nous connecter.

Sous linux

Générons notre paire de clé :

ssh-keygen -t rsa -b 4096 -C votre@email.com

Une passphrase est demandé, gardez la bien dans votre tête ou dans un gestionnaire de mot de passe. Elle sera utile par la suite !

Ici on génère une clé RSA de 4096 bits avec en commentaire votre adresse mail (juste afin de s’y retrouver si vous avez plusieurs clés à générer)

Par défaut ssh-keygen génère une clé RSA de 2048 bits avec en commentaire : votre@email.com

A vous de voir si vous préférez utiliser un algorithme RSA ou DSA. Il n’y a pas de plus ou moins costaud mais DSA est plus récent.

Pour la taille de la clé, il est recommandé de faire au moins du 2048 bits pour le RSA. En DSA, la clé fait obligatoirement 1024 bits.

Vos deux clés sont générées par défaut dans : ~/.ssh/

Vous y retrouvez vos deux clés :

• id_rsa.pub : La clé publique
• id_rsa : La clé privée

Sous windows

Utilisez la suite putty et générez vos clés avec PuTTYgen.

Mise en place de la clé publique sur le serveur

Il faut maintenant envoyer la clé publique sur le serveur et la placer dans le fichier ~/.ssh/authorized_keys. Ce fichier est utilisé lors de l’authentification pour déterminer si la clé privée de l’utilisateur est conforme à la clé publique inscrite dans le fichier.

Envoi de la clé si le serveur autorise l’authentification par mot de passe (sous client linux)

Nous allons utiliser ssh-copy-id qui permet d’envoyer notre clé publique automatiqument dans le fichier ~/.ssh/authorized_keys en remettant les bons droits d’écriture sur le fichier.

ssh-copy-id -i ~/.ssh/id_rsa.pub <username>@<ipaddress>

Si le port SSH n’est pas sur le port standard (22) :

ssh-copy-id -i ~/.ssh/id_rsa.pub -p <num_port> <username>@<ipaddress>

Autre méthode

Copiez le contenu de votre clé publique dans ~/.ssh/authorized_keys sur le serveur.

Configuration sur le serveur

Côté serveur, nous allons maintenant indiquer à ssh que nous souhaitons permettre la connexion par clés.

/etc/ssh/sshd_config :

RSAAuthentication yes
PubkeyAuthentication yes
StrictModes yes

Avec StrictMode = yes, donnez les bons droits à votre homedir sinon l’authentification risque d’échouer :

chmod go-w ~/
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Gardons pour le moment la possibilité de nous connecter avec un mot de passe ssh classique au cas où. Nous verrons pas la suite comment n’autoriser que l’authentification par clé.

Recharger le serveur ssh :

service sshd reload

Connexion avec votre clé privée

Sous linux

Modifiez ou créez le fichier ~/.ssh/config et adaptez le avec l’exemple ci-dessous :

~/.ssh/config

Host serveur1
  HostName serveur1.domain.tld
  User remi
  Port 22
  IdentityFile /home/remi/.ssh/id_rsa

Host serveur2
  HostName 192.168.1.120
  User remi
  Port 22
  IdentityFile /home/remi/autre_cle/private_key

HostName : Adresse ip ou nom de domaine du serveur

User : Utilisateur à utiliser en login

Port : Numéro du port à utiliser

IdentifyFile : Chemin vers votre clé privée à utiliser

Maintenant connectez-vous au serveur :

ssh serveur1

Indiquez votre passphrase (la clé de déverrouillage de la clé privée que nous avons généré)

Si tout va bien vous êtes maintenant connecté au serveur.

Vous pouvez ajouter votre clé privée dans votre agent ssh pour éviter de devoir taper votre passphrase à chaque fois (il faudra quand même le refaire à chaque ouverture de session) :

ssh-add ~/.ssh/id_rsa

Indiquez votre passphrase pour dévérouiller la clé.

Maintenant connectez-vous au serveur :

ssh serveur1

La passphrase ne vous est pas demandée et vous êtes connecté.

Il est possible aussi de se connecter directement sans passer par le fichier de config :

ssh <username>@<ipaddress>

Petite astuce : Avec le gestionnaire de mot de passe keepassXC, il est possible de déverrouiller automatiquement les clés privées qui sont enregistré dans votre base de mot de passe à son ouverture. Pour une fois que sécurité et pratique s’entendent !

Sous windows

Utilisez la suite putty et ajoutez votre clé publique sur Pagent.

Désactiver l’authentification par mot de passe

Attention ! Soyez sûr que votre accès par clé privée est bien opérationnel sinon vous perdrez tout accès ssh à votre machine !

Seul les authentifications par clé seront possibles !

Modifiez la configuration du fichier /etc/ssh/sshd_config :

/etc/ssh/sshd_config

ChallengeResponseAuthentication no
PasswordAuthentication no

Puis redémarrez le serveur ssh :

service sshd reload

Terminé !

Pourquoi installer le https ?

Le HTTPS est un protocole qui permet d’encrypter les échanges entre ton serveur et le navigateur web. Ainsi, il est impossible à un pirate de récupérer les identifiants que tu saisis pour te loguer sur ton site. En HTTP, les identifiants passent en clair et sont facile à intercepter.

Il nécessite de créer un certificat SSL qui permettra d’initialiser les échanges cryptés. 

C’est payant ?

Pour être reconnu par un navigateur web, le certificat SSL doit être signé par un organisme de certification. Ces organisme font payer cette certification. Depuis quelques années, Let’s encrypt permet de générer des certificats SSL gratuitement ! C’est une excellente nouvelle pour l’évolution globale de la sécurité sur internet.

Tu peux aussi signer toi même ton certificat SSL, il ne sera alors pas connu par les navigateurs et tu aura une page d’erreur du genre :

Dans le cas d’un site en local, ce n’est pas grave, il te suffit de passer cette alerte et tu peux consulter ton site en toute sécurité car la couche SSL qui crypte les données fait quand même son travail.

Par contre, si un hacker venait à prendre le contrôle de ton serveur et modifiait ton certificat SSL, il serai alors en mesure de décrypter les échanges. Mais bon … Je pense qu’une fois le hacker sur ton serveur, il peut aisément avoir accès à tes données.

Le cas d’un certificat auto-signé peut être intéressant pour la gestion d’un intranet. L’idée serait de générer un certificat maître auto-signé qui signerait ensuite lui même tous les certificats SSL de l’ensemble des services utilisé dans l’intranet. C’est ce qu’on appelle une PKI (Public Key Infrastructure).

On peut ensuite installer le certificat maître sur tout les postes des utilisateurs de l’intranet. Ces dernier pourront alors consulter tous les sites en HTTPS sans avoir d’alerte de sécurité et l’administrateur de l’intranet garde la main pour pouvoir ajouter de nouveaux certificats valides.

La gestion des PKI fera l’objet d’un article que je sortirai bientôt 🙂

Dans cet article on va s’intéresser à la création d’un certificat simple auto-signé.

Créer le certificat

Prérequis

Nous allons travailler avec un site hébergé sur un serveur Linux (avec accès root). Nous utiliserons Apache2 pour le serveur web.

Openssl doit être installé pour générer les certificats.

apt-get install openssl

Génération de la clé privée

On va créer une clé privée de 4096 bit encrypté avec l’algorithme de cryptage AES 256 bit.

openssl genrsa -aes256 -out certificat.key 4096

Entres un mot de passe pour ta clé (penses à bien le conserver).

On a généré une clé privée protégée par mot de passe, on va maintenant générer cette même clé mais déverrouillée.

Si tu ne souhaites pas la déverrouiller, le mot de passe de la clé sera demandé à chaque redémarrage de Apache2.

Dans un premier temps on va renommer notre clé :

mv certificat.key certificat.key.lock

Puis générer notre certificat déverrouillé :

openssl rsa -in certificat.key.lock -out certificat.key

Saisisses le mot de passe de la clé, le fichier déverrouillé est créé.

Ta clé privée déverrouillée : certificat.key

Ta clé privée verrouillée : certificat.key.lock

Génération du fichier de demande de signature

Ce fichier va être utile pour obtenir notre certification de l’organisme ou pour auto-signer notre certificat.

openssl req -new -key certificat.key.lock -out certificat.csr

Renseignes les différents champs demandés comme tu veux.

Ton fichier de demande de signature : certificat.csr

Génération du certificat

Pour auto-signer ton certificat, exécutes la commande suivante :

openssl x509 -req -days 365 -in certificat.csr -signkey certificat.key.lock -out certificat.crt

Ton certificat : certificat.crt

Indiquer à Apache d’utiliser le certificat SSL

Première chose à faire, vérifier que le ssl est activé sur apache :

a2enmod ssl

Il va falloir ensuite créer un vHost sur le port 443 (port du https) :

/etc/apache2/site-availables/tuto.conf

<VirtualHost *:80>
    ServerName      tuto.remipoignon.fr
    # On redirige le port HTTP vers le port HTTPS
    Redirect        / https://www.remipoignon.fr
</VirtualHost>

<VirtualHost *:443>
    ServerName      tuto.remipoignon.fr
    DocumentRoot    /var/www/tuto
        
    SSLEngine on
    SSLCertificateFile    /etc/ssl/www/certificat.crt
    SSLCertificateKeyFile /etc/ssl/www/certificat.key
    # Facultatif, ici, on dit qu'on accepte tout les protocoles SSL sauf SSLv2 et SSLv3 (dont on accepte que le TLS ici)
    SSLProtocol all -SSLv2 -SSLv3
    # Facultatif, on dit que c'est le serveur qui donne l'ordre des algorithmes de chiffrement pendant la négociation avec le client
    SSLHonorCipherOrder on
    # Facultatif, algorithme de chiffrement disponibles (ne pas être trop méchant sinon beaucoup de navigateur un peu ancien ne pourront plus se connecter)
    SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES
</VirtualHost>

On active le vHost :

a2ensite tuto.conf
service apache2 restart

C’est tout, ton site est maintenant en HTTPS