Ricezione di una chiave privata dall'amministratore del server: ok o no?

Devo accedere a un server SFTP remoto. L'amministratore ha creato un utente per me e ha generato una coppia di chiavi pubblica / privata per me. Quindi mi ha inviato in modo sicuro il file della chiave privata, che utilizzo per l'autenticazione. Credo che non vada bene, dovrei essere io a generare la coppia di chiavi e dargli la chiave pubblica. Ma non riesco a pensare a nessun buon motivo per cui questo è male, se uso questa chiave solo per accedere a quel server, nessun altro server. Ci sono ragioni del genere?

authentication ssh-keys private-key

— matthiash
fonte

Cattiva igiene della sicurezza, per uno. L'amministratore del server dovrebbe conoscere meglio e non dovrebbe "addestrare" gli utenti ad aspettarsi di ottenere chiavi private da fonti esterne.

— wmorrell,

A chi altro lo sta dando? Pensa sempre, qual è il peggio che potrebbe accadere?

— mckenzm,

In realtà non penso che sia così male. Un'analogia qui sotto (Eric Towers) che fornisce all'utente una "password iniziale" che deve essere cambiata immediatamente è buona. Parlare per esperienza personale, spiegare agli utenti quali sono le chiavi per la centesima volta può essere un po 'noioso: l'amministratore è ancora umano. Darti la chiave privata è pigro, sì, ma nulla può impedirti di sostituirla da solo. In sostanza, dopo che te lo ha inviato, non è necessario disturbare di nuovo il sysadmin (a meno che non abbiano scelto di disattivare le autorizzazioni di scrittura sul file ... quindi, basta infastidirli).

— Ray,

@matthiash questa domanda si adatta a questo sito ma, proprio come una FYI, esiste un sito di sicurezza delle informazioni per altre domande di sicurezza.

— topher

Vorrei anche sottolineare che è così che funziona anche AWS. Quando crei un'istanza a cui non carichi la tua chiave pubblica, viene generata una coppia di chiavi per te e scarichi la chiave privata.

— GnP,

Risposte:

È esattamente come dici tu: l'intero concetto di autenticazione della chiave pubblica è che la chiave privata dovrebbe essere nota solo al proprietario, mentre la chiave pubblica corrispondente può essere ampiamente diffusa. La sicurezza della tua autenticazione dipende dalla sicurezza della chiave privata, non dalla sicurezza della chiave pubblica.

Il fatto che qualcun altro ti fornisca una chiave privata automaticamente la compromette. (Non sai se l'altro amministratore ha ancora una copia che può essere utilizzata per impersonarti.)

— HBruijn
fonte

Assumiamo il meglio dall'amministratore del server e supponiamo che sia meglio generare una nuova coppia di chiavi, poiché non si fiderebbe che l'utente non abbia una chiave privata compormata. Forse l'amministratore del server pensa che la chiave privata degli utenti sia molto vecchia e forse sia stata compromessa nel corso degli anni. È lo stesso con U2F, in cui il consorzio o i fornitori non si fidano degli utenti per generare chiavi, ecco perché i dispositivi U2F sono dotati di chiavi pre-create!

— cornelinux,

L'amministratore dovrebbe aiutare l'utente a generare e proteggere una chiave privata.

— Alex,

Hai perfettamente ragione. Ma spesso gli amministratori stanno meglio con i computer che con gli umani, -)

— cornelinux il

L'amministratore può comunque impersonarti.

— user253751

Penso che tu stia confondendo le pratiche teoriche di un esempio ristretto con la realtà e il quadro generale. Devi comunque fidarti dell'amministratore perché ha il controllo del sistema e può evitare di dover usare la chiave del tutto. La consegna di chiavi private avviene nel mondo reale perché gli utenti finali non capiscono come crearne una o come crearne una in modo sicuro.

— JamesRyan,

Per quella chiave, l'organizzazione non ha non ripudio . Ad esempio, se qualcuno fa qualcosa di offensivo o distruttivo per quel sistema usando la chiave "tua", l'amministratore non può dare la colpa a te per esserne il solo responsabile. Dal momento che anche la persona che te lo ha dato ha avuto la chiave. Probabilmente non è così male per te, dal momento che ti dà una difesa, ma orribile per l'organizzazione che controlla il server, se mai accade qualcosa di brutto.

Potresti essere in grado di utilizzare i privilegi di scrittura che hai dalle chiavi fornite, per aggiornare le tue chiavi autorizzate, aggiungere la tua chiave e rimuovere la chiave fornita.

— Zoredache
fonte

In effetti, l'amministratore potrebbe aspettarsi che l'utente cambi la chiave durante il primo utilizzo, proprio come con le prime password generate amministrativamente.

— Eric Towers,

Come disse un grande uomo "aspettati di distanza". La modifica del primo utilizzo è spesso necessaria per le password, ma non è mai necessaria per la crittografia a chiave pubblica - questo è un po 'il punto.

— womble

@EricTowers È persino possibile richiedere con le implementazioni contemporanee di SFTP (o anche SSH, a meno che tu non sia disposto a mettere insieme qualcosa da solo) implementazioni?

— un CVn il

Questa risposta dà l'impressione che le azioni su sftp siano firmate in un registro da qualche parte e end to end protette da quella chiave. Questo semplicemente non è il caso, un amministratore può manomettere le azioni o i registri senza nemmeno usare la chiave.

— JamesRyan,

@marcelm: C'è un motivo per cui ho detto "spesso necessario", non "sempre assolutamente obbligatorio in tutte le circostanze senza eccezioni". Come qualcuno che, in effetti, richiede regolarmente (e accetta) hash di password e chiavi pubbliche, so che è una barriera molto più elevata convincere qualcuno a fornire una password con hash (con un salt sicuro e tutto il resto) rispetto a una chiave pubblica. Se hai un client SSH, hai uno strumento di generazione delle chiavi. Lo stesso non si può dire per qualcosa in grado di chiamare crypt(2) nelle sue molte forme divertenti.

— womble