Posso aggiungere automaticamente un nuovo host a known_hosts?


249

Ecco la mia situazione: sto configurando un cablaggio di prova che, da un client centrale, avvierà un numero di istanze di macchina virtuale e quindi eseguirà i comandi su di esse tramite ssh. Le macchine virtuali avranno nomi host e indirizzi IP precedentemente inutilizzati, quindi non saranno nel ~/.ssh/known_hostsfile sul client centrale.

Il problema che sto riscontrando è che il primo sshcomando eseguito su una nuova istanza virtuale presenta sempre un prompt interattivo:

The authenticity of host '[hostname] ([IP address])' can't be established.
RSA key fingerprint is [key fingerprint].
Are you sure you want to continue connecting (yes/no)?

C'è un modo in cui posso ignorarlo e far conoscere il nuovo host al computer client, magari usando una chiave pubblica già inserita nell'immagine del computer virtuale? Vorrei davvero evitare di usare Expect o qualsiasi altra cosa per rispondere al prompt interattivo, se posso.


5
Per un ambiente di test autonomo e fisicamente sicuro, l'accettazione automatica delle chiavi può funzionare correttamente. Ma accettare automaticamente le chiavi pubbliche in un ambiente di produzione o attraverso una rete non attendibile (come Internet) ignora completamente qualsiasi protezione contro gli attacchi man-in-the-middle che SSH altrimenti si permetterebbe. L' unico modo valido per assicurarsi che tu sia al sicuro dagli attacchi MITM è verificare la chiave pubblica dell'host attraverso un canale attendibile fuori banda. Non esiste un modo sicuro per automatizzarlo senza creare un'infrastruttura di firma delle chiavi moderatamente complicata.
Eil,

Risposte:


142

Impostare l' StrictHostKeyCheckingopzione su no, nel file di configurazione o tramite -o:

ssh -o StrictHostKeyChecking=no username@hostname.com


62
Questo ti lascia aperto all'uomo in mezzo agli attacchi, probabilmente non è una buona idea.
JasperWallace,

9
@JasperWallace, sebbene si tratti in genere di un buon consiglio, il caso d'uso specifico (distribuzione di VM di prova e invio di comandi) dovrebbe essere abbastanza sicuro.
Massimo,

8
Questo dà un Warning: Permanently added 'hostname,1.2.3.4' (RSA) to the list of known hosts.Per evitare l'avvertimento e per evitare che la voce venga aggiunta a qualsiasi file known_hosts, faccio:ssh -o StrictHostKeyChecking=no -o LogLevel=ERROR -o UserKnownHostsFile=/dev/null username@hostname.com
Peter V. Mørch,

11
Il downvoting in quanto ciò non risponde alla domanda e si apre a gravi vulnerabilità della sicurezza.
marcv81,

12
@Mnebuerquo: Se fossi preoccupato per la sicurezza, non avresti assolutamente niente a che fare con questa domanda. Avresti di fronte a te la chiave host corretta, raccolta dalla console del sistema a cui volevi connetterti e la verificheresti manualmente al primo collegamento. Certamente non faresti nulla "automaticamente".
Ignacio Vazquez-Abrams,

230

IMO, il modo migliore per farlo è il seguente:

ssh-keygen -R [hostname]
ssh-keygen -R [ip_address]
ssh-keygen -R [hostname],[ip_address]
ssh-keyscan -H [hostname],[ip_address] >> ~/.ssh/known_hosts
ssh-keyscan -H [ip_address] >> ~/.ssh/known_hosts
ssh-keyscan -H [hostname] >> ~/.ssh/known_hosts

Ciò assicurerà che non ci siano voci duplicate, che tu sia coperto sia per il nome host che per l'indirizzo IP, e avrà anche l'output dell'output, una misura di sicurezza aggiuntiva.


4
Perché hai bisogno di tutti e 3 gli ssh-keyscan? Non riesci a cavartela solo con la prima poiché funziona sia con il nome host che con l'ip?
Robert,

6
Puoi essere sicuro che la macchina che risponde alla richiesta ssh-keyscan sia davvero quella con cui vuoi parlare? Altrimenti ti sei aperto a un uomo in mezzo all'attacco.
JasperWallace,

