Différences

Ci-dessous, les différences entre deux révisions de la page.

--- start:raspberry:ssh [2020/08/26 19:07] – modification externe 127.0.0.1
+++ start:raspberry:ssh [2024/06/20 19:37] (Version actuelle) – [SSH c’est quoi ?] gerardadmin
@@ Ligne 1: / Ligne 1: @@
 ======= SSH c’est quoi ? =======
+[[start:raspberry:ssh:clefpublique|inserer la clef publique sur le serveur]]
 Avant de voir comment contrôler la Raspberry Pi avec SSH, voyons exactement ce qu’est SSH.
@@ Ligne 14: / Ligne 16: @@
 De façon générale, SSH permet de se connecter à distance sur une machine en utilisant un compte utilisateur de la dite machine.
-Pour cela, l’ordinateur qui doit se connecter à la machine distante va fournir à celle-ci le nom de l’utilisateur à utiliser et son mot de passe. Il est possible dans certains cas d’utiliser un jeu de certificats sur l’ordinateur et la machine distante, permettant ainsi d’obtenir une connexion sécurisée sans avoir à taper un mot de passe. Il s’agit là d’un cas d’utilisation plus poussé que nous n’aborderons pas ici.
+Pour cela, l’ordinateur qui doit se connecter à la machine distante va fournir à celle-ci le nom de l’utilisateur à utiliser et son mot de passe. Il est possible dans certains cas d’utiliser un jeu de certificats sur l’ordinateur et la machine distante, permettant ainsi d’obtenir une connexion sécurisée sans avoir à taper un mot de passe. Il s’agit là d’un cas d’utilisation plus poussé que nous aborderons plus loin.
 Par défaut SSH propose uniquement une prise de contrôle en lignes de commande. Il est possible dans certains cas d’ajouter une interface graphique mais il s’agit là d’une méthode plus complexe que nous ne verrons pas ici.
@@ Ligne 87: / Ligne 89: @@
 - Clés asymétriques : http://www.it-connect.fr/les-cles-asymetriques/
-I. Génération de la clé
+__I. Génération de la clé__
 Étant donné qu'un client SSH peut être un client Linux ou un client Windows, nous allons voir comment générer cette paire de clés sous Linux en ligne de commande, et sous Windows via PuttyGen.
@@ Ligne 122: / Ligne 125: @@
 Pour rappel, nous nous situons toujours ici sur un Linux client, on remarque l'existence d'un autre fichier "known_hosts", il s'agit ici d'un fichier permettant d'identifier un serveur. Si vous vous connectez en SSH à plusieurs serveurs depuis votre utilisateur ("root" dans mon cas), votre fichier known_host va peu à peu se remplir. Cela entraîne entre autre le fait qu'une demande validation de la clé serveur est demandée à la première connexion du serveur mais pas lors des connexions suivantes.
