Outils pour utilisateurs

Outils du site


se_connecter_en_ssh_a_l_aide_de_cle_asymetrique

Description

Secure Shell (SSH) est à la fois un programme informatique et un protocole de communication sécurisé. Le protocole de connexion impose un échange de clés de chiffrement en début de connexion. Par la suite, tous les segments TCP sont authentifiés et chiffrés. Il devient donc impossible d'utiliser un sniffer pour voir ce que fait l'utilisateur.

Le protocole SSH a été conçu avec l'objectif de remplacer les différents programmes rlogin, telnet, rcp, ftp et rsh.

OpenSSH est un ensemble d'outils informatiques libres permettant des communications sécurisées sur un réseau informatique en utilisant le protocole SSH. Il est développé par l'équipe d'OpenBSD et est sous licence BSD modifiée.

Du point de vue de l'utilisateur une connexion ssh s'établit comme une session telnet (demande de connexion, demande de login, demande de mot de passe), le principe est en réalité beaucoup plus complexe.

SSH permet de garantir :

  • La confidentialité : le chiffrement des paquets permet de garantir celle-ci. Les anciens services tels que telnet, rlogin… envoyaient les données en clair.
  • L'intégrité : SSH permet de garantir que les paquets circulant d'un hôte vers un autre ne sont pas altérés.
  • L'authentification : chaque connexion SSH vérifie l'identité du serveur (par sa clé d'hôte ~/.ssh/known_hosts) puis celle du client (par mot de passe ou clé publique ~/.ssh/authorized_keys).
  • L'autorisation : il est possible avec SSH de limiter les actions autorisées à l'utilisateur (~/ssh/.authorization).
  • Tunneling : SSH permet de sécuriser un service dont les informations circulent habituellement en clair (POP, IMAP, VNC…). D'autres aspects du tunneling sont la sécurisation du protocole X11 (X11forwarding) , et l'utilisation de clés privées situées sur un hôte distant (Agent forwarding).

SSH est donc sécurisé mais ne protège pas de tout. L'authentification par mot de passe reste relativement vulnérable (mot de passe trop facile à découvrir… toute la difficulté d'un bon mot de passe : facile à retenir, difficile à découvrir par les autres).

L'authentification par clé

Face à la faiblesse de l'authentification par mot de passe, l'authentification par clé se révèle être très efficace.

La clé permet de garantir à un système qu'un utilisateur est bien celui qu'il prétend être… en deux mots : « Je jure et je prouve que c'est bien moi ».

L'authentification par clé fonctionne grâce à 3 composants :

  • Une clé publique : elle sera exportée sur chaque hôte sur lequel on souhaite pouvoir se connecter.
  • Une clé privée : elle permet de prouver son identité aux serveurs.
  • Une passphrase : Permet de sécuriser la clé privée (notons la subtilité, passphrase et pas password… donc « phrase de passe » et non pas « mot de passe »).

La sécurité est vraiment accrue car la passphrase seule ne sert à rien sans la clé privée, et vice-versa.

Installation

L'installation dois se faire des deux coté, sur le serveur que l'on veux atteindre, et sur le client, c'est à dire l'ordinateur que l'on utilise pour se connecter au serveur.

Coté serveur

Sur le serveur il suffit d'installer le paquet openssh-serveur qui installera tout ce qui est nécessaire pour pouvoir s'y connecter de base.

Pour debian et dérivé (ubuntu/Mint/handylinux):

apt-get install openssh-server

Pour fedora et dérivé (CentOS/Viperr)

yum install openssh-server

ou

dnf install openshh-server

Archlinux et dérivé (manjaro)

pacman -Syu openssh-server

Coté client

En général coté client il n'y à rien à faire, le paquet étant disponible par défaut sur la plupart des distribution. Dans le cas contraire, installez simplement le paquet openssh-client

Pour debian et dérivé (ubuntu/Mint/handylinux):

apt-get install openssh-client

Pour fedora et dérivé (CentOS/Viperr)

yum install openssh-clients

ou

dnf install openshh-common

Archlinux et dérivé (manjaro)

pacman -Syu openssh-client

Configuration

Création de la paire de clé

La création de la paire de clé se fait avec

ssh-keygen