2
@JasperWallace Sì, per questo è necessario almeno l'impronta digitale o ancora meglio la chiave pubblica, nel qual caso è possibile aggiungerla direttamente a known_hosts, trasformando questa domanda in discussione. Se hai solo l'impronta digitale, dovrai scrivere un passaggio aggiuntivo che verifica la chiave pubblica scaricata con l'impronta digitale ...

1
Le chiamate a ssh-keyscannon sono riuscite per me perché il mio host di destinazione non supporta il tipo di chiave versione 1 predefinito. L'aggiunta -t rsa,dsaal comando ha risolto questo problema.
phasetwenty

5
Questa è probabilmente una cattiva idea. Ti stai aprendo ad un attacco man-in-the-middle aggiornando queste chiavi. Per evitare voci duplicate, controlla invece lo stato di ritorno di ssh-keygen -F [address]. medium.com/@wblankenship/…
retrohacker

93

Per i più pigri:

ssh-keyscan -H <host> >> ~/.ssh/known_hosts

-H esegue l'hashing del nome host / dell'indirizzo IP


2
"ssh-keyscan -H <host> >> ~ / .ssh / known_hosts" produce una voce più simile a quella che ssh fa con l'interazione dell'utente. (L'H ha il nome dell'host remoto.)
Sarah Messer,

3
Vulnerabile agli attacchi MITM. Non stai controllando l'impronta digitale chiave.
Mnebuerquo,

8
@Mnebuerquo Tu dici cosa fare ma non come, il che sarebbe utile.
Ray

4
@jameshfisher Sì, è vulnerabile agli attacchi MITM, ma hai mai confrontato l'impronta digitale RSA, che ti è stata mostrata con quella reale del server, quando lo facevi manualmente? No? Quindi questa risposta è il modo di farlo per te. Se sì, non dovresti usare questa risposta e farlo manualmente o implementare altre misure di sicurezza ...
fivef

2
@Mnebuerquo Sarei davvero felice se ci facessi sapere anche un modo migliore per gestirlo, quando dobbiamo clonare un repository utilizzando script batch non frequentati e vogliamo ignorare questo prompt. Per favore, fai luce su una soluzione reale se pensi che questa non sia quella giusta!
Waqas Shah,

42

Come accennato, l'uso della scansione dei tasti sarebbe il modo giusto e discreto per farlo.

ssh-keyscan -t rsa,dsa HOST 2>&1 | sort -u - ~/.ssh/known_hosts > ~/.ssh/tmp_hosts
mv ~/.ssh/tmp_hosts ~/.ssh/known_hosts

Quanto sopra farà il trucco per aggiungere un host, SOLO se non è stato ancora aggiunto. Inoltre non è sicuro per la concorrenza; non è necessario eseguire lo snippet sulla stessa macchina di origine più di una volta contemporaneamente, poiché il file tmp_hosts può essere bloccato, portando alla fine al file known_hosts che diventa gonfio ...


Esiste un modo per verificare se la chiave è in known_hosts prima ssh-keyscan ? Il motivo è che richiede un po 'di tempo e una connessione di rete aggiuntiva.
utapyngo,

1
La versione del poster originale di questo file aveva cat ~/.ssh/tmp_hosts > ~/.ssh/known_hosts, ma una successiva modifica lo ha cambiato in >>. L'uso >>è un errore. Sconfigge lo scopo dell'unicità nella prima riga e provoca il dump di nuove voci known_hostsogni volta che viene eseguito. (Ho appena pubblicato una modifica per cambiarla.)
paulmelnikow il

1
Questo è soggetto agli stessi attacchi MITM degli altri.
Mnebuerquo,

@utapyngo ssh-keygen -F ti darà l'impronta digitale corrente. Se torna vuoto con il codice di ritorno 1, non lo hai. Se stampa qualcosa e il codice di ritorno è 0, allora è già presente.
Rich L

1
Se ti interessa molto di MITM, distribuisci i record DNSSEC e SSHFP o usa altri mezzi sicuri per distribuire le chiavi e questa soluzione di kludge sarà irrilevante.
Zart,

19

