L'amministratore del server mi ha inviato una chiave privata da utilizzare. Perché?

Dovrei accedere a un server per collegare i server di gestione temporanea e live di un'azienda nel nostro ciclo di distribuzione. Un amministratore dalla loro parte ha impostato le due istanze e quindi ha creato un utente sul server per noi su SSH in as. Sono così abituato.

Nella mia mente ora ciò che accadrebbe è che invierei loro la mia chiave pubblica che potrebbe essere inserita nella cartella delle chiavi autorizzate. Invece mi hanno inviato un nome file id_rsache all'interno del file contiene -----BEGIN RSA PRIVATE KEY-----tramite e-mail. È normale?

Mi sono guardato intorno e sono riuscito a trovare tonnellate di risorse per generare e configurare le mie chiavi da zero, ma nulla a proposito di partire dalle chiavi private del server. Dovrei usarlo per generare una chiave per me o?

Chiederei direttamente all'amministratore di sistema, ma non voglio apparire un idiota e perdere tempo tra tutti noi. Devo semplicemente ignorare la chiave che mi ha inviato e chiedere loro di mettere la mia chiave pubblica nella loro cartella autorizzata?

— Toby
fonte

Non la definirei normale o sana, ma poiché hai la chiave privata (supponendo che l'abbia già aggiunta come autorizzata) puoi usarla come faresti con qualsiasi altra chiave privata. Non hai bisogno della chiave pubblica corrispondente, ma se vuoi, puoi sempre generarla: askubuntu.com/a/53555/158442

— muru

Superare -----BEGIN RSA PRIVATE KEY-----l'e-mail è la prossima cosa spaventosa dopo aver visto un utente chiamato '); DROP DATABASE;--nella tabella dei nomi utente.

— Dmitry Grigoryev il

@DmitryGrigoryev nulla di spaventoso nel vedere '); DROP DATABASE;--come un nome utente nella tabella del database - mostra che hai

— evitato

Sicuramente non puoi "usarlo come faresti con qualsiasi altra chiave privata". Questo non è privato. Ergo non può assolutamente svolgere la funzione per cui è stato creato. Dovrebbe essere gettato via e l'amministratore UNIX severamente castigato. @muru

— user207421

Chiunque abbia questa chiave privata ha accesso ai nuovi server. Presumibilmente l'amministratore ha comunque accesso senza la chiave, visto che è stato in grado di configurare il server, quindi non vi è alcuna minaccia aggiuntiva di accesso non autorizzato da parte sua. Tuttavia, poiché questa è la chiave, ora può impersonare in modo affidabile. C'è anche la possibilità che qualcuno diverso da te legga l'e-mail e quindi possano anche impersonare te.

— user253751

Risposte:

116

Nella mia mente ora ciò che accadrebbe è che invierei loro la mia chiave pubblica che potrebbe essere inserita nella cartella delle chiavi autorizzate.

Ciò che è "nella tua mente" come quello che dovrebbe accadere ora è corretto.

L'email non è un canale di comunicazione sicuro, quindi dal punto di vista della sicurezza adeguata, tu (e loro) dovresti considerare tale chiave privata compromessa.

A seconda delle tue capacità tecniche e di quanto diplomatico vuoi essere, potresti fare diverse cose. Consiglierei uno dei seguenti:

Genera la tua coppia di chiavi e allega la chiave pubblica a un'email che invii loro, dicendo:

Grazie! Dal momento che l'e-mail non è un metodo di distribuzione sicuro per le chiavi private, potresti invece inserire la mia chiave pubblica? È attaccato.
Ringraziali e chiedi loro se si oppongono all'installazione della tua coppia di chiavi, poiché la chiave privata che hanno inviato dovrebbe essere considerata compromessa dopo essere stata inviata tramite e-mail.

Genera la tua coppia di chiavi, usa la chiave che ti hanno inviato per accedere la prima volta e usa quell'accesso per modificare il authorized_keysfile per contenere la nuova chiave pubblica (e rimuovere la chiave pubblica corrispondente alla chiave privata compromessa).

In conclusione: non sembrerai un idiota. Ma l'altro amministratore potrebbe essere fatto sembrare un idiota molto facilmente. Una buona diplomazia potrebbe evitarlo.

Modifica in risposta ai commenti di MontyHarder:

Nessuno dei miei corsi di azione suggeriti implica "sistemare le cose senza dire all'altro amministratore cosa ha fatto di sbagliato"; L'ho fatto sottilmente senza gettarlo sotto il bus.

Tuttavia, aggiungerò che seguirò anche (educatamente) se gli indizi sottili non fossero stati raccolti:

Ciao, ho visto che non hai risposto al mio commento sull'e-mail come canale non sicuro. Voglio essere sicuro che questo non accadrà più:

Capisci perché sto sottolineando la gestione sicura delle chiavi private?

Migliore,

Toby

— jolly
fonte

+1 Migliore risposta. E aggiungerei: state particolarmente attenti poiché questo amministratore di sistema si è dimostrato incompetente. Meglio coprirsi la schiena quando (e non se ) rovinerà definitivamente il server.

— dr01,

Grazie. Ho usato un fraseggio delicato e ho inviato la mia chiave pubblica. Sembra tutto risolto ma deselezionerò la chiave che mi ha inviato ora.

— Toby,

Non è che l'altro amministratore "potrebbe sembrare un idiota". È che l'altro amministratore ha fatto qualcosa di idiota. Posso solo pensare a uno scenario in cui una chiave privata dovrebbe essere condivisa tra macchine, ed è lì che si accede a un pool di server con lo stesso nome (risoluzione DNS round robin ecc.) E deve presentare la stessa chiave host SSH in modo che i processi automatizzati accetteranno di essere quel nome. E in quel caso, la stessa persona sarebbe un amministratore di tutti i server e gestirà i trasferimenti senza che sia coinvolta una parte esterna.

