Quanto è male avere più dispositivi con le stesse chiavi del server SSH?

Sto lavorando su un dispositivo incorporato che esegue FreeBSD e SSH.

Come sai, a sshd piace generare casualmente un set di chiavi del server al primo avvio. Il problema è che spediremo il prodotto con un file system sd-card di sola lettura (non negoziabile).

Le mie due opzioni come le vedo sono:

• Spedisci le stesse chiavi del server sshd su tutti i dispositivi
• Montare un file system di memoria e generare le chiavi del server ad ogni avvio (lento ...)

È un grave problema di sicurezza spedire le stesse chiavi del server su tutti i dispositivi? Questi articoli non saranno direttamente su Internet. Occasionalmente ci saranno più dispositivi di proprietà della stessa persona e sulla stessa rete.

Il più delle volte il dispositivo non sarà connesso a Internet.

L'accesso con SSH non fa parte del normale funzionamento. È principalmente per comodità di programmatori e tecnici. I clienti non accederanno al dispositivo con SSH.

Quali sono le conseguenze dell'utilizzo delle stesse chiavi del server su più dispositivi hardware?

PS qualcuno potrebbe creare un tag per l'internet delle cose?

EDIT : sto parlando di installare le stesse chiavi private host su tutti i server (dispositivi). Per quanto riguarda le chiavi pubbliche / private degli utenti, al momento non è in programma l'utilizzo di un accesso basato su chiavi: sarebbe un accesso con password. Ancora una volta, la stessa password su tutti i server (dispositivi).

So che questa è probabilmente una cattiva idea. Mi piacerebbe sapere perché è una cattiva idea, quindi posso capire i compromessi.

Invece di archiviare dati specifici dell'host come chiavi host ssh sulla scheda SD o altri supporti di sola lettura, è possibile archiviarli in NVRAM, che è ciò che serve per un sistema incorporato. Dovrai eseguire alcuni script personalizzati per archiviare e recuperare le chiavi all'avvio, ma gli script saranno esattamente gli stessi per ogni dispositivo.

L'impatto della spedizione della stessa coppia di chiavi con tutti i tuoi dispositivi è direttamente correlato alla sicurezza dei client che si collegano ad essi, in quanto significa che non esiste alcun modo (da un client SSH) di identificare in modo univoco il dispositivo a cui potrebbe connettersi. Se la tua coppia di chiavi dovesse trapelare, potrebbe essere utilizzata per gli attacchi MITM.

D'altra parte, rigenerando le chiavi ad ogni avvio, si attiverà anche un avviso sui client.

Per riferimento, da man ssh(1):

sshmantiene e controlla automaticamente un database contenente l'identificazione per tutti gli host con cui è mai stato utilizzato. Le chiavi host sono archiviate nella ~/.ssh/known_hostshome directory dell'utente. Inoltre, il file /etc/ssh/ssh_known_hostsviene automaticamente verificato per host noti. Eventuali nuovi host vengono aggiunti automaticamente al file dell'utente. Se l'identificazione di un host cambia, sshavvisa e disabilita l'autenticazione con password per impedire lo spoofing del server o attacchi man-in-the-middle, che potrebbero altrimenti essere utilizzati per aggirare la crittografia. L' StrictHostKeyCheckingopzione può essere utilizzata per controllare gli accessi ai computer la cui chiave host non è nota o è cambiata.

Sembra che nella prima opzione, le chiavi SSH sarebbero disponibili sulla scheda SD. Quindi qualsiasi utente potrebbe prendere la carta e leggerla. Quindi in pratica le tue chiavi private sono diventate (principalmente) pubbliche.

Ciò consentirà attacchi man-in-the-middle, come il seguente:

1. Un utente configura un server SSH con le chiavi private ottenute dal tuo dispositivo e fornisce tale indirizzo IP al tuo tecnico.
2. Il tecnico immette la password di root tramite la connessione SSH.
3. L'utente ora conosce la password di root valida per tutti i tuoi dispositivi.

Tuttavia, non dovresti usare le password di root in primo luogo, usa invece le chiavi ssh per l'autenticazione. Quindi l'impatto delle chiavi del server condiviso è piuttosto piccolo se si accede solo da una LAN.

SSH fornisce anche segretezza diretta, quindi un utente malintenzionato deve essere in grado di configurare un server falso per beneficiare delle chiavi; fiutare passivamente il traffico non permetterà di decifrarlo.

L'ho letto con orrore! Io che ho fatto più macchine nello stesso cluster con la stessa chiave host ssh non oserei mai farlo. Non consentire in nessun caso a macchine con diversi set di amministratori di condividere chiavi host ssh. In questo modo risiede la follia e l'orrore urlante quando vieni postato per la tua mancanza di sicurezza.

Ecco, io ti dico la verità, chi compromette un dispositivo li compromette tutti. Una volta ottenuto uno, aspettatevi che le persone cattive saltino l'una dall'altra a piacimento e la sicurezza sia tornata indietro come se fosse carta sottile.

Poiché si menziona che l'accesso SSH non è utilizzato dall'utente / cliente finale, è possibile che si desideri disattivare l'accesso SSH per impostazione predefinita e abilitarlo temporaneamente solo quando il dispositivo viene messo in modalità "debug".

Puoi quindi spedire tutti i dispositivi con la stessa chiave, supponendo che tu abbia protetto la modalità "debug" in modo che non possa essere attivata da remoto da qualcuno che cerca di hackerare il dispositivo.

Oppure hai una nuova chiave generata quando il dispositivo entra in modalità "debug", quindi non devi perdere tempo di avvio generando le chiavi ogni volta che il dispositivo viene acceso.

Ecco uno scenario di attacco di esempio basato sui vincoli che hai:

Se i tuoi dispositivi lo sono, ad esempio un Raspberry Pi. Se mi alzo e strappo la scheda SD da una, posso attaccare la scheda SD nel mio computer, trovare la chiave sshd e copiarla dove voglio. Forse prendo il mio Raspberry Pi e una scheda Ethernet USB. Ora posso collegarlo tra un dispositivo di destinazione e ovunque vadano e monitorare le connessioni ssh. Quando vedo che il dispositivo di destinazione sta tentando di stabilire una connessione ssh, faccio questo:

(target) <---> (my evil sshd <--> decrypted traffic <--> ssh) <---> (real server)
                                       |
                                       V
                                    log file

Oh, che cos'è? La tua password è "Mi piacciono i gatti"? Ragazzo, questa è una email interessante che hai inviato a tua moglie. Scommetto che sarebbe ancora più interessante se leggesse questa e-mail che hai inviato alla moglie dei vicini della porta accanto.

Le possibilità sono infinite . E la destinazione non lo saprebbe mai, perché la chiave sshd è identica a quella trovata sul server reale. A seconda della sicurezza fisica delle strutture che stanno ricevendo il tuo dispositivo, questo potrebbe essere incredibilmente banale. Non farlo

Invece, fai quello che già proponi ma correggilo . Prima di scrivere la tua immagine esegui qualcosa del genere:

ssh-keygen -f some-new-server
cp some-new-server /path/to/the/mounted/image/sshd/key
cp some-new-server.pub /path/to/the/mounted/image/sshd/key.pub

E ora ogni server ha una nuova chiave. Perché davvero, davvero non vuoi distribuire copie di una chiave. Voglio dire, onestamente è al minimo così male come scattare una foto delle vostre chiavi di casa e di caricarli su Internet con il vostro indirizzo di casa.