È possibile utilizzare il ssh-keyscancomando per afferrare la chiave pubblica e aggiungerla al known_hostsfile.


3
Assicurati di controllare l'impronta digitale per assicurarti che sia la chiave corretta. Altrimenti ti apri agli attacchi MITM.
Mnebuerquo,

3
@Mnebuerquo Il punto giusto nel contesto generale, ma perché qualcuno dovrebbe provare a raccogliere le chiavi a livello di codice se già sapesse qual era la chiave corretta?
Brian Cline,

Questo non è il modo di farlo. MITM.
jameshfisher,

8

Ecco come puoi incorporare ssh-keyscan nel tuo gioco:

---
# ansible playbook that adds ssh fingerprints to known_hosts
- hosts: all
  connection: local
  gather_facts: no
  tasks:
  - command: /usr/bin/ssh-keyscan -T 10 {{ ansible_host }}
    register: keyscan
  - lineinfile: name=~/.ssh/known_hosts create=yes line={{ item }}
    with_items: '{{ keyscan.stdout_lines }}'

1
Stai caricando un file known_hosts valido noto o stai eseguendo ssh-keyscan e scaricando l'output in known_hosts senza verificare le impronte digitali?
Mnebuerquo,

1
Questo è semplicemente il dump dell'output di un keyscan, sì. Quindi, in effetti, è lo stesso di StrictHostKeyChecking = no, solo con l'aggiornamento di known_hosts silenzioso senza armeggiare con le opzioni ssh. Anche questa soluzione non funziona bene a causa del fatto che ssh-keyscan può restituire più righe, il che fa sì che questa attività venga sempre contrassegnata come 'cambiata'
Zart

Questo non è il modo di farlo. MITM.
jameshfisher,

3
@jameshfisher Sarei davvero felice se ci facessi sapere anche un modo migliore per gestirlo, quando dobbiamo clonare un repository utilizzando script batch non frequentati e vogliamo ignorare questo prompt. Per favore, fai luce su una soluzione reale se pensi che questa non sia quella giusta! Fateci sapere "come" farlo, se pensate che questo non sia il modo giusto di farlo!
Waqas Shah,

È un metodo perfettamente valido per aggiungere valori a known_hosts, ma sì è sensibile al MITM. Tuttavia, per uso interno va bene.
Cameron Lowell Palmer,

7

questa sarebbe una soluzione completa, accettando la chiave host solo per la prima volta

#!/usr/bin/env ansible-playbook
---
- name: accept ssh fingerprint automatically for the first time
  hosts: all
  connection: local
  gather_facts: False

  tasks:
    - name: "check if known_hosts contains server's fingerprint"
      command: ssh-keygen -F {{ inventory_hostname }}
      register: keygen
      failed_when: keygen.stderr != ''
      changed_when: False

    - name: fetch remote ssh key
      command: ssh-keyscan -T5 {{ inventory_hostname }}
      register: keyscan
      failed_when: keyscan.rc != 0 or keyscan.stdout == ''
      changed_when: False
      when: keygen.rc == 1

    - name: add ssh-key to local known_hosts
      lineinfile:
        name: ~/.ssh/known_hosts
        create: yes
        line: "{{ item }}"
      when: keygen.rc == 1
      with_items: '{{ keyscan.stdout_lines|default([]) }}'

1
Questo non è il modo di farlo. MITM.
jameshfisher,

6

Ho avuto un problema simile e ho scoperto che alcune delle risposte fornite mi hanno permesso solo di raggiungere una soluzione automatizzata. Quanto segue è quello che ho finito per usare, spero che mi aiuti:

ssh -o "StrictHostKeyChecking no" -o PasswordAuthentication=no 10.x.x.x

Aggiunge la chiave known_hostse non richiede la password.


2
Vulnerabile agli attacchi MITM. Non stai controllando l'impronta digitale.
Mnebuerquo,

6
Nessuno controlla l'impronta digitale.
Brendan Byrd,

Questo non è il modo di farlo. MITM.
jameshfisher,

5

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.


