ssh

Rédigé par Paulo Aucun commentaire
Classé dans : Linux Mots clés : ssh


 

Rappel :  SSH utilise les 2 protocoles de chiffrement

  1. chiffrement assymétrique : en début de communication pour l'échange des clés publiques (clé de chiffrement) entre les deux serveurs.
    La cryptographie asymétrique utilise une clé de chiffrement (clé publique)  et une clé de dechiffrement (clé privée).
    Le terme asymétrique s'applique dans le fait qu'il y a deux clés, telles que si l'utilisateur utilise une première clé (publique) dans un algorithme dit « de chiffrement », la donnée devient inintelligible à tous ceux qui ne possèdent pas la deuxième clé (privée). Cette clé est donnée en entrée d'un algorithme dit « de déchiffrement ».
     
  2. chiffrement symétrique : pour la suite des échanges car ce protocole est entre 100 et 1000 fois plus rapide.
    La cryptographie symétrique est la plus ancienne forme de chiffrement. Elle permet à la fois de chiffrer et de déchiffrer des messages à l'aide d'un même mot clé.

 


Fichiers du repertoire $HOME/.ssh :
J'ai choisi RSA (de Ron Rivest, Adi Shamir et Len Adleman) au moment de la génération des clés

  • id_rsa : contient la clé privée (idéalement cryptée avec une passphrase)
    A conserver précieusement...mon précieux !
    Utilisée uniquement pour le déchiffrement.
     
  • id_rsa.pub : contient la clé publique
    Utilisée uniquement pour le chiffrement
     
  • known_hosts : empreinte (fingerprint) du serveur
    Numéro unique qui vous permet d'identifier le serveur. Si demain quelqu'un essaie de se faire passer pour le serveur, le fingerprint changera forcément et vous saurez qu'il se passe alors quelque chose d'anormal


 

Etapes de création d'un canal SSH sécurisé :

  • le serveur envoie clé publique en clair afin que le client puisse chiffrer
    Pas de risque de vol puisque cette clé 'ne sert qu'à chiffrer'
  • le client génère aussi une clé de chiffrement (donc pubique) qu'il chiffre avec la clé reçue dans l'étape précedente et l'envoie au serveur
    Pas de risque d'interception puisque cette clé 'ne sert elle aussi qu'à chiffrer'' et nécessite cle privée pour le déchiffrement
  • le serveur déchiffre la clé reçue avec sa clé privée

    A ce stade, le client et le serveur connaissent les clé publiques de chiffrement sans jamais avoir échangé de clé privée sur le rezo. Les échanges entre les deux serveurs se feront pour la suite en mode symétrique pour des raisons de performance.
    Le client peut se connecter au serveur :-)


Authentification par clé sous linux :
 

# echange de clé du user toto entre client et serveur
ssh-copy-id toto@serveur

# pour ceux qui ont envie de se faire ch...,il faut rajouter le contenu du fichier id_rsa.pub de $HOME du client dans le fichier
authorized_keys du serveur
[toto@client /]# cat ~/.ssh/id_dsa.pub | ssh toto@serveur "cat - > ~/.ssh/authorized_keys"
  • echange des clés pour connexion sans demande de mot de passe
    copie de la clé publique ($HOME/.ssh/id_rsa.pub) sur le serveur (authorized_keys)
    rappel :
        - si clés générées sans passphrase, les futures connexions se feront sans mot de passe (mais seront moins sécurisées...)
        - si passphrase, le ssh la demandera à chaque connexion : pénible  !
            solution : utiliser la commande  # ssh-agent $SHELL, puis # ssh-add
                            la passphrase ne sera demandée qu'une seule fois pour route la session  :-)
  • ssh client vers serveur :
  1.  verification de l'identité du serveur (clé hote dans le fichier known_hosts)
    Pour vérifier qu'on dialogue avec le bon serveur,  SSH vérifie l'empreinte(fingerprint ) de la clé publique reçue précedemment  (un serveur différent aura des clés différentes, et du coup des fingerprint différents).
    Le client OpenSSH fera ça tout seul et vous demandera de vérifier l'empreinte de la clé publique reçue en cas de doute.
    source : http://quack1.me/ssh_fingerprint_server.html
    [client@toto]$ ssh toto@serveur
    The authenticity of host '192.168.1.66 (192.168.1.66)' can't be established.
    RSA key fingerprint is SHA256:U7SPYuSe9+y9hh4Krl/ER5bWTmNgE8Mho6W7Yg7IRrc.
    RSA key fingerprint is MD5:13:80:ec:f5:24:cc:4e:a9:4e:29:18:02:dd:ca:5a:08.
    Are you sure you want to continue connecting (yes/no)? 
    
    # obtenir le fingerprint SSH d'une clé 
    [toto@client /]# ls /etc/ssh/*key*.pub
    [toto@client /]# ssh-keygen -lf /etc/ssh/ssh_host_ecdsa_key.pub
    
    
  2. puis vérification de l'identité du client <authorized_keys du serveur>


 

 

Les commentaires sont fermés.