Non aggiungere hostkey a known

111

Voglio connettermi a un host tramite SSH ma non voglio che il nome host venga aggiunto al mio ~/.ssh/known_hosts.

Come posso fare ciò?

ssh hosts

— Albert
fonte

99

-o "UserKnownHostsFile /dev/null"

dovrebbe funzionare.

— Albert
fonte

3

Funziona come previsto, ma riporterà sempre: "Avvertenza:" hostname, ip "(RSA) è stato aggiunto in modo permanente all'elenco degli host noti." L'ho fatto andare via con: 2> & 1 | grep -v "^Warning: Permanently added"

— Guillaume Boudreau,

3

aggiungi -o "LogLevel ERROR" e non si lamenterà più degli avvertimenti

— John

1

Nota: una richiesta per sopprimere quel messaggio "Avvertenza: aggiunto permanentemente 'hostname, ip' (RSA) all'elenco degli host conosciuti." è stato segnalato ai manutentori bugzilla.mindrot.org/show_bug.cgi?id=2413

— Ben Creasy,

2

Il piping to grepunirà stdout e stderr; anche lo stato di uscita può cambiare. Se si utilizza bash, sarà meglio usare sostituzione di processo per sbarazzarsi del messaggio: ssh 2> >( egrep >&2 -v '^Warning: Permanently added') -o "UserKnownHostsFile /dev/null" [...]. Eviterà la conduttura e quindi i corrispondenti cambiamenti nella gestione dello stato di uscita.

— Alex O

1

@John È meglio usare uno degli altri metodi in questi commenti, altrimenti si sta introducendo un difetto di sicurezza a causa del potenziale per nascondere altri avvisi non correlati

— Jon Bentley

98

Se si desidera questo comportamento perché si lavora con server cloud (AWS EC2, Rackspace CloudServers ecc.) O si esegue costantemente il provisioning di nuove immagini in Vagrant, è possibile che si desideri aggiornare la configurazione SSH invece di aggiungere alias bash o più opzioni sul riga di comando.

Valuta di aggiungere qualcosa come:

Host *.mydomain.com 
  StrictHostKeyChecking no
  UserKnownHostsFile /dev/null
  User foo
  LogLevel QUIET

Utilizzare il più rigoroso regex per l'host possibile per essere sicuro.
L'impostazione di LogLevel su QUIET manterrà l'avviso che Guillaume menzionato dalla visualizzazione

— cclark
fonte

Dovresti davvero provare a non disabilitare completamente StrictHostKeyChecking, quindi la risposta di cclark è un ottimo compromesso per lavorare con i server cloud.

— Alex Recarey,

Questo mi è stato molto utile mentre usavo Shipit (uno strumento di distribuzione JavaScript) contro Vagrant. Non sono riuscito a ottenere facilmente i parametri che Shipit stava passando a SSH, quindi questo mi ha permesso di eludere lo strumento e dirgli quello che ho fatto e non volevo che ricordasse.

— John Munsch,

1

LogLevel è quello che stavo cercando. Ha il vantaggio di non mostrare l'avviso configurato dall'azienda durante l'esecuzione degli script! (Sto correndo ora con ERRORE loglevel)

— Anshu Prateek

In quale file lo aggiungo?

— Wim Deblauwe,

Questo è il tuo file di configurazione SSH. In Linux o macOS il file si troverebbe generalmente in una directory chiamata .ssh nella directory home e denominata config - ~ / .ssh / config

— cclark,

8

Ho voglia di aggiungere la chiave host ai tuoi known_hosts (le persone che gestiscono questi servizi sono, almeno nella mia esperienza, abbastanza intelligenti da mantenere coerenti le chiavi dell'host tra macchine che servono lo stesso nome host) e quindi attivare StrictHostKeyChecking, disattivare CheckHostIP e la registrazione con LogLevel ERROR ti offrirà la migliore esperienza senza sacrificare la sicurezza. (Ok, senza CheckHostIP devi fidarti del DNS, che è un enorme buco senza DNSSEC diffuso o qualcosa di simile; ma per il momento lo spazzeremo sotto il tappeto.)

Uso un file known_hosts di sola lettura, quindi devo fare qualcosa o ricevo infiniti avvisi di non poter aggiungere voci a known_hosts.

Quello che uso:

Host github.com *.github.com
StrictHostKeyChecking yes
CheckHostIP no
LogLevel ERROR

Vorrei che questi servizi pubblicassero le loro chiavi host SSH sui loro siti Web tramite HTTPS, quindi posso copiarle in modo esplicito senza dover prima collegarmi ed esponermi potenzialmente a un attacco MITM.

— Kyle Rose
fonte

7

Per una singola sessione SSH, utilizzare questo

ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null user@host

— Quanlong
fonte

4

Ciò non aggiunge nulla di nuovo a una risposta accettata su una domanda di 5 anni.

— Jake Gould il

5

suggerisco

LogLevel ERROR

al di sopra di

LogLevel QUIET

quindi ottieni ancora "Impossibile risolvere il nome host" e altri errori simili

— kiloforce
fonte

dovresti essere in grado di fidarti delle tue connessioni SSH, imho. Non limitarti a tacere sui tuoi rischi.

— sylvainulg,

3

Dipende davvero. Abbiamo ambienti di sviluppo che vengono demoliti ogni settimana e ricostruiti, i loro record A rimangono gli stessi ma la loro chiave host viene generata ogni volta che viene creata. Non possiamo mantenere le chiavi host perché il record A è appena definito in un database basato su un nome di ambiente e i nomi di ambiente possono essere eliminati o crearne di nuovi in qualsiasi momento, quindi la soluzione sopra descritta è davvero utile.

— Alex Berry,

2

Hai provato a disabilitare StrictHostKeyChecking? Puoi farlo con l' -oopzione o nel file di configurazione ~/.ssh/config.

— jneves
fonte

Lo sto già usando. Ma ha un effetto diverso: riduce la severità per il controllo della chiave host. Vale a dire quando l'host è sconosciuto, si connette ancora quando si disabilita tale opzione. Pertanto, salva ancora l'host. Ma penso di aver trovato la soluzione giusta (vedi la mia risposta).

— Albert,

0

Ho trovato utili le seguenti voci .ssh / config (LAN con DHCP e DNS):

 CheckHostIP no

 Host *.*
 CheckHostIP yes

Il risultato è che i nomi di macchine locali "zora" o "goron" non controlleranno gli indirizzi IP assegnati dinamicamente, ma www.mycompany.com o node42.planetlab.com continueranno a confermare i loro IP statici.

— sylvainulg
fonte

Non aggiungere hostkey a known_hosts per SSH