Penso che questa sia la migliore soluzione a questo problema. Tuttavia, fai molta attenzione mentre usi Nmap su qualcosa come Amazon EC2, ho ricevuto un avviso sulla scansione delle porte che Nmap fa! Compila il loro modulo prima di eseguire il portscanning!
Waqas Shah,

...bene sì. Non so perché dovresti eseguire la scansione della porta da EC2. Se hai effettuato l'accesso al tuo account, puoi semplicemente ottenere le chiavi dalle macchine reali. Questo è più per macchine su cui non hai il controllo. Suppongo che avresti un computer locale non soggetto alle restrizioni di scansione delle porte AWS da usare. Ma, se ti trovi in ​​quella situazione limite in cui devi eseguire nmap con AWS, suppongo che questo avviso sia utile.
BradChesney79,

L'uso di nmap per leggere la chiave host SSH dalla propria stazione di lavoro e quindi fidarsi di quel valore non è diverso dalla connessione via SSH con StructHostKeyChecking disattivato. È altrettanto vulnerabile a un attacco man-in-the-middle.
Micah R Ledbetter

... @ MicahRLedbetter ed è per questo che ho suggerito che "più confronti da diversi computer e reti di solito aumenteranno la tua capacità di fidarti della connessione". Ma questo è il mio punto. Se controlli l'host di destinazione solo da una serie di condizioni ambientali, come faresti a conoscere eventuali discrepanze? Hai qualche suggerimento migliore?
BradChesney79,

1
Questo è teatro della sicurezza. Fare qualcosa di complicato per creare l'apparenza di una maggiore sicurezza. Non importa quanti metodi diversi usi per chiedere la chiave all'host. Come chiedere alla stessa persona più volte se puoi fidarti di loro (magari chiami, e-mail, sms e posta ordinaria). Diranno sempre di sì, ma se chiedi alla persona sbagliata, non importa.
vastlysuperiorman,

5

Faccio uno script da una riga, un po 'lungo ma utile per rendere questo compito per host con IP multipli, usando digebash

(host=github.com; ssh-keyscan -H $host; for ip in $(dig @8.8.8.8 github.com +short); do ssh-keyscan -H $host,$ip; ssh-keyscan -H $ip; done) 2> /dev/null >> .ssh/known_hosts

5

Quanto segue evita voci duplicate in ~ / .ssh / known_hosts:

if ! grep "$(ssh-keyscan github.com 2>/dev/null)" ~/.ssh/known_hosts > /dev/null; then
    ssh-keyscan github.com >> ~/.ssh/known_hosts
fi

1
Questo non è il modo di farlo. MITM.
jameshfisher,

Questa risposta mi piace di più. Per lo scripting della configurazione iniziale di un VPS casuale senza importanza per nessuno tranne me, il rischio MITM è decisamente ridotto. Cavillo infinitesimale ... la prima linea deve esseremkdir -p ~/.ssh/known_hosts;
Martin Bramwell

5

Come stai costruendo queste macchine? puoi eseguire uno script di aggiornamento DNS? puoi entrare in un dominio IPA?

FreeIPA lo fa automaticamente, ma essenzialmente tutto ciò di cui hai bisogno sono i record dns SSHFP e DNSSEC nella tua zona (freeipa fornisce come opzioni configurabili (dnssec disabilitato di default)).

È possibile ottenere i record SSHFP esistenti dal proprio host eseguendo.

ssh-keygen -r jersey.jacobdevans.com

jersey.jacobdevans.com IN SSHFP 1 1 4d8589de6b1a48e148d8fc9fbb967f1b29f53ebc jersey.jacobdevans.com IN SSHFP 1 2 6503272a11ba6d7fec2518c02dfed88f3d455ac7786ee5dbd72df63307209d55 jersey.jacobdevans.com IN SSHFP 3 1 5a7a1e8ab8f25b86b63c377b303659289b895736> jersey.jacobdevans.com IN SSHFP 3 2 1f50f790117dfedd329dbcf622a7d47551e12ff5913902c66a7da28e47de4f4b

poi una volta pubblicato, aggiungeresti VerifyHostKeyDNS yesa ssh_config o ~ / .ssh / config

Se / Quando google decide di capovolgere su DNSSEC, è possibile inviare ssh senza un prompt della chiave host.

