You signed in with another tab or window.Reload to refresh your session.You signed out in another tab or window.Reload to refresh your session.You switched accounts on another tab or window.Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Nov 1, 2017. It is now read-only.
Clarify deploy keys and collaborators are always granted read/write access.
Clarify difference between machines users on a team vs machines users as collaborator.Clarify machine accounts are 'github user accounts'.Clarify user-owned repos are unable to grant read-only access.
*Deploy keys always providefull read/write access toa repository.
73
73
* Deploy keys are usually not protected by a passphrase, making the key easily accessible if the server is compromised.
74
74
75
75
####Setup
@@ -88,11 +88,11 @@ A deploy key is an SSH key that is stored on your server and grants access to a
88
88
89
89
##Machine users
90
90
91
-
If your server needs to access multiple repositories, you can choose to attach an SSH keyto an automated user account.Since this account won't be used by a human, it's called a machine user. You can then[add the machineaccount as collaborator][collaborator] or[add the machine user to a team][team] with access to the repositories it needs to manipulate.
91
+
If your server needs to access multiple repositories, you can choose tocreate a new github account andattach an SSH keythat will be used exclusively for automation.Since thisgithubaccount won't be used by a human, it's called a machine user.You can then[add the machineuser as collaborator][collaborator] or[add the machine user to a team][team] with access to the repositories it needs to manipulate.**NOTE**: Adding a machine user as a collaborator always grants read/write access. Adding a machine user to a team grants the permissions of the team.
92
92
93
93
<divclass="alert">
94
94
<p>
95
-
<strong>Tip</strong>: Our <ahref="https://help.github.com/articles/github-terms-of-service">terms of service</a> do mention that <em>'Accounts registered by "bots" or other automated methods are not permitted.'</em> and that <em>'One person or legal entity may not maintain more than one free account.'</em> But don't fear, we won't send rabid lawyers out to hunt you down if youmake machine users for your server deploy scripts. Machine users are completely kosher.
95
+
<strong>Tip</strong>: Our <ahref="https://help.github.com/articles/github-terms-of-service">terms of service</a> do mention that <em>'Accounts registered by "bots" or other automated methods are not permitted.'</em> and that <em>'One person or legal entity may not maintain more than one free account.'</em> But don't fear, we won't send rabid lawyers out to hunt you down if youcreate machine users for your server deploy scripts. Machine users are completely kosher.
96
96
</p>
97
97
</div>
98
98
@@ -101,11 +101,10 @@ If your server needs to access multiple repositories, you can choose to attach a
101
101
* Anyone with access to the repository and server has the ability to deploy the project.
102
102
* No (human) users need to change their local SSH settings.
103
103
* Multiple keys are not needed; one per server is adequate.
104
-
* Organizations can give read-only access to their machine users.
105
104
106
105
####Cons
107
106
108
-
*By default, the key has full read/writeaccess tothe repository if the repository belongs to a user account. You can add themachineuser toaread-onlyteam if it's accessing repositoriesin an organization.
107
+
*Only organizations haveaccess tocreate teams; therefore only organizations can use them to restrictmachineusers to read-onlyaccess. Individual user-owned repositoriesalways grant read/write to collaborators.
109
108
* Machine user keys, like deploy keys, are usually not protected by a passphrase.