Accéder au Pi par SSH depuis Linux : authentification par clé

cle ssh

Pour accéder à un serveur (le Rasperry Pi) par SSH, il y a deux solutions :

  • taper un mot de passe à chaque connexion
  • s'identifier par une clé avec ou sans mot de passe.

L'utilisation d'une clé SSH avec mot de passe est la solution la plus sûre.

 

Malgré tout, nous allons voir ici l'installation d'une clé sans mot de passe pour des raisons de commodité mais aussi pour pouvoir plus tard mettre en place une sauvegarde automatique d'un serveur nextcloud sur le Pi.

Ce guide concerne une installation depuis Linux. La version Windows est consultable ici.

Clé SSH : Fonctionnement

 

Pour se connecter en SSH à un serveur, le client (l'ordinateur depuis lequel on établit la connexion) va devoir s'authentifier.

Soit il le fait grâce à un mot de passe, soit par une clé.

 

Avantages d'une clé d'authentification SSH

L'identification par  un mot de passe a plusieurs inconvénients :

  • il faut taper un mot de passe à chaque connexion SSH. Il est difficile dans ce contexte d'opérer une connexion automatique (dans le cas d'une sauvegarde automatique depuis un poste client par exemple).
  • pour éviter les attaques par force brute, il faut choisir un mot de passe complexe, difficile à retenir et pénible à taper au clavier.
  • l'échange de mot de passe est susceptible d'être vulnérable à une attaque de l'homme du milieu (interception de l'échange entre le client et le serveur) ou d'un key-logger (logiciel espion enregistrant les frappes sur le clavier).

L'identification par clé SSH permet de dépasser ces inconvénients :

  • possibilité d'authentification sans mot de passe et sans frappe sur le clavier.
  • inviolabilité de la clé largement supérieure à un mot de passe complexe.

 

Inconvénients d'une clé d'authentification SSH

Il y a tout de même quelques inconvénients à l'utilisation d'une clé SSH :

  • si l'on utilise une clé SSH sans mot de passe, elle est stockée sur l'ordinateur client en clair. N'importe qui ayant accès à cet ordinateur peut donc lire ou recopier la clé. Il est donc important que l'ordinateur client disposant de cette clé soit lui-même protégé (chiffrement du disque dur par exemple).

 

  • la clé privée doit être présente sur chaque appareil client. Si on est susceptible de se connecter depuis plusieurs ordinateurs, cela pose le problème de transfert de la clé privée à chacun des clients. Ce point est à considérer en particulier quand on ne peut pas faire une copie physique par clé USB par exemple (le transfert de la clé privée par internet est en effet déconseillé pour des raisons de sécurité).

 

Principe de l'authentification par clé

L'authentification par clé fait intervenir 2 clés :

  • une clé privée stockée sur l'ordinateur client (celui depuis lequel on se connecte)
  • une clé publique sur le serveur (celui vers lequel on se connecte).

Lorque l'on se connecte, le serveur va vérifier que la clef publique dont il dispose correspond à la clé privée stockée sur le client. Si c'est le cas, la connexion est établie.

Il est possible d'ajouter un mot de passe à cette authentification. À la première connexion SSH lors d'une session, il faut alors donner le mot de passe configuré pendant de la génération des clefs.

Durant le reste de la session, il ne sera plus nécessaire de redonner ce mot de passe.

Installation de l'authentification SSH par clé

Préparatifs

Au préalable, nous allons nous connecter sur le serveur (ici le Raspberry Pi) pour créer un répertoire qui accueillera la clef SSH publique.

Dans cet exemple, le login de l'utilisateur est lambda_user et l'adresse sur le réseau est 192.168.0.15.

 

$ ssh lambda_user@192.168.0.15
lambda_user@myweb:~ $ cd
lambda_user@myweb:~ $ mkdir .ssh
lambda_user@myweb:~ $ logout

 

Depuis l'ordinateur client, nous allons vérifier qu'aucune clé SSH n'existe déjà :

$ ls -al .ssh

Si vous avez :

  • soit le message d'avertissement suivant :
ls: impossible d'accéder à '.ssh': Aucun fichier ou dossier de ce type
  • soit une liste de fichiers ne contenant pas id_rsa et id_rsa.pub
