Outils pour utilisateurs

Outils du site


start:raspberry:ssh

Différences

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

Lien vers cette vue comparative

Les deux révisions précédentesRévision précédente
Prochaine révision
Révision précédente
start:raspberry:ssh [2020/07/10 18:42] gerardadminstart:raspberry:ssh [2023/01/27 16:08] (Version actuelle) – modification externe 127.0.0.1
Ligne 87: Ligne 87:
  
 - Clés asymétriques : http://www.it-connect.fr/les-cles-asymetriques/ - 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. É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 123:
  
 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. 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.
 +
 +2 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]]
 +
/home/chanteri/www/fablab37110/data/attic/start/raspberry/ssh.1594399361.txt.gz · Dernière modification : 2023/01/27 16:08 (modification externe)