SSH: vantaggi dell'utilizzo di hash noti_host

29

Quali sono i vantaggi dell'archiviazione di known_hosts in un modulo con hash? Da quello che ho letto, si suppone che protegga l'elenco di server a cui mi sto collegando, presumibilmente in uno scenario in cui il mio account è stato compromesso (e known_hosts file rubato)

Se il mio account fosse davvero compromesso, avere hash known_hosts sarebbe una pochissima consolazione. Un utente malintenzionato potrebbe vedere dal mio bash history a quali server mi sto connettendo. E anche dal mio .ssh/config in cui sono elencati tutti i miei server.

Ci sono dei vantaggi che mi mancano nella mia descrizione qui?

    
posta Martin Vegter 21.04.2014 - 14:06
fonte

1 risposta

30

Non penso che ti manchi molto. L'unico cambiamento è che se una macchina è compromessa, l'idea è di minimizzare la quantità di informazioni utilizzabili fornite a un utente malintenzionato. Nel file known_hosts , non sono necessarie ulteriori informazioni da includere (calcolare alcune centinaia di HMAC non è un lavoro oneroso), diversamente da ~/.ssh/config dove deve essere incluso nella riga Address se desideri connetterti tramite il tuo alias (l'hashing non funzionerebbe) e nella cronologia della riga di comando, se si sceglie di conservarne uno.

Presumibilmente potresti avere un numero molto elevato di noti_host (ad esempio, se lo sincronizzi con un altro computer quando imposti l'account), ma non usare .ssh/config e non mantenere una cronologia della riga di comando o non ti sei mai connesso alla maggior parte delle macchine la cronologia della riga di comando.

In queste situazioni, l'hashing degli indirizzi IP usati nei tuoi known_hosts potrebbe ridurre l'esposizione in caso di compromissione.

Inoltre, HashKnownHosts è un'opzione configurabile e il valore predefinito è hash (probabilmente per i motivi specificati, non aiuta molto). Guarda man ssh_config :

HashKnownHosts

Indicates that ssh(1) should hash host names and addresses when they are added to ~/.ssh/known_hosts. These hashed names may be used normally by ssh(1) and sshd(8), but they do not reveal identifying information should the file's contents be disclosed. The default is “no”. Note that existing names and addresses in known hosts files will not be converted automatically, but may be manually hashed using ssh-keygen(1). Use of this option may break facilities such as tab-completion that rely on being able to read unhashed host names from ~/.ssh/known_hosts.

Nota il formato di una riga hash known_hosts (esempio tratto da qui - la mia configurazione attuale non è hash) per una voce per 192.168.1.61 :

|1|F1E1KeoE/eEWhi10WpGv4OdiO6Y=|3988QV0VE8wmZL7suNrYQLITLCg= ssh-rsa ... 

dove la prima parte F1E1KeoE/eEWhi10WpGv4OdiO6Y= è un salt casuale - che funge da chiave per l'HMAC-SHA1 per l'hash 192.168.1.61.

Puoi verificare nella riga di comando con (BSD / Mac OS X):

#### key='echo F1E1KeoE/eEWhi10WpGv4OdiO6Y= | base64 -D | xxd -p'
#### echo -n "192.168.1.61" | openssl sha1 -mac HMAC -macopt hexkey:$key|awk '{print $2}' | xxd -r -p|base64
3988QV0VE8wmZL7suNrYQLITLCg=

o su GNU / linux con:

#### key='echo F1E1KeoE/eEWhi10WpGv4OdiO6Y= | base64 -d | xxd -p'
#### echo -n "192.168.1.61" | openssl sha1 -mac HMAC -macopt hexkey:$key|awk '{print $2}' | xxd -r -p|base64
3988QV0VE8wmZL7suNrYQLITLCg=

dove abbiamo solo decodificato il sale e usato come chiave in un HMAC sha1, e quindi ricodificare l'hash in base64. Solo specificando come un'altra risposta originariamente supponeva che l'HMAC potesse aver usato la chiave ssh privata dell'utente per calcolare il codice di autenticazione dei messaggi basato su hash, ma non è questo il caso.

    
risposta data 21.04.2014 - 19:41
fonte

Leggi altre domande sui tag