total 12
drwx------ 2 lambda_user users 4096 14 janv. 10:41 .
drwx------ 38 lambda_user users 4096 14 janv. 10:41 ..
-rw-r--r-- 1 lambda_user users 174 14 janv. 10:31 known_hosts

cela signifie qu'aucune clé ssh n'est installée.

Par contre, si les fichiers id_rsa et id_rsa.pub sont affichés, la clé est déjà créée. Il n'est pas utile de la regénérer :

$ ls -al .ssh/
total 20
drwx------ 2 lambda_user users 4096 14 janv. 10:43 .
drwx------ 38 lambda_user users 4096 14 janv. 10:41 ..
-rw------- 1 lambda_user users 3243 14 janv. 10:30 id_rsa
-rw-r--r-- 1 lambda_user users 737 14 janv. 10:30 id_rsa.pub
-rw-r--r-- 1 lambda_user users 174 14 janv. 10:31 known_hosts

Création de la clé SSH

Dans le cas où aucune clé SSH n'existe déjà, nous allons en créer une sur l'ordinateur client (celui qui va se connecter sur le serveur) avec la commande :

ssh-keygen -b 4096

Generating public/private rsa key pair.
Enter file in which to save the key (/home/ubuntu_user/.ssh/id_rsa):

Taper Entrée pour garder le nom de clef par défaut (id_rsa)

Enter passphrase (empty for no passphrase):

Taper Entrée afin de ne pas avoir à taper un mot de passe à la première authentification par session (recommandé pour installer ensuite une sauvegarde automatique de fichiers depuis le serveur par SSH), sinon taper un mot de passe fort.

Enter same passphrase again:

Retaper Entrée pour ne pas avoir de mot de passe, ou redonner le mot de passe choisi précédemment.

Your identification has been saved in /home/ubuntu_user/.ssh/id_rsa. 
Your public key has been saved in /home/ubuntu_user/.ssh/id_rsa.pub. 
The key fingerprint is: SHA256:sVIifzsR4N3g5YaqCNB9AoHUY6wKpCnLfNeBayee7ac ubuntu_user@ubuntu 
The key's randomart image is: 
+---[RSA 4096]----+
|.o=.  . . .      |
|.o B . + *       |
|+.+ = = B +      |
|*.   * = =       |
|B.    * S        |
|o+ o * = o       |
|  o = = o        |
|     o . o       |
|      .Eo        |
+----[SHA256]-----+

Les deux clés SSH ont été générées. On peut le vérifier avec la commande :

$ ls -al .ssh

qui indiquera la présence des fichiers id_rsa (clé privée) et id_rsa.pub (clé publique).

Copie de la clé publique sur le serveur

Maintenant que les deux clés ont été créées, il faut copier la clé publique sur le serveur (le Raspberry Pi).

On utilise la commande ssh-copy-id pour cela :

$ ssh-copy-id -i ~/.ssh/id_rsa.pub lambda_user@192.168.0.15

/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/ubuntu_user/.ssh/id_rsa.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
lambda_user@192.168.0.15's password:

Donner le mot de passe de l'utilisateur du serveur (du Pi) :

Number of key(s) added: 1

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

Pour vérifier, on se connecte sur le serveur Pi :

$ ssh lambda_user@192.168.0.15

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: Sat Jan 14 11:17:22 2017 from 192.168.0.11

On arrive maintenant directement sur le Pi sans taper de mot de passe.

 

Désactiver l'authentification par mot de passe

Maintenant que l'authentification par clé est fonctionnelle, on peut désactiver l'authentification par mot de passe pour gagner en sécurité.

On peut également garder les deux méthodes d'authentification si on souhaite utiliser le mot de passe pour se connecter depuis des ordinateurs différents et uniquement utiliser la clé pour une sauvegarde automatique du serveur vers le client par exemple.

Pour enlever la possibilité de s'authentifier par mot de passe, sur le serveur (le Raspberry Pi), il faut modifier la configuration de SSH.

$ ssh lambda_user@192.168.0.15

Une fois sur le serveur :

$ sudo nano /etc/ssh/sshd_config

Dans la fenêtre qui s'ouvre, chercher la ligne :

PasswordAuthentication yes

et modifier ainsi :

PasswordAuthentication no

Ctrl-o pour enregistrer les changements, Ctrl-x pour quitter l'éditeur.

Redémarrer le serveur pour prendre en compte les modifications.

 

La connexion SSH grâce à une clef et sans mot de passe est installée.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *