Utilizzo della stessa chiave di distribuzione per più progetti GitHub

94

Github non consente di utilizzare la stessa chiave di distribuzione ssh per più di un progetto, il che sarebbe molto utile in alcuni casi (ad esempio il server CI che si occupa di progetti con sottomoduli privati). Ho visto vari thread che sembrano dire che questa limitazione è presente per "motivi di sicurezza", ma devo ancora vedere una spiegazione convincente su esattamente quale rischio aumenterebbe.

Tieni presente che il fatto che Github non consenta il riutilizzo delle chiavi a livello di account ha senso (due utenti non dovrebbero condividere le chiavi). È solo la restrizione sulla distribuzione delle chiavi che sto mettendo in dubbio.

E per essere chiari, io sto , non alla ricerca di soluzioni alternative (creare un utente fittizio, utilizzare più chiavi, ...), ma solo per una spiegazione plausibile per questa limitazione su Deploy Keys.

Discussioni correlate:

git  github  ssh 
— David Ebbo
fonte
Poiché non esiste un modo migliore, abbiamo creato un utente di distribuzione dedicato a cui stiamo concedendo l'accesso in sola lettura ai repository. Il risultato finale è lo stesso.
— Datageek
— apple16

Risposte:

22

L'unico motivo, illustrato dalla soluzione alternativa a cui fai riferimento (creazione di un singolo utente "build" o condivisione dello stesso id_rsa.REPONAME.pubper repo) è:

evitare di condividere la chiave pubblica / privata per utenti diversi

Anche se non sarebbe il caso nella tua situazione (creazione di più progetti), consentire di riutilizzare la stessa chiave ssh aprirebbe la possibilità a due utenti diversi di condividere la stessa chiave ssh, vanificando lo scopo di autenticazione .

Autenticazione significa:
"l'utilizzo di una determinata chiave ssh dovrebbe implicare che si suppone che tu sappia chi la sta utilizzando".

La pagina di GitHub " Gestione delle chiavi di distribuzione " descrive i vari account che utilizzano ssh:

  • Inoltro dell'agente SSH : l' inoltro dell'agente utilizza le chiavi SSH già configurate sulla macchina di sviluppo locale quando accedi tramite SSH al tuo server ed esegui i comandi git.
    È possibile consentire selettivamente ai server remoti di accedere al proprio ssh-agent locale come se fosse in esecuzione sul server.
    Quindi non è necessario replicare la tua chiave privata sul server.

  • Utenti della macchina : (questa è la strategia "account fittizio") Collegare la chiave a un account utente. Poiché questo account non verrà utilizzato da un essere umano, viene chiamato utente macchina.
    Tuttavia, tratteresti questo utente allo stesso modo di un essere umano, allegando la chiave all'account utente della macchina come se fosse un normale account.
    Concedi al collaboratore dell'account o al team l'accesso ai repository a cui deve accedere.
    Quindi una chiave privata associata a un "utente macchina", una per server.

( DHa sottolinea nei commenti un numero limite di chiavi di distribuzione e il fatto che puoi avere un solo account utente della macchina)

  • Distribuisci la chiave (una per repository GitHub) Chiave SSH archiviata sul server e concede l'accesso a un singolo repository su GitHub.
    Questa chiave è collegata direttamente al repository invece che a un account utente .
    Invece di andare alle impostazioni del tuo account, vai alla pagina di amministrazione del repository di destinazione.
    Vai a " Deploy Keys" e fai clic su " Add deploy key". Incolla la chiave pubblica e invia.