ssh jersey.jacobdevans.com

MA il mio dominio non è ancora firmato, quindi per ora vedresti ...

debug1: chiave host del server: ecdsa-sha2-nistp256 SHA256: H1D3kBF9 / t0ynbz2IqfUdVHhL / WROQLGan2ijkfeT0s

debug1: trovati 4 impronte digitali non sicure in DNS

debug1: corrispondenza dell'impronta digitale della chiave host

trovato in DNS L'autenticità dell'host 'jersey.jacobdevans.com (2605: 6400: 10: 434 :: 10)' non può essere stabilita. L'impronta digitale della chiave ECDSA è SHA256: H1D3kBF9 / t0ynbz2IqfUdVHhL / WROQLGan2ijkfeT0s. Impronta digitale della chiave host corrispondente trovata nel DNS. Sei sicuro di voler continuare a connetterti (sì / no)? no


4

Per farlo correttamente, quello che vuoi veramente fare è raccogliere le chiavi pubbliche dell'host delle macchine virtuali mentre le crei e le rilascia in un file in known_hostsformato. Puoi quindi utilizzare il -o GlobalKnownHostsFile=..., indicando quel file, per assicurarti di connetterti all'host a cui ritieni di dover connetterti. Il modo in cui lo fai dipende da come stai configurando le macchine virtuali, tuttavia, ma leggerlo dal filesystem virtuale, se possibile, o persino ottenere l'host per stampare il contenuto /etc/ssh/ssh_host_rsa_key.pubdurante la configurazione può fare il trucco.

Detto questo, potrebbe non valere la pena, a seconda del tipo di ambiente in cui lavori e di chi sono i tuoi avversari previsti. Fare un semplice "store on first connect" (tramite una scansione o semplicemente durante la prima connessione "reale") come descritto in molte altre risposte sopra può essere considerevolmente più semplice e comunque fornire un po 'di sicurezza. Tuttavia, se lo fai, ti consiglio vivamente di cambiare il file hosts noto dall'utente ( -o UserKnownHostsFile=...) in un file specifico per questa particolare installazione di test; questo eviterà di inquinare il file degli host conosciuti personali con le informazioni di test e semplificherà la pulizia delle chiavi pubbliche ormai inutili quando si eliminano le macchine virtuali.


4

Questo intero

  • ssh-key-scan
  • ssh-copy-id
  • Avviso chiave ECSDA

gli affari mi davano fastidio, così ho optato per

Una sceneggiatura per dominarli tutti

Questa è una variante dello script su https://askubuntu.com/a/949731/129227 con la risposta di Amadu Bah https://serverfault.com/a/858957/162693 in un ciclo.

chiamata di esempio

./sshcheck somedomain site1 site2 site3

Lo script passerà in rassegna i siti dei nomi e modificherà il file .ssh / config e .ssh / known_hosts e eseguirà ssh-copy-id su richiesta - per l'ultima funzionalità, basta che le chiamate al test ssh falliscano, ad esempio premendo invio 3 volte su la richiesta della password.

script sshcheck

#!/bin/bash
# WF 2017-08-25
# check ssh access to bitplan servers

#ansi colors
#http://www.csc.uvic.ca/~sae/seng265/fall04/tips/s265s047-tips/bash-using-colors.html
blue='\033[0;34m'  
red='\033[0;31m'  
green='\033[0;32m' # '\e[1;32m' is too bright for white bg.
endColor='\033[0m'

#
# a colored message 
#   params:
#     1: l_color - the color of the message
#     2: l_msg - the message to display
#
color_msg() {
  local l_color="$1"
  local l_msg="$2"
  echo -e "${l_color}$l_msg${endColor}"
}

#
# error
#
#   show an error message and exit
#
#   params:
#     1: l_msg - the message to display
error() {
  local l_msg="$1"
  # use ansi red for error
  color_msg $red "Error: $l_msg" 1>&2
  exit 1
}

#
# show the usage
#
usage() {
  echo "usage: $0 domain sites"
  exit 1 
}

