Il messaggio "autenticità dell'host non può essere stabilito" in SSH riflette un rischio per la sicurezza?

Ogni volta che mi collego a un nuovo server SSH dal mio computer ottengo questo messaggio:

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

Perché SSH me lo chiede?

Ho qualche rischio di connessione a un server SSH casuale?

O è solo per assicurarsi che il server a cui ci si connette non sia stato violato?

ssh internet-security

— Charles Duffy
fonte

Stai utilizzando una password o una chiave per accedere?

— kasperd

Ce ne sono diversi meglio modi per distribuire le chiavi host rispetto al trust al primo utilizzo; questo è un flusso di lavoro relativamente insicuro. Le chiavi host possono essere distribuite tramite LDAP; tramite voci DNS firmate; può essere firmato con le autorità di certificazione SSH; ecc. In altre parole, quello che stai vedendo qui indica che il tuo sito è configurato "il modo pigro" (che quasi tutti sono!), che è meno sicuro di andare a ulteriori lunghezze per fare le cose bene.

— Charles Duffy

Risposte:

Ti sta chiedendo perché non è mai collegato a questo host in precedenza.

Se ti trovi in un ambiente sicuro, allora conoscerai l'impronta digitale dell'host remoto e la confronterai sulla prima connessione, se l'impronta digitale corrisponde a ciò che sai dovrebbe essere, quindi ottimo. Se ti trovi in un ambiente meno sicuro, puoi semplicemente accettarlo alla prima connessione.

Una volta che hai detto " Sì, mi fido della chiave dell'host e voglio che sia associata a quel nome host / IP ", il client SSH ricorderà questo per te ... Se per qualsiasi motivo (reinstallare / nuove chiavi host / nuova macchina / uomo nel mezzo) la chiave non lo fa abbinare su una connessione successiva, vedrete un avvertimento come di seguito:

$ ssh baloo
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:Su0uy/4BcRcpmyLfxO9ndlcda52F8uct6yWNp7Sa92M.
Please contact your system administrator.
Add correct host key in /home/attie/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/attie/.ssh/known_hosts:65
  remove with:
  ssh-keygen -f "/home/attie/.ssh/known_hosts" -R baloo
ECDSA host key for baloo has changed and you have requested strict checking.
Host key verification failed.

In questa situazione, se sai che l'host remoto è stato effettivamente modificato, puoi procedere ... eventualmente verificando che l'impronta digitale sia corretta.

Se non sei sicuro, o sai che l'host remoto non dovrebbe essere cambiato, allora ti indurrà a un potenziale attacco.

— Attie
fonte

Questo è il principio TOFU: Trust On First Use

— Patrick Mevzek

D'accordo, TOFU non è una grande idea, specialmente se devi essere sicuro ... La tua opinione e il tuo approccio dipenderanno (dovrebbero) dal tuo modello di thread.

— Attie

Tuttavia, per l'efficacia di questo, vedi cs.auckland.ac.nz/~pgut001/pubs/defending.pdf , pagine 45-48.

— Joker_vD

Diapositive interessanti, grazie per aver condiviso @Joker_vD

— Attie

@PatrickMevzek Il problema è che il nostro intero modello di "fiducia" del computer è fondamentalmente alla granularità di un booleano, mentre nel mondo reale un modello pratico di fiducia (come quello che usiamo intuitivamente nelle relazioni inter-umane) è più simile a un probabilità condizionale: data una richiesta di un'entità, abbiamo un certo grado di fiducia che l'entità la seguirà e limitiamo la nostra esposizione al rischio in proporzione a ciò.

— mtraceur

Quando ricevi questo messaggio SSH sta semplicemente dicendo "Non ho mai visto questo computer prima, quindi non posso essere sicuro che sia chi dice di essere. Ti fidi?" A quel punto puoi dire che ti fidi di esso e in futuro il tuo computer ricorderà e non ti chiederà più.

Idealmente per fidarsi è necessario confrontare manualmente la chiave fornita con la chiave sul server (come si farebbe con una chiave GPG controllando che la persona a cui si crede possa effettivamente generare la chiave pubblica). Anche se in realtà la gente non si preoccupa di questo (almeno per quanto ne so).

Il vero vantaggio deriva da ogni successiva connessione al server. Se SSH si lamenta del server di cui ti fidi già di non essere lo stesso server, allora c'è la possibilità che tu sia vittima di un attacco MiTM.

Soprattutto se sei su una rete in cui sei sicuro che non ci sia nessun attacco Man in the Middle in corso e questa è la prima volta che ti colleghi al computer, quindi dovresti essere sicuro di accettare la chiave. (anche se stai lavorando ad alcune missioni governative top secret allora forse chiedi all'amministratore di sistema di verificare l'impronta digitale prima di connetterti)

— KNejad
fonte