Il existe 2 types de clés : RSA et DSA. Chacune pouvant être de longueur différente : 1024, 2048, 4096 bits (les clés inférieures à 1024 bits sont à proscrire… surtout les RSA). Pour créer une clé DSA de 2048 bits :

ssh-keygen -t dsa -b 2048 -C username@domain.tld

Sans paramètres, les options par défaut sont type RSA en 2048 bits.

Le commentaire permet de distinguer les clés, utile quand on a plusieurs clé (notamment une personnelle et une pour le boulot). Ici la distinction se fait sur l'adresse e-mail. Si le commentaire est omis, il sera de la forme user@host.

 $ ssh-keygen
 Generating public/private rsa key pair.
 Enter file in which to save the key (/home/user/.ssh/id_rsa):
 Enter passphrase (empty for no passphrase):
 Enter same passphrase again:
 Your identification has been saved in /home/user/.ssh/id_rsa.
 Your public key has been saved in /home/user/.ssh/id_rsa.pub.
 The key fingerprint is:
 XX:00:00:0X:X0:00:00:0X:X0:0X:XX:00:00:00:X0:00 username@domain.tld
 The key’s randomart image is:
 +–[ RSA 2048]—-+
 | . + *+.      |
 | * + +        |
 | . + o        |
 | . +          |
 | . S .        |
 | . .          |
 | ..o o        |
 | . . .o.o .   |
 |E . .. .o..   |
 +————-----—–---+

Deux fichiers ont été créés (dans le dossier ~/.ssh/) : * id_rsa (ou id_dsa dans le cas d'une clé DSA) : contient la clé privée et ne doit pas être dévoilé ou mis à disposition * id_rsa.pub (ou id_dsa.pub dans le cas d'une clé DSA) : contient la clé publique, c'est elle qui sera mise sur les serveurs dont l'accès est voulu.

Paramétrage de SSH

Le fichier de configuration est /etc/ssh/sshd_config.
L'authentification par clé est active par défaut. En fait, dans le fichier de configuration original, toutes les valeurs commentées (précédées d'un #) sont placées à leur valeur par défaut. En effet, la ligne

#PubkeyAuthentication yes 

Signifie que la valeur par défaut de la clé

PubkeyAuthentication

est Yes ; l'authentification par clé est autorisée. Si vous souhaitez modifier la valeur d'une clé, il suffit de la dé-commenter. La suite de ce tutoriel vous donnera quelques exemples.

Cela ne suffit bien entendu pas car aucune clé publique n'a été envoyée sur le serveur.

L'authentification par mot de passe va être utilisée * Première méthode de copie d'une clé :

[user@machine ~]$ cat ~/.ssh/id_rsa.pub | ssh user@ip_machine "cat - >> ~/.ssh/authorized_keys"
user@ip_machine's password:

Cette commande va lire le fichier $HOME/.ssh/id_rsa.pub (clé publique), se connecter sur le serveur ayant l'adress ip « ip_machine » avec le nom d'utilisateur « user » et ajouter au fichier des clés autorisées ($HOME/.ssh/authorized_keys) le contenu de la clé lue.

* Deuxième méthode de copie d'une clé :

Il s'agit du même principe que la première méthode sauf que tout est décomposé (utile pour bien comprendre) :

[user@machine ~]$ scp ~/.ssh/id_rsa.pub user@ip_machine:/tmp
user@ip_machine's password:
id_rsa.pub                                            100%  609     0.6KB/s   00:00
[user@machine ~]$ ssh user@ip_machine
[user@nom_machine ~]$ cat /tmp/id_rsa.pub >> /root/.ssh/authorized_keys
[user@nom_machine ~]$ rm /tmp/id_rsa.pub

* Troisième méthode :

Il s'agit de la méthode la plus automatisée et la plus simple (elle est a utiliser quand on a compris ce qu'elle va faire… )

 [user@machine ~]$ ssh-copy-id -i ~/.ssh/id_rsa.pub user@ip_machine
 root@machine's password:
 Now try logging into the machine, with "ssh 'user@ip_machine'", and check in:
 
 .ssh/authorized_keys
 
 to make sure we haven't added extra keys that you weren't expecting.

