Essayez ceci :
ssh-keyscan -t rsa [ip_address]
Prenez la sortie et collez-la dans .ssh/known_hosts.Maintenant, si vous voulez hacher les Known_hosts, faites ceci :
ssh-keygen -H
modifier : Voici la solution en une seule commande. Il utilise le nom d'hôte et les adresses IP et les hache tous les deux.
ssh-keyscan -Ht rsa [hostname],[IP address] >> known_hosts
La réponse de kschurig fonctionnera mais ce n'est pas forcément la plus sécurisée. Il obtient des points bonus pour avoir fait un effort supplémentaire pour vous permettre d'identifier le serveur par plus d'un URI, c'est-à-dire le nom d'hôte et l'adresse IP. C'est-à-dire que vous pouvez continuer à ajouter des URI valides de cet hôte en étendant la liste délimitée par des virgules.
Cependant, je cherchais un moyen banal de contourner l'interaction manuelle de l'hôte inconnu du clonage d'un dépôt git comme indiqué ci-dessous et cela devrait aider à expliquer ce qui se passe et comment vous pouvez éviter cette partie du script de quelque chose lié à SSH :
[email protected]:~$ 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, c'est une chose SSH, cela fonctionnera pour git sur SSH et juste pour les choses liées à SSH en général...
[email protected]:~$ 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 de ports ouverts et ceci - la vérification manuelle des empreintes digitales SSH. Mais revenons à ce que nous faisons.
Bien. Soit je suis compromis aux multiples endroits et machines que j'ai vérifiés, soit l'explication la plus plausible de tout ce qui se passe est ce qui se passe.
Cette "empreinte digitale" n'est qu'une chaîne raccourcie avec un algorithme à sens unique pour notre commodité humaine au risque que plus d'une chaîne se résolve dans la même empreinte digitale. Ça arrive, on les appelle des collisions.
Quoi qu'il en soit, revenons à la chaîne d'origine que nous pouvons voir dans le contexte ci-dessous.
[email protected]:~$ 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 sommes manuellement aussi vulnérables qu'automatiquement :les chaînes correspondent, nous avons les données de base qui créent l'empreinte digitale, et nous pourrions demander ces données de base (prévention des collisions) à l'avenir.
Maintenant, pour utiliser cette chaîne de manière à éviter de demander l'authenticité d'un hôte...
Le fichier known_hosts dans ce cas n'utilise pas d'entrées en clair. Vous saurez que 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.
[email protected]:~$ 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 apparaît de manière 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 une confiance, j'ajouterai cette identification à mon fichier known_hosts dans mon répertoire ~/.ssh. Puisqu'il sera désormais identifié comme un hôte connu, je n'obtiendrai pas l'invite mentionnée ci-dessus lorsque vous étiez jeune.
Merci de rester avec moi, voilà. J'ajoute la clé RSA bitbucket afin de pouvoir interagir avec mes dépôts git de manière non interactive dans le cadre d'un flux de travail CI, mais quoi que vous fassiez, ce que vous voulez.
#!/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 restes vierge pour aujourd'hui. Vous pouvez faire la même chose avec github en suivant des instructions similaires à votre rythme.
J'ai vu tant de messages de débordement de pile vous disant d'ajouter par programmation la clé aveuglément sans aucune sorte de vérification. Plus vous vérifiez la clé de différentes machines sur différents réseaux, plus vous pouvez avoir confiance que l'hôte est celui qu'il dit être - et c'est le mieux que vous puissiez espérer de cette couche de sécurité.
WRONGssh -oStrictHostKeyChecking=pas de nom d'hôte [commande]
INCORRECTssh-keyscan -t rsa -H hostname>> ~/.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 n'écoute vos transferts de données via une attaque d'homme au milieu - 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 maintenant vous savez comment obtenir ces informations pour les comparer afin de pouvoir faire confiance à la connexion. N'oubliez pas que plus de comparaisons entre différents ordinateurs et réseaux augmenteront généralement votre capacité à faire confiance à la connexion.