Bypass Rsync Prompt “Êtes-vous sûr de vouloir continuer à vous connecter”

Définissez l’option SsortingctHostKeyChecking sur no , soit dans le fichier de configuration, soit via -o .

Utilisez l’option de rsync pour transmettre les options à ssh :

 -e "ssh -o SsortingctHostKeyChecking=no" 

Donc, je trouvais beaucoup de réponses non sécurisées qui marchaient – mais le meilleur moyen n’est pas beaucoup plus de travail, alors j’ai cherché des articles qui conseillent la façon la moins sécurisée de faire les choses liées à SSH, comme rsync. Je cherchais un moyen banal de contourner l’interaction manuelle inconnue de l’hôte consistant à cloner un repo git comme indiqué ci-dessous, mais cela fonctionne comme mentionné dans rsync et d’autres technologies:

 brad@computer:~$ git clone [email protected]:viperks/viperks-api.git Cloning into 'viperks-api'... The authenticity of host 'bitbucket.org (104.192.143.3)' can't be established. RSA key fingerprint is 97:8c:1b:f2:6f:14:6b:5c:3b:ec:aa:46:46:74:7c:40. Are you sure you want to continue connecting (yes/no)? 

Notez l’empreinte de la clé RSA …

Donc, ceci est une chose SSH, cela fonctionnera pour git sur SSH et juste des choses liées à SSH en général …

 brad@computer:~$ nmap bitbucket.org --script ssh-hostkey Starting Nmap 7.01 ( https://nmap.org ) at 2016-10-05 10:21 EDT Nmap scan report for bitbucket.org (104.192.143.3) Host is up (0.032s latency). Other addresses for bitbucket.org (not scanned): 104.192.143.2 104.192.143.1 2401:1d80:1010::150 Not shown: 997 filtered ports PORT STATE SERVICE 22/tcp open ssh | ssh-hostkey: | 1024 35:ee:d7:b8:ef:d7:79:e2:c6:43:9e:ab:40:6f:50:74 (DSA) |_ 2048 97:8c:1b:f2:6f:14:6b:5c:3b:ec:aa:46:46:74:7c:40 (RSA) 80/tcp open http 443/tcp open https Nmap done: 1 IP address (1 host up) scanned in 42.42 seconds 

Tout d’abord, installez nmap sur votre pilote quotidien. nmap est très utile pour certaines choses, comme la détection des ports ouverts, et cela pour vérifier manuellement les empreintes digitales SSH. Mais revenons à ce que nous faisons.

Bien. Je suis soit compromis aux endroits et aux machines multiples que j’ai vérifié – soit l’explication plus plausible de ce que tout est en train de se passer est ce qui se passe.

Cette «empreinte» est simplement une chaîne raccourcie par un algorithme à sens unique pour notre commodité humaine, au risque de voir plusieurs chaînes se résorber dans la même empreinte. Cela arrive, ils s’appellent des collisions.

Indépendamment, retour à la chaîne d’origine que nous pouvons voir dans le contexte ci-dessous.

 brad@computer:~$ ssh-keyscan bitbucket.org # bitbucket.org SSH-2.0-conker_1.0.257-ce87fba app-128 no hostkey alg # bitbucket.org SSH-2.0-conker_1.0.257-ce87fba app-129 bitbucket.org ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAubiN81eDcafrgMeLzaFPsw2kNvEcqTKl/VqLat/MaB33pZy0y3rJZtnqwR2qOOvbwKZYKiEO1O6VqNEBxKvJJelCq0dTXWT5pbO2gDXC6h6QDXCaHo6pOHGPUy+YBaGQRGuSusMEASYiWunYN0vCAI8QaXnWMXNMdFP3jHAJH0eDsoiGnLPBlBp4TNm6rYI74nMzgz3B9IikW4WVK+dc8KZJZWYjAuORU3jc1c/NPskD2ASinf8v3xnfXeukU0sJ5N6m5E8VLjObPEO+mN2t/FZTMZLiFqPWc/ALSqnMnnhwrNi2rbfg/rd/IpL8Le3pSBne8+seeFVBoGqzHM9yXw== # bitbucket.org SSH-2.0-conker_1.0.257-ce87fba app-123 no hostkey alg 

Donc, à l’avance, nous avons un moyen de demander une forme d’identification à l’hôte d’origine.

À ce stade, nous sums manuellement aussi vulnérables qu’automatiquement – les chaînes correspondent, nous avons les données de base qui créent l’empreinte et nous pourrions demander ces données de base (prévention des collisions) à l’avenir.

Maintenant, utilisez cette chaîne d’une manière qui empêche de poser des questions sur l’authenticité d’un hôte …

Le fichier known_hosts dans ce cas n’utilise pas les entrées en texte clair. Vous connaissez les entrées hachées lorsque vous les voyez, elles ressemblent à des hachages avec des caractères aléatoires au lieu de xyz.com ou 123.45.67.89.

 brad@computer:~$ ssh-keyscan -t rsa -H bitbucket.org # bitbucket.org SSH-2.0-conker_1.0.257-ce87fba app-128 |1|yr6p7i8doyLhDtrrnWDk7m9QVXk=|LuKNg9gypeDhfRo/AvLTAlxnyQw= ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAubiN81eDcafrgMeLzaFPsw2kNvEcqTKl/VqLat/MaB33pZy0y3rJZtnqwR2qOOvbwKZYKiEO1O6VqNEBxKvJJelCq0dTXWT5pbO2gDXC6h6QDXCaHo6pOHGPUy+YBaGQRGuSusMEASYiWunYN0vCAI8QaXnWMXNMdFP3jHAJH0eDsoiGnLPBlBp4TNm6rYI74nMzgz3B9IikW4WVK+dc8KZJZWYjAuORU3jc1c/NPskD2ASinf8v3xnfXeukU0sJ5N6m5E8VLjObPEO+mN2t/FZTMZLiFqPWc/ALSqnMnnhwrNi2rbfg/rd/IpL8Le3pSBne8+seeFVBoGqzHM9yXw== 

La première ligne de commentaire montre de façon exaspérante – mais vous pouvez vous en débarrasser avec une simple redirection via la convention “>” ou “>>”.

Comme j’ai fait de mon mieux pour obtenir des données non contaminées à utiliser pour identifier un “hôte” et faire confiance, je vais append cette identification à mon fichier known_hosts dans mon répertoire ~ / .ssh. Comme il sera maintenant identifié comme hôte connu, je ne recevrai pas l’invite mentionnée ci-dessus lorsque vous étiez jeune.

Merci de restr avec moi, vous voilà. J’ajoute la clé RSA de bitbucket pour que je puisse interagir avec mes référentiels git de manière non interactive, dans le cadre d’un stream de travail CI, mais peu importe ce que vous faites.

 #!/bin/bash cp ~/.ssh/known_hosts ~/.ssh/known_hosts.old && echo "|1|yr6p7i8doyLhDtrrnWDk7m9QVXk=|LuKNg9gypeDhfRo/AvLTAlxnyQw= ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAubiN81eDcafrgMeLzaFPsw2kNvEcqTKl/VqLat/MaB33pZy0y3rJZtnqwR2qOOvbwKZYKiEO1O6VqNEBxKvJJelCq0dTXWT5pbO2gDXC6h6QDXCaHo6pOHGPUy+YBaGQRGuSusMEASYiWunYN0vCAI8QaXnWMXNMdFP3jHAJH0eDsoiGnLPBlBp4TNm6rYI74nMzgz3B9IikW4WVK+dc8KZJZWYjAuORU3jc1c/NPskD2ASinf8v3xnfXeukU0sJ5N6m5E8VLjObPEO+mN2t/FZTMZLiFqPWc/ALSqnMnnhwrNi2rbfg/rd/IpL8Le3pSBne8+seeFVBoGqzHM9yXw==" >> ~/.ssh/known_hosts 

Alors, c’est comme ça que tu rests vierge pour aujourd’hui. Vous pouvez faire la même chose avec github en suivant des instructions similaires sur votre temps.

J’ai vu tellement de messages de dépassement de stack vous indiquant d’append la clé à l’aveuglette sans vérification. Plus vous vérifiez la clé depuis différentes machines sur différents réseaux, plus vous pouvez avoir confiance dans le fait que l’hôte est celui qu’il dit être – et c’est ce que vous pouvez espérer de cette couche de sécurité.

FAUX ssh -oSsortingctHostKeyChecking = no hostname [commande]

FAUX ssh-keyscan -t rsa -H nom_hôte >> ~ / .ssh / known_hosts

Ne faites aucune des choses ci-dessus, s’il vous plaît. Vous avez la possibilité d’augmenter vos chances d’éviter que quelqu’un vous écoute sur vos transferts de données via un attaquant intermédiaire – saisissez cette opportunité. La différence est de vérifier littéralement que la clé RSA que vous avez est celle du serveur de bonne foi et que vous savez maintenant comment obtenir ces informations pour pouvoir les comparer afin de pouvoir faire confiance à la connexion. Rappelez-vous simplement que plus de comparaisons provenant de différents ordinateurs et réseaux augmenteront votre capacité à faire confiance à la connexion.