#
# check known_hosts entry for server
#
checkknown() {
  local l_server="$1"
  #echo $l_server
  local l_sid="$(ssh-keyscan $l_server 2>/dev/null)" 
  #echo $l_sid
  if (! grep "$l_sid" $sknown) > /dev/null 
  then
    color_msg $blue "adding $l_server to $sknown"
    ssh-keyscan $l_server >> $sknown 2>&1
  fi
}

#
# check the given server
#
checkserver() {
  local l_server="$1"
  grep $l_server $sconfig > /dev/null
  if [ $? -eq 1 ]
  then
    color_msg $blue "adding $l_server to $sconfig"
    today=$(date "+%Y-%m-%d")
    echo "# added $today by $0"  >> $sconfig
    echo "Host $l_server" >> $sconfig
    echo "   StrictHostKeyChecking no" >> $sconfig
    echo "   userKnownHostsFile=/dev/null" >> $sconfig
    echo "" >> $sconfig
    checkknown $l_server
  else
    color_msg $green "$l_server found in $sconfig"
  fi
  ssh -q $l_server id > /dev/null
  if [ $? -eq 0 ]
  then
    color_msg $green "$l_server accessible via ssh"
  else
    color_msg $red "ssh to $l_server failed" 
    color_msg $blue "shall I ssh-copy-id credentials to $l_server?"
    read answer
    case $answer in
      y|yes) ssh-copy-id $l_server
    esac
  fi
}

#
# check all servers
#
checkservers() {
me=$(hostname -f)
for server in $(echo $* | sort)
do
  os=`uname`
  case $os in
   # Mac OS X
   Darwin*)
     pingoption=" -t1";;
    *) ;;
  esac

  pingresult=$(ping $pingoption -i0.2 -c1 $server)
  echo $pingresult | grep 100 > /dev/null
  if [ $? -eq 1 ]
  then 
    checkserver $server
    checkserver $server.$domain
  else
    color_msg $red "ping to $server failed"
  fi
done
}

#
# check configuration
#
checkconfig() {
#https://askubuntu.com/questions/87449/how-to-disable-strict-host-key-checking-in-ssh
  if [ -f $sconfig ]
  then
    color_msg $green "$sconfig exists"
    ls -l $sconfig
  fi
}

sconfig=~/.ssh/config
sknown=~/.ssh/known_hosts

case  $# in
  0) usage ;;
  1) usage ;;
  *) 
    domain=$1 
    shift 
    color_msg $blue "checking ssh configuration for domain $domain sites $*"
    checkconfig
    checkservers $* 
    #for server in $(echo $* | sort)
    ##do
    #  checkknown $server 
    #done
    ;;
esac

2

Ecco come fare una raccolta di host

definire una raccolta di host

ssh_hosts:
  - server1.domain.com
  - server2.domain.com
  - server3.domain.com
  - server4.domain.com
  - server5.domain.com
  - server6.domain.com
  - server7.domain.com
  - server8.domain.com
  - server9.domain.com

Quindi definire due attività per aggiungere le chiavi agli host noti:

- command: "ssh-keyscan {{item}}"
   register: known_host_keys
   with_items: "{{ssh_hosts}}"
   tags:
     - "ssh"

 - name: Add ssh keys to know hosts
   known_hosts:
     name: "{{item.item}}"
     key: "{{item.stdout}}"
     path: ~/.ssh/known_hosts
   with_items: "{{known_host_keys.results}}"

0

La cosa migliore sarebbe controllare l'impronta digitale di ogni nuovo server / host. Questo è l'unico modo per autenticare il server. Senza di essa, la tua connessione SSH può essere soggetta ad un attacco man-in-the-middle .

Se sei davvero sicuro di voler ignorare il controllo dell'impronta digitale, allora la seconda opzione migliore e meno sicura è usare StrictHostKeyChecking=accept-new, che è stata introdotta in OpenSSH versione 7.6 (2017-10-03) :

Il primo "accetta-nuovo" accetterà automaticamente le chiavi finora invisibili ma rifiuterà le connessioni per hostkey modificate o non valide.

Non utilizzare il vecchio valore StrictHostKeyChecking=noche non controlla affatto l'autenticità del server. (Anche se il significato di questa =noimpostazione verrà capovolto in seguito in alcune versioni .)

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.