— Monty Harder,

@zwol Nel mio lavoro, abbiamo una filosofia "senza colpa" che comprende che commetteremo degli errori, ma rende prioritario non commettere lo stesso errore due volte. Ma per non commettere lo stesso errore due volte, devi sapere che è un errore, motivo per cui non posso votare le risposte suggerendo che l'OP risolve semplicemente le cose senza dire all'altro amministratore cosa ha fatto di sbagliato. Ho scelto di chiamare l' errore "idiota" piuttosto che chiamare i nomi dell'amministratore proprio per il motivo che descrivi. (Ma non sono sicuro che la tua parentesi conclusiva esprima una distinzione significativa.)

— Monty Harder,

@LightnessRacesinOrbit, sospetto che potresti avere una comprensione incompleta del significato di "diplomazia". Hai provato a ripulirlo in un buon dizionario, come il terzo nuovo dizionario internazionale di Webster?

— Wildcard l'

Devo semplicemente ignorare la chiave che mi ha inviato e chiedere loro di mettere la mia chiave pubblica nella loro cartella autorizzata?

Sì, è esattamente quello che dovresti fare. L'intero punto con le chiavi private è che sono private , nel senso che solo tu hai la tua chiave privata. Dato che hai ricevuto quella chiave dall'amministratore, ce l'ha anche lui. Quindi può impersonarti ogni volta che vuole.

Non importa se la chiave ti è stata inviata tramite un canale sicuro: anche se hai ricevuto di persona la tua chiave privata, ciò non cambierebbe nulla. Anche se sono d'accordo con i commenti sul fatto che l'invio tramite e-mail delle chiavi di crittografia sensibili è la ciliegina sulla torta: il tuo amministratore non finge nemmeno che sia in atto una sorta di politica di sicurezza.

— Dmitry Grigoryev
fonte

E poiché l'OP non ha modo di sapere quanto sia sicura la macchina dell'amministratore (dalla storia, presumibilmente molto insicura), dovrebbe presumere che la chiave privata sia (o sarà) trapelata ad altre persone. L'invio di una chiave privata via e-mail è solo un vantaggio per la mancanza di informazioni.

— dr01,

Puoi presumere che un amministratore in grado di creare utenti non avrà bisogno della tua chiave privata per impersonarti.

— Max Ried il

@MaxRied Potrebbe essere difficile avere a che fare con i registri di sicurezza appropriati. Con la tua chiave privata non ha nemmeno bisogno di deridere i registri. È come avere la possibilità di reimpostare la password anziché conoscerla.

— Dmitry Grigoryev il

@DmitryGrigoryev Potrebbe sempre aggiungere un'altra chiave al tuo file authorized_keys ...

— Max Ried

@MaxRied Mi riferivo /var/log/secureo simile , sono abbastanza sicuro che il trucco spaziale non ingannerà questo.

— Dmitry Grigoryev il

A me sembra che l'amministratore abbia generato per te una coppia di chiavi privata / pubblica, abbia aggiunto la chiave pubblica a authorized_keys e ti abbia inviato quella privata. In questo modo devi solo usare questa chiave privata per le tue sessioni ssh con il server. Non è necessario generare tu stesso una coppia di chiavi o inviare all'amministratore una chiave pubblica per la tua chiave privata eventualmente corrotta (pensa sempre al caso peggiore: P).

Tuttavia, non mi fiderei della chiave privata inviata tramite posta non crittografata.

Il mio approccio sarebbe: utilizzare la chiave privata per accedere una volta, aggiungere la propria chiave pubblica a authorized_keys sul server (sostituendo la chiave pubblica originale) e gettare via questa chiave privata e-mail. Puoi quindi ringraziare l'amministratore per averti fornito la chiave privata ma preferiresti che tali informazioni / chiavi non vengano inviate via e-mail (/ per niente).

— user204269
fonte

@Toby L'unica ragione che posso immaginare per loro di inviare la chiave privata è che non capiscono gli strumenti che stanno usando. E puoi usare -idalla riga di comando per scegliere quale chiave privata usare.

— Kasperd,

@kasperd Il motivo che posso immaginare è un amministratore di sistema sovraccarico che ha deciso che i rischi di inviare una chiave privata tramite e-mail sono compensati dalla seccatura di provare a spiegare agli utenti meno esperti di tecnologia come generare correttamente una coppia di chiavi e inviare il chiave pubblica indietro.

— Mattdm,

Ottimo punto che puoi risolvere questo da solo. Meglio farlo da soli che aspettare che l'amministratore installi la chiave pubblica per una nuova coppia di chiavi. Evitare di usare la chiave privata non più segreta non aiuta nulla; dà a qualsiasi potenziale intercettatore più tempo per usarlo prima che tu possa entrare e rimuoverlo authorized_keys(dopo aver aggiunto + testato il tuo).

— Peter Cordes,

@mattdm That ... è del tutto logico, ma spaventoso. Una persona che non è in grado di generare una coppia di chiavi e di inviarmi la chiave pubblica probabilmente non sta andando molto meglio con una chiave privata che gli do.

— Monty Harder,

@mattdm, abbastanza giusto ma dato che ero io a chiedergli di fare tutto ciò, trovo difficile credere che pensasse di non sapere come connettermi con ssh. Semmai i passi che ha fatto sono stati più confusi poiché conosco solo il modo comune di base per utilizzare le chiavi pubbliche. : x

— Toby,