Quindi, stavo cercando un modo banale per bypassare l'interazione manuale dell'host sconosciuta di clonare un repository git come mostrato di seguito:
brad@computer:~$ git clone git@bitbucket.org: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)?
Nota l'impronta digitale della chiave RSA ...
Quindi, questa è una cosa SSH, funzionerà per git su SSH e solo cose relative a SSH in generale ...
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
Innanzitutto, installa nmap sul tuo driver giornaliero. nmap è molto utile per alcune cose, come il rilevamento di porte aperte e questo - verifica manuale delle impronte digitali SSH. Ma torniamo a quello che stiamo facendo.
Buono. O sono compromesso nei molteplici luoghi e macchine che ho controllato-- o la spiegazione più plausibile di tutto ciò che è hunky dory è ciò che sta accadendo.
Quell'impronta digitale è solo una stringa accorciata con un algoritmo unidirezionale per la nostra convenienza umana a rischio che più di una stringa si risolva nella stessa impronta digitale. Succede, si chiamano collisioni.
Indipendentemente da ciò, torniamo alla stringa originale che possiamo vedere nel contesto di seguito.
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
Quindi, in anticipo, abbiamo un modo per chiedere una forma di identificazione dall'host originale.
A questo punto siamo manualmente vulnerabili come automaticamente: le stringhe corrispondono, abbiamo i dati di base che creano l'impronta digitale e potremmo chiedere quei dati di base (prevenire le collisioni) in futuro.
Ora per usare quella stringa in un modo che impedisce di chiedere l'autenticità di un host ...
Il file known_hosts in questo caso non utilizza voci di testo in chiaro. Conoscerai le voci con hash quando le vedi, sembrano hash con caratteri casuali invece di xyz.com o 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 prima riga di commenti si presenta in modo esasperante, ma puoi sbarazzartene con un semplice reindirizzamento tramite la convenzione ">" o ">>".
Dato che ho fatto del mio meglio per ottenere dati non contaminati da utilizzare per identificare un "host" e la fiducia, aggiungerò questa identificazione al mio file known_hosts nella mia directory ~ / .ssh. Poiché ora verrà identificato come host noto, non riceverò il messaggio di cui sopra quando eri un giovane.
Grazie per essere rimasto con me, eccoti. Sto aggiungendo la chiave RSA bitbucket in modo da poter interagire con i miei repository git lì in modo non interattivo come parte di un flusso di lavoro CI, ma qualunque cosa tu faccia quello che vuoi.
#!/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
Quindi, è così che rimani vergine per oggi. Puoi fare lo stesso con github seguendo indicazioni simili nel tuo tempo libero.
Ho visto così tanti post di overflow dello stack che ti dicevano di aggiungere programmaticamente la chiave alla cieca senza alcun tipo di controllo. Più controlli la chiave da macchine diverse su reti diverse, maggiore sarà la fiducia che l'host è quello che dice di essere - e questo è il massimo che puoi sperare da questo livello di sicurezza.
SBAGLIATO
ssh -oStrictHostKeyChecking = no hostname [comando]
SBAGLIATO
ssh-keyscan -t rsa -H hostname >> ~ / .ssh / known_hosts
Non fare una delle cose sopra, per favore. Ti viene data la possibilità di aumentare le tue possibilità di evitare che qualcuno intercetti sui tuoi trasferimenti di dati tramite un uomo nel mezzo dell'attacco - cogli l'occasione. La differenza sta letteralmente verificando che la chiave RSA che hai è quella del server in buona fede e ora sai come ottenere tali informazioni per confrontarle in modo da poterti fidare della connessione. Ricorda solo che più confronti da diversi computer e reti aumenteranno la tua capacità di fidarti della connessione.