+======= Comment se connecter en SSH sans mot de passe?  =======
+https://tutox.fr/2017/04/08/se-connecter-ssh-de-passe/
+Le grand classique du « comment faire communiquer 2 machines en SSH sans mot de passe »? Souvent on a besoin pour des scripts d’automatisation de s’affranchir de l’authentification par mot de passe entre 2 machines.
+Le SSH permet d’assurer la l‘authentification, la confidentialité des échanges entre 2 machines. C’est à dire que tout ce qui passe dans les tuyaux entre les 2 machines est chiffré.
+==== Comment SSH fait il?====
+Il s’appuie sur la cryptographie asymétrique. Un nom bien pompeux derrière lequel se cache un mécanisme simple et rudement efficace.
+==Le principe:==
+On va reprendre le fameux exemple du « bob et alice ».
+BOB souhaite parler à ALICE de manière confidentielle. Pour ce faire, ils disposent chacun de 2 clés:
+    *1 clé privée et 1 clé publique.
+    *ALICE envoie en clair sa clé publique à BOB . Au passage, comme son nom l’indique , n’importe qui peut avoir accès à la clé publique d’ALICE. N’importe qui souhaitant communiquer avec elle utilise la clé publique d’ALICE.
+La clé publique d’ALICE ,c’est en quelque sorte comme un cadenas que BOB va apposer sur son message.
+==chiffrement asymetrique==
+Ok , maintenant que Bob possède la clé publique d’ALICE, il va pouvoir lui écrire et chiffrer son message . (mettre son petit cadenas dessus : – )
+Seule, ALICE avec sa clé privée pourra déchiffrer le contenu du message de BOB. La clé privée est en quelque sorte la clé qui ouvre le cadenas posé par BOB.
+Scenario inverse:
+    *Alice veut répondre à BOB.
+    *Alice =>demande la clé publique de BOB
+    *BOB=>envoie en clair sa clé publique à ALICE
+    *ALICE chiffre son message avec la clé publique de BOB
+    *BOB recoit le message et le déchiffre avec sa clé privée.
+Concrètement, les commandes…
+On veut que la machine A se connecte sur la machine B sans mot de passe.
+__1/ Générer les clés publiques (sur la machine A)__
+**ssh-keygen -t  rsa**
+Répondre « oui » et « rien » aux questions qui vous seront posées.
+fichiers sont générés dans le répertoire « ~/.ssh »
+    *id_rsa => c’est la clé privée. A conserver précieusement à l’abri des indiscrets sur sa machine.
+    *id_rsa.pub => c’est la clé publique. Que l’on peut transmettre à tous ceux qui veulent communiquer avec moi.
+__2/ Copier la clé publique de la machine A__
+**ssh-copy-id user@machineB**
+Vous devriez voir ces messages:
+/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/root/.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
+Rentrer le mot de passe habituel pour accéder à B.
+Cette commande a pour effet de copier le contenu de la clé publique de A dans le fichier « ~/.ssh/authorized_keys » de B.
+__3/ Tester la connexion de A vers B__
+**ssh user@machineB**
+et là magie magie, vous êtes directement connecté sur la machine B.
+NOTA BENE:
+Si c’est la toute première connexion de A vers B alors un message du type:
+The authenticity of host 'machineB (192.168.2.3)' can't be established. RSA key fingerprint is c6:ee:c6:e4:9a:b6:7e:46:4c:17:b4:d0:7b:80:af:2c. Are you sure you want to continue connecting (yes/no)?
+Répondre « yes » , l’empreinte la machine B sera copié dans le fichier « ~/.ssh/known_hosts » de la machine A.
+__4/ pour les curieux__
+Sur la machine B:
+**cat /home/user/.ssh/authorized_keys**
+on retrouve la clé publique de la machine A:
+ssh-rsaAAAAB3NzaC1yc2EAAAADAQABAAABAQDIAePqXozbqzerGr3jCj7nF2Vd2Bqi7BbQJXw/ROGH+210Y41kEe9gzioV /Q86z31pMJdUhC+LU96wiBPbPMUlPqSNBckcbmQK0LoWZYaxwrlFdqcmbAhqx9lHywPCQdJCIGkkk9sFsuSmxli7mfuzNjKVdA6C8BuGvEgM1QBWQ9gGPIKCs+BXkCtfU1KyxZOdNnnP9apT/i2P+Pk3XocJJuXSR887Vu81a/hG2uy46/M8t/n7/Btrt44FZZ root@machineA
+Si on supprimait cette clé du fichier authorized_keys de la machine B, à la prochaine tentative de connexion de A vers B, un mot de passe serait demandé.
+Remarque:
+Pour être plus précis, le protocole SSH utilise le chiffrement asymétrique pour que client et serveur s’échange une clé de session.(je simplifie au max et ne parle pas de toutes les étapes pour ne pas embrouiller). Cette clé de session va permettre ensuite de chiffrer le reste des communications entre les 2 machines.
+__5/ sécurité?__
+    *ne pas créer de connexions ssh automatique sans mot de passe pour Root.
+    *Conserver sa clé privée comme la prunelle de ses yeux . Au besoin la sauvegarder dans un lieu sûr.
+    *Du coup ,mettre des droits restrictifs sur la clé privée id_rsa. ( par exemple : chmod 600 id_rsa)
+===== Lien Web =====
+[[https://www.linuxpedia.fr/doku.php/commande/ssh|Doc SSH ]]
+[[start:raspberry:ssh:doc|Doc ssh interne]]