ssh-copy-id va copier la clé publique sur l'hôte distant. Par mesure de sécurité, le script ajoute l'extension .pub au fichier d'identité si elle a été omise.

Notez que si vous posédez plusieurs clés, cette commande risque d'en copier plusieurs. Pensez à vérifier le fichier ~/.ssh/authorized_keys sur ip_machine pour éventuellement supprimer les clés que vous ne souhaitez pas publier sur ce serveur.

La situation-cible sera alors:

PubkeyAuthentication yes
AuthorizedKeysFile      .ssh/authorized_keys
ChallengeResponseAuthentication yes

:!: Il est possible de définir la machine distante dans /etc/hosts (ou dans .ssh/config) pour qu'elle soit identifiée par son nom. De plus, si l'utilisateur auquel on souhaite se connecter est le même sur la machine distante, on remplacera « user@ip_machine » par « nom_machine ». Nous pourrons donc nous connecter plus simplement avec la commande suivante :

 [user@machine ~]$ ssh nom_machine

* Piège a éviter :

Il faut s'assurer dans le cas ou un fichier <path>authorized_keys</path> est présent, qu'il se termine bien par une nouvelle ligne. Sinon le rajout se fera à la volée et 2 clés (la dernière et celle rajoutée) seront inutilisables.

Configuration avancée

Conseils de sécurité

* Désactivation de l'authentification par mot de passe

Une fois que les clés sont générées, mises en place et que leur fonctionnement testé, il est souhaitable de désactiver l'authentification par mot de passe (ATTENTION, bien vérifier de pouvoir accéder physiquement au serveur… au cas où…). Cela se passe donc dans le fichier de configuration (/etc/ssh/sshd_config). Pour la suite, le nom de la machine distante correspond à « amraam » .

PasswordAuthentication yes

devient

PasswordAuthentication no

On relance le service sshd :

[root@machine ~]# service sshd reload
Rechargement de sshd :                                     [  OK  ]

Il n'est plus possible désormais de se connecter avec le couple login/password.

* Désactivation de l'accès direct en root. Il est possible de désactiver l'accès direct vers le compte root vers votre (et même vos ;-)) ordinateurs.

En effet, il n'est jamais très conseillé d'abuser des droits root, il est donc possible de désactiver la possibilité au root de se connecter. L'accès au serveur distant pourra être fait sur un autre compte utilisateur, quitte à faire un petit « su - » ensuite.
Pour ce faire, trouvez la ligne :

#PermitRootLogin yes

Attribuez-lui la valeur « no » et décommentez la ligne :

PermitRootLogin no 

Au prochain démarrage de votre démon sshd, il ne sera plus possible de se connecter directement à votre serveur sur le compte root via SSH.

* Liste des utilisateurs autorisés à se connecter

Il est possible de mettre en place la liste des utilisateurs qui seront seuls autorisés à se connecter avec la directive AllowUsers dans le fichier de configuration du démon SSH :

AllowUsers user builder@127.0.0.1

La page de manuel de sshd_config (man sshd_config) pourra vous apporter des compléments d'informations, ainsi que des directives qui ne sont pas abordées dans le présent article.

Configuration par utilisateur

La configuration par utilisateur se fait par le fichier .ssh/config. Voyons l'exemple suivant :

Host serveur
 HostName 10.42.0.1
 User client
 Port 22
 IdentityFile ~/.ssh/.id_rsa

Host *.gitorious.org

  IdentityFile ~/.ssh/.id_rsa_gitorious

Avec le fichier ci-dessus, la commande ssh serveur sera équivalente à ssh -p 22 -i ~/.ssh/.id_rsa client@10.42.0.1, ce qui est bien plus pratique. Préciser la clé d'identification permet donc d'en définir plusieurs, on remarque également que dans cet exemple, quelque soit l'utilisateur auquel on veut se connecter sur gitorious.org, le fichier d'identité est précisé.

ssh-agent

Le serveur SSH est maintenant plus sécurisé, mais taper des passphrases à longueur de journée peut se révéler être très pénible surtout si on a choisi une « vraie » passphrase.

L'agent SSH permet de taper la passphrase une seule fois et de la conserver en mémoire pendant tout son fonctionnement. Les communications SSH fonctionneront donc de façon transparente.

