So che questo ha più di 5 anni ma non c'è una risposta accettata a questa domanda così popolare ecco qui quello che considero il modo migliore considerando la pulizia e la leggibilità futura:
aggiungere un utente distribuire agli TEAM
Fase 1: Creare un nuovo indirizzo di posta elettronica nel dominio dell'organizzazione per un nuovo distribuire utente. Qualcosa come [email protected].
Fase 2: Utilizzare tale cassetta postale per creare un nuovo account GitHub (GitHub calls these "machine users") dargli un nome utente come deploy-ExampleOrganisation quindi il suo ruolo è chiaro.
Fase 3: Creare un utente sul server chiamato "distribuire" con un comando come questo:
useradd -d /home/deploy -m deploy
generare una chiave SSH per implementare @ servername, specificando senza passphrase e /home/deploy/.ssh/id_rsa come la posizione del file:
ssh-keygen -t rsa -b 4096 -C "[email protected]"
Aggiungere il conte nti di /home/deploy/.ssh/id_rsa.pub come una chiave SSH sul vostro nuovo account GitHub -ExampleOrganisation Deploy: Vai Impostazioni> SSH e le chiavi GPG> Nuova SSH Key.
Fase 4: creare un team all'interno dell'organizzazione chiama qualcosa come "Sola lettura distribuire agli utenti", aggiungere il nuovo utente alla squadra e dare alla squadra accesso in lettura a tutti i pronti contro termine che verrà distribuito. (Se non si dispone di un account organizzazione è ancora possibile fornire l'autorizzazione all'accesso a più pronti contro termine privati)
Fase 5: Aggiungere la vostra chiave SSH di macchina personale per distribuire file di chiavi autorizzate dell'utente (/ home /deploy/.ssh/authorized_keys) in modo che tu (o lo script di distribuzione) possa accedere come distribuire durante la distribuzione del codice.
Boom! Questo è tutto ... Ora hai un flusso pulito e autodocumentato.
P.S. Ho provato la risposta altamente acclamata di aculich, ma mi sono sentita sporca in giro con nomi di host falsi e ho pensato, se tornassi su questo in un periodo di tempo, riuscirò a capire facilmente cosa ho fatto per creare tutte le chiavi e capire come quel file di configurazione SSH fa funzionare quei simpatici indirizzi remoti inesistenti? Probabilmente no!
I vantaggi di un utente implementare oltre falso metodo di nomi di host:
- nessun hack! Si tratta di account utente standard con nomi chiari, che accedono ai repository tramite nomi di host reali.
- Meno tasti fluttuanti.
- Se/quando ci si sposta su server aggiuntivi, è facile assegnare un account a tutti gli utenti di distribuzione e solo aggiungendo 1 nuova chiave al proprio account GitHub, il suo account sul nuovo server è pronto per la distribuzione del codice.
- L'utente di distribuzione ha un accesso di sola lettura con privilegi limitati solo ai repository elencati nel team e le chiavi SSH personali vengono mantenute fuori dal server, quindi se qualche persona cattiva accede al server non può sfondare anche tutti i tuoi repository.
- Distribuire i file di configurazione dello strumento (ad es. Capistrano) non essere sporcati contenenti quei nomi host falsi e confusi. (È stato quando hanno iniziato a diffondersi al di là del server che mi sono davvero sentito a disagio con questo metodo.)
- Se dimentichi come diavolo l'hai fatto in anni la proprietà del file ti porterà all'utente di distribuzione
ls -la
, la chiave SSH ti condurrà al nome dell'account GitHub ssh -T [email protected]
e speriamo che tu possa riprendere completamente.
- E infine ... è il metodo consigliato da GitHub.
Ottima risposta e molto utile. Ha funzionato perfetto Grazie –
Non capisco cosa sia falso qui? Genera un'altra chiave. Ogni seconda chiave è chiamata "un falso"? –
@LittleAlien il nome host 'foo' in' foo.github.com' è la parte finta (alias inesistente). Puoi creare tutto ciò che vuoi per il nome host. Ho chiarito la voce con 'fake-hostname-foo.github.com' invece di solo' foo.github.com'. – aculich