ssh
Rédigé par Paulo
Aucun commentaire
Classé dans : Linux
Rappel : SSH utilise les 2 protocoles de chiffrement
|
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 :
-
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
- puis vérification de l'identité du client <authorized_keys du serveur>