Il faut lancer l'agent avec un shell (le plus simple étant de le lancer avec la variable $SHELL qui contient le shell courant).
Ensuite le programme ssh-add permet de charger les clé présentes dans ~/.ssh/. La passphrase est demandée, toutes les connexions nécessitant les clés chargées par l'agent seront transparentes.

 [user@machine ~]$ ssh-agent $SHELL
 [user@machine ~]$ ssh-add
 Enter passphrase for /home/user/.ssh/id_rsa:
 Identity added: /home/user/.ssh/id_rsa (/home/user/.ssh/id_rsa)
 [user@machine ~]$ ssh user@ip_machine
 Last login: Mon Jul  3 17:21:20 2006 from ip_dernier_client

Si les clés ont été générées sur le serveur qui sera utilisé pour les connexions, il suffit alors de rajouter la clé publique dans le fichier ~/.ssh/authorized_keys par un :

[user@machine ~]$ cd .ssh
[user@machine .ssh]$ cat id_rsa.pub >> authorized_keys

Si les clés ne seront pas utilisées en tant que client SSH, elles peuvent être supprimées (id_rsa et id_rsa.pub) du serveur.

Correction des problèmes

Afin d'obtenir des information de débogage supplémentaires, ajoutez l'argument -vvv à votre commande ssh.

Première connexion

Lors de la première connexion SSH vers un hôte, ce message peut apparaitre :

The authenticity of host 'amraam (192.168.24.3)' can't be established.
RSA key fingerprint is c6:XX:c6:e4:9a:b6:7e:00:4c:00:b4:d0:7b:00:XX:2c.
Are you sure you want to continue connecting (yes/no)? 

Il faut répondre oui/yes lors de cette première connexion.

Warning: Permanently added 'amraam' (RSA) to the list of known hosts.

La clé d'hôte sur le serveur est maintenant conservée (fichier ~/.ssh/known_hosts) .

Changement de clé d'hôte sur le serveur

En cas de changement de clé le message suivant apparaitra :

 [user@machine ~]# ssh user@ip_machine
  @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 
  @    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!      @ 
  @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 
 IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
 Someone could be eavesdropping on you right now (man-in-the-middle attack)!
 It is also possible that the RSA host key has just been changed.
 The fingerprint for the RSA key sent by the remote host is
 c6:ee:c6:e4:9a:b6:7e:46:4c:17:b4:d0:7b:80:af:2c.
 Please contact your system administrator.
 Add correct host key in /home/user/.ssh/known_hosts to get rid of this message.
 Offending key in /home/user/.ssh/known_hosts:12
 RSA host key for amraam has changed and you have requested strict checking.
 Host key verification failed.

Un changement de clé peut avoir plusieurs cause : * La clé de l'hôte a été changée volontairement par un administrateur * Le serveur a subi une réinstallation sans sauvegarde de ses clés * Ce n'est plus le même serveur (et il faut donc se renseigner si c'est normal… Car cela peut être le serveur d'un pirate…)

Pour corriger le problème ('en cas de changement non suspect uniquement !!!'), il suffit :

  • soit de supprimer la clé du serveur dans ~/.ssh/known_hosts (ici dans la 12ème place)
  • soit de la modifier dans ~/.ssh/known_hosts afin de mettre la nouvelle clé de l'hôte si elle est connue

Les clés ne fonctionnent pas

Vérifiez que le répertoire .ssh ait les permissions 700 (rwx pour l'utilisateur, rien pour le groupe ni les autres) et que son contenu soit en 600 (rw pour l'utilisateur, rien pour le groupe ni les autres). Il faut aussi vérifier que chaque clé tient sur une ligne dans authorized_keys (même si elle apparait sur plusieurs ligne a l'écran, dans le fichier elle ne correspond qu'à une ligne).

Conclusion

En n'autorisant que la connexion par clé publique, le service ssh se retrouve fortement sécurisé.
C'est une opération qui n'est pas très complexe, mais qui nécessite néanmoins de bien comprendre le fonctionnement afin de le mettre en place dans de bonnes conditions.

Voir aussi

se_connecter_en_ssh_a_l_aide_de_cle_asymetrique.txt · Dernière modification: 2016/08/24 18:58 (modification externe)