Un mio amico è riuscito a esporre sia il file id_rsa che id_rsa.pub dal suo server tramite apache. Gli ho detto che si trattava di un serio problema di sicurezza, ma l'ha spazzato via come se non fosse un grosso problema. Dato che non possiedo abbastanza conoscenze di sicurezza per spiegargli perché questo è cattivo, qualcuno può aiutarmi qui? O forse il mio amico ha ragione e non è così male come immagino che sia?
Suppongo che questi file siano per "la sua chiave SSH" come client.
Rivelare la chiave pubblica ( id_rsa.pub ) non ha alcuna conseguenza: quando la chiamiamo chiave pubblica intendiamo. La chiave privata ( id_rsa ) è ovviamente il problema.
Il modo in cui utilizzi, come client, la tua chiave privata, è di inserire la chiave pubblica corrispondente nel server, nella .ssh/authorized_keys dell'account di destinazione. Quando la chiave pubblica è in questo file, chiunque conosca la chiave privata può accedere al server con quel nome. Ecco come funzionano le chiavi pubbliche / private sul lato client in SSH.
Quindi ci sono fondamentalmente tre possibili motivi razionali che consentirebbero al tuo amico di ignorare la divulgazione del suo file id_rsa :
Forse non ha mai spinto la chiave pubblica da nessuna parte. Quando accede a un server, lo fa digitando la sua password dell'account per quel server, sempre. Se la sua coppia di chiavi non è mai usata , rivelare la chiave privata è innocua. Ma allora, perché dovrebbe avere una simile coppia di chiavi?
Probabilmente, tutti i server a cui si connette, con autenticazione a chiave privata, si trovano su una rete privata, con solo utenti non ostili e un strong isolamento dal mondo esterno.
È concepibile che la chiave privata sia protetta da una password (o "passphrase" nella terminologia SSH), il che significa che è realmente crittografata con una chiave derivata dalla password; e il tuo amico ha grande fiducia nella forza della sua password.
Nota che anche se la chiave privata non è protetta (o protetta con una password indovinabile) e concede l'accesso ad alcuni server raggiungibili dagli aggressori, allora ciò che gli aggressori possono fare è accedere a questi server nel nome del tuo amico (che è già un grosso problema). Questo NON garantisce agli attaccanti il potere di fare un attacco Man-in-the-Middle ( MitM è una doppia rappresentazione, quindi un utente malintenzionato MitM deve conoscere le chiavi private sia sul client che sul server); non possono né decifrare le sessioni passate o future da cui origliare o alterare i dati delle sessioni in corso (in particolare, le chiavi asimmetriche in SSH vengono utilizzate per l'autenticazione, ma lo scambio di chiavi utilizza Diffie-Hellman ).
- Autenticazione / controllo di accesso
People who possess his credentials might be able to login into systems impersonating him.
- Non ripudio
Others will be able to sign messages as him, and he will not be able to deny sending them.
- Riservatezza
All his private communications can be decrypted and leaked.
- Integrità
Previous documents can be already and re-signed / re-hashed being no longer integer as in the last version prior to the incident.
Per farla breve - deve farlo revocare al più presto e ottenere uno nuovo.
Le chiavi private SSH sono solitamente (per impostazione predefinita) crittografate con un potente codice simmetrico. In alcune circostanze (non l'uso della produzione, ovviamente) potrebbe essere fattibile disporre di tali chiavi in una posizione condivisa accessibile per facilitare le operazioni. Questo riduce a malapena la forza della chiave alla forza della password con cui è crittografata, il che può essere tollerabile, a seconda del modello di utilizzo delle chiavi e dei server citati in precedenza.
Dovevo solo fare l'avvocato del diavolo qui.;)
Leggi altre domande sui tag ssh certificates