Questa volta, la chiave ssh non è collegata a un utente (per il quale è possibile concedere l'accesso a diversi repository), ma a un repository.
La concessione dell'accesso ssh a diversi repository sarebbe l'equivalente di un "utente macchina".

In termini di autenticazione :

  • usare la stessa chiave per più repository va bene quando è fatto da un utente (che ha detto chiave associata al suo account)
  • usare la stessa chiave per diversi repository NON va bene quando la chiave è allegata da un repository, perché non sai affatto chi ha avuto accesso a cosa.
    Ciò è diverso dall '"utente macchina" in cui un "utente" viene dichiarato collaboratore per molti repository.
    Qui (chiave di distribuzione), non esiste un "collaboratore" , ma solo un accesso SSH diretto concesso al repository.
— VonC
fonte
53
GitHub supporta sia chiavi pubbliche a livello di account che chiavi a livello di progetto (note anche come chiavi di distribuzione). Non consentire il riutilizzo delle chiavi a livello di account ha senso, ma sostengo che non consentirlo per Distribuisci chiavi non lo è. La mia chiave a livello di account consente l'accesso a tutti i miei progetti, quindi perché non potrei avere una chiave di distribuzione che consenta l'accesso ad alcuni dei miei progetti? È solo più restrittivo e non crea alcuna preoccupazione che io possa vedere. La tua preoccupazione sull'apertura della possibilità per due diversi utenti di condividere la stessa chiave ssh non compare nell'immagine in quello scenario.
— David Ebbo,
@DavidEbbo Potrebbe non apparire nella foto, ma questa preoccupazione (due utenti diversi per condividere la stessa chiave ssh) è alla base del motivo per cui una chiave ssh non è condivisa.
— VonC
21
Temo di non seguire il tuo ragionamento qui. Sto chiedendo uno scenario molto specifico (usa una chiave di distribuzione in più progetti), e il tuo argomento per non essere possibile è far apparire uno scenario non correlato (due utenti che condividono le chiavi ssh). Attenendosi esclusivamente allo scenario di distribuzione della chiave, quale sarebbe lo svantaggio del fatto che GitHub lo consenta?
— David Ebbo,
6
@DavidEbbo Seguendo help.github.com/articles/managing-deploy-keys , nessuno dei tre metodi (Account, Deploy o Machine) prevede la condivisione di una chiave SSH privata per accedere a detti repository. Attenersi esclusivamente allo scenario di distribuzione della chiave, poiché è una chiave sul server , per essere valido su più repository significherebbe condividere (o replicare) una chiave privata su più repository. Ciò diminuisce l'aspetto dell'autenticazione e, se la chiave è compromessa, aumenta il numero di repo esposti.
— VonC
8
grazie, quella pagina ha informazioni interessanti. Contrassegnerò la tua risposta come risposta tra un giorno o due se non vedo nient'altro, anche se ad essere sincero non sono ancora convinto dall'argomento. Avere una chiave di distribuzione utilizzata su due repository non è più debole che utilizzare una chiave macchina che ha accesso allo stesso set di repository.
— David Ebbo,
11

Sfortunatamente, questo è uno scenario in cui github interpreta male la distinzione tra una coppia di chiavi e un account o progetto.

Poiché una coppia di chiavi viene utilizzata per l'autenticazione e l'autorizzazione, è effettivamente un'identità. Gli account Github sono un'altra identità. Il collegamento di account GitHub a coppie di chiavi stabilisce in modo efficace una mappatura 1: N tra identità basate su account GitHub e identità di coppie di chiavi.

Al contrario, github applica una mappatura 1: N dei progetti alle identità basate sulla coppia di chiavi. L'analogo del mondo reale è che esiste una porta che garantisce l'accesso al progetto che può essere sbloccata da molte persone diverse. Ma una volta che qualcuno di loro ottiene una chiave della porta, non possono più ottenere altre chiavi per nessun'altra porta.

Ha senso non riutilizzare le chiavi spesso dal punto di vista del contenimento delle violazioni se una chiave viene compromessa. Ma questa è solo una buona politica amministrativa . Non ha molto senso impedire che una chiave venga utilizzata più di una volta per principio . Che ci sono alcune chiavi per alcune porte che non vengono mai riutilizzate, beh, ancora una volta dipende dalla politica .

Una visione leggermente più complessa consiste nell'illustrare le coppie di chiavi come ruoli . Puoi possedere molte coppie di chiavi e quindi ricoprire molti ruoli. La chiave privata ti autentica per il ruolo.

La mappatura delle chiavi di distribuzione di Github nei progetti afferma che un ruolo non può mai comprendere più di un'attività. È raramente realistico.

Niente di tutto ciò cambia ciò che github consente, ovviamente.

— Jens Finkhaeuser
fonte
1
Eh. È piuttosto divertente come questo venga svalutato, quando è più corretto della risposta accettata. Non c'è letteralmente nulla in questo che impedisce la condivisione di una chiave con più utenti.
— Jens Finkhaeuser
2

Mi ci è voluto molto tempo per razionalizzare le implicazioni e ho pensato a questo scenario.

Immagina di creare una singola chiave di distribuzione per un utente che hai assegnato a più repository. Ora vuoi revocare quella chiave ma è usata in più posti. Quindi, invece di poter revocare tutti gli accessi, potresti inavvertitamente revocare solo l'accesso parziale.

Può sembrare un vantaggio, ma questa relazione molti-a-uno è in realtà intrinsecamente insicura una volta considerato il fattore umano. Questo perché non puoi sapere con certezza se hai davvero revocato tutti gli accessi senza ispezionare ogni repository e confrontare ogni chiave pubblica individualmente nel caso in cui ti sei dimenticato di dove l'hai effettivamente assegnata.

È decisamente frustrante assegnare e gestire così tante chiavi univoche, ma le implicazioni sulla sicurezza sono chiare con il modo in cui GitHub ha istituito la loro politica: quando revochi una chiave sei sicuro di revocare tutti gli accessi concessi da quella chiave perché è usata solo in un posto .

— Zhro
fonte
1
Non sono convinto da questa spiegazione. In che modo è fondamentalmente diverso dal consentire a un utente di accedere a più repository, cosa ovviamente consentita? Se non ti fidi più di quell'utente, dovresti rimuoverlo da ogni repository.
— David Ebbo
@ David: How is that fundamentally different from allowing one user to access multiple repositories, which is obviously allowedpuoi spiegarlo ulteriormente? Ho solo un account sviluppatore e vedo che puoi aggiungere chiavi ssh per l'accesso a livello di account (una chiave per tutti i repository) o aggiungere chiavi di distribuzione individuali (una chiave per ogni repository). Questa è ancora una relazione uno-a-molti o uno-a-uno in cui la revoca della chiave "uno" revoca l'accesso "tutto" in entrambi i casi.
— Zhro
Per chiarire ulteriormente, non c'è alcuna possibilità (cosa posso dire) di assegnare accidentalmente una chiave in una relazione molti-a-uno in cui l'accesso potrebbe esistere altrove dopo essere stato revocato. Questa sembra essere la motivazione di GitHub per questa restrizione, ma sto solo supponendo.
— Zhro
Per come vedo le cose, le chiavi di distribuzione sono un po 'come "utenti anonimi" che non hanno un account completo, ma rappresentano comunque una sorta di identità. La differenza è che nel caso dell'account, si concede l'accesso all'account, che indirettamente dà accesso a tutte le chiavi ssh in quell'account. Mentre nel caso Deploy Key, salti l'astrazione dell'account e concedi direttamente l'accesso alla chiave ssh. Ma oltre a questo, non vedo che le esigenze di sicurezza siano diverse. Se l'account o il proprietario della chiave di distribuzione diventa malvagio, è necessario rimuoverli da ogni repository.
— David Ebbo
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.