Alcune aziende utilizzano software di monitoraggio come nagios o icinga. Per eseguire controlli sui server, spesso hanno bisogno di login SSH senza password.
I server controllati inseriscono la chiave pubblica del server nagios in un file /root/.ssh/authorized_keys
Ora, se vedo un server nagios in una rete aziendale, non posso semplicemente recuperare la chiave pubblica di questo server e sostituire il mio con esso e accedere ai server senza password?
I valori in .ssh/authorized_keys sono chiavi pubbliche - questi sono oggetti matematici, ognuno dei quali è collegato con un altro oggetto matematico chiamato chiave privata . Quando il server nagios si collega a uno dei server monitorati, utilizza la sua chiave privata : il server nagios dimostra la sua conoscenza della chiave privata attraverso un'operazione matematica (a firma digitale ), che il server di destinazione verifica utilizzando la corrispondente chiave pubblica.
La magia della costruzione è che la chiave pubblica può essere resa pubblica: sebbene la chiave privata e pubblica condividano una struttura comune, quella struttura è "nascosta" e non può essere ricostruita dalla sola chiave pubblica (qui "non può" significa "avresti bisogno di un computer più grande di tutto lo stato del Wyoming e programmato da Chuck Norris").
Quindi, per accedere ai server di destinazione, non è necessario prendere la chiave pubblica , ma la chiave privata - e quella non lascia mai le viscere di il server nagios.
(D'altra parte, se riesci a ottenere un accesso in lettura al server nagios, ad esempio puoi dare un'occhiata a un nastro di backup, quindi puoi ottenere la chiave privata e accedere a tutti i server. Nirvāṇa di Attacker < em> Quel può essere un serio problema di sicurezza: proteggi i tuoi backup!)
Non so se ti capisco bene, ma l'autenticazione con certificato SSH funziona in un modo che devi configurare il tuo SSHD con certificati attendibili così, per poter aggiungere il tuo certificato come affidabile dal server, devi essere in grado di accedervi in un primo posto.
Diciamo in qualche modo di accedere al server in questione (sia fisicamente che da remoto). Potrebbe esserci un file nagios.pub in /root/.ssh/authorized_keys/ e la tua domanda è, cosa succede se sostituisci il file nagios.pub con attacker.pub (solo ovviamente rinominato)? La risposta è che saresti in grado di accedere a quel server usando la chiave privata dell'attaccante (negheresti anche l'accesso legittimo dell'utente al sistema).
La domanda quindi è, cosa hai guadagnato. Beh, niente in realtà come hai già avuto accesso al sistema in primo luogo. Forse hai ottenuto l'accesso remoto, ma ci sono un milione di modi per farlo una volta che hai accesso fisico. Forse hai acquisito un accesso persistente, ma di nuovo ci sono molti altri metodi per farlo meno tracciabili (ad es. Rootkit).
È sicuro perché per l'accesso è necessario sia le chiavi pubbliche che quelle private e il server ha solo bisogno della chiave pubblica per verificare che si disponga della chiave privata. Quindi, se il server è configurato correttamente, è possibile ottenere solo la chiave pubblica, ma non si avrà ancora la chiave privata. E dal design non è possibile calcolare la chiave privata solo dalla chiave pubblica.
Leggi altre domande sui tag cryptography encryption passwords ssh attacks