管理部署密钥

在自动执行部署脚本时，您可以使用 SSH 代理转发、HTTPS 结合 OAuth 令牌、部署密钥或机器用户来管理服务器上的 SSH 密钥。

SSH 代理转发

在许多情况下，尤其是在项目开始时，SSH 代理转发是最快和最简单的方法。代理转发与本地开发计算机使用相同的 SSH 密钥。

SSH 代理转发的优点

无需生成或跟踪任何新密钥。
没有密钥管理；用户在服务器上具有与本地相同的权限。
服务器上没有存储密钥，因此，万一服务器受到破坏，您不需要搜索并删除泄露的密钥。

SSH 代理转发的缺点

用户必须通过 SSH 连接进行部署；无法使用自动部署流程。
对于 Windows 用户来说，使用 SSH 代理转发可能比较麻烦。

设置 SSH 代理转发

在本地开启代理转发。有关详细信息，请参阅有关 SSH 代理转发的指南。
将部署脚本设置为使用代理转发。例如，在 bash 脚本上，启用代理转发将如下所示：ssh -A serverA 'bash -s' < deploy.sh

使用 OAuth 令牌进行 HTTPS 克隆

如果不想使用 SSH 密钥，可以将 HTTPS 与 OAuth 令牌结合使用。

使用 OAuth 令牌进行 HTTPS 克隆的优点

有权访问服务器的任何人都可以部署仓库。
用户不必更改其本地 SSH 设置。
不需要多个令牌（每个用户一个）；每个服务器一个令牌就足够了。
令牌可随时撤销，本质上变成一次性密码。
使用 OAuth API 可以轻松编写生成新令牌的脚本。

使用 OAuth 令牌进行 HTTPS 克隆的缺点

必须确保使用正确的访问范围配置令牌。
令牌本质上是密码，必须以同样的方式进行保护。

设置使用 OAuth 令牌进行 HTTPS 克隆

请参阅创建 personal access token 指南。

部署密钥

可以使用部署密钥（即授予对单个存储库的访问权限的 SSH 密钥）从你的 GitHub Enterprise Server 实例上的存储库启动项目到服务器。 GitHub Enterprise Server 将密钥的公共部分直接附加到存储库而不是个人帐户，密钥的私有部分仍保留在服务器上。有关详细信息，请参阅“交付部署”。

具有写入权限的部署键可以执行与具有管理员权限的组织成员或个人仓库上的协作者相同的操作。有关详细信息，请参阅“组织的存储库角色”和“个人帐户存储库的权限级别”。

部署密钥的优点

有权访问仓库和服务器的任何人都能够部署项目。
用户不必更改其本地 SSH 设置。
部署密钥默认为只读，但在将其添加到存储库时可授予它们写入权限。

部署密钥的缺点

部署密钥只授予对单个仓库的访问权限。较复杂的项目可能要将多个仓库拉取到同一服务器。
部署密钥通常不受密码保护，因此在服务器遭到破坏时可轻松访问密钥。

设置部署密钥

在服务器上运行 ssh-keygen 过程，并记住保存生成的公共和专用 rsa 密钥对的位置。
在你的 GitHub Enterprise Server 实例上，导航到存储库的主页。 1. 在存储库名称下，单击 “设置”。如果看不到“设置”选项卡，请选择下拉菜单，然后单击“设置” 。
在边栏中，单击“部署密钥”。
单击“添加部署密钥”。
在“标题”字段中，提供标题。
在“密钥”字段中，粘贴公钥。
如果希望此密钥具有对存储库的写入权限，请选择“允许写入权限”。具有写入权限的部署密钥允许将部署推送到仓库。
单击“添加密钥”。

在一台服务器上使用多个仓库

如果在一台服务器上使用多个仓库，则需要为每个仓库生成专用密钥对。不能对多个仓库重复使用一个部署密钥。

在服务器的 SSH 配置文件中（通常为 ~/.ssh/config），为每个存储库添加别名条目。例如：

Host my-GHE-hostname.com-repo-0
        Hostname my-GHE-hostname.com
        IdentityFile=/home/user/.ssh/repo-0_deploy_key

Host my-GHE-hostname.com-repo-1
        Hostname my-GHE-hostname.com
        IdentityFile=/home/user/.ssh/repo-1_deploy_key

Host my-GHE-hostname.com-repo-0 - 存储库的别名。
Hostname my-GHE-hostname.com - 将主机名配置为与别名一起使用。
IdentityFile=/home/user/.ssh/repo-0_deploy_key - 将私钥分配给别名。

然后可以使用主机名的别名通过 SSH 与仓库进行交互，SSH 将使用分配给该别名的唯一部署密钥。例如：

$ git clone git@my-GHE-hostname.com-repo-1:OWNER/repo-1.git

服务器到服务器令牌

如果服务器需要访问一个或多个组织的存储库，可以使用 GitHub 应用来定义需要的访问权限，然后从该 GitHub 应用生成 tightly-scoped、server-to-server 令牌。服务器到服务器令牌可以扩展到单个或多个仓库，并且可以拥有细致的权限。例如，您可以生成对仓库内容具有只读权限的令牌。

由于 GitHub 应用程序是 GitHub Enterprise Server 上的一类角色，因此服务器到服务器令牌不限于任何 GitHub 用户，这使它们堪比“服务令牌”。此外，服务器到服务器令牌有专门的速率限制，与它们所依据的组织规模相当。有关详细信息，请参阅 GitHub Apps 的速率限制。

服务器到服务器令牌的优点

具有明确定义的权限集和到期时间的严格范围令牌（如果使用 API 手动撤销，则为 1 小时或更短时间）。
随组织而增长的专用速率限制。
与 GitHub 用户身份脱钩，因此他们不消耗任何许可席位。
从未授予密码，因此无法直接登录。

服务器到服务器令牌的缺点

创建 GitHub 应用程序需要其他设置。
服务器到服务器令牌 1 小时后过期，因此需要重新生成，通常是按需使用代码。

设置服务器到服务器令牌

确定您的 GitHub 应用程序是公开的还是私有的。如果您的 GitHub 应用程序将仅在您组织内的仓库上操作，您可能希望它是私有的。
确定 GitHub 应用程序所需的权限，例如对仓库内容的只读访问权限。
通过组织的设置页面创建您的 GitHub 应用程序。有关详细信息，请参阅创建 GitHub 应用程序。
记下 GitHub 应用 id。
生成并下载 GitHub 应用程序的私钥，并妥善保管。有关详细信息，请参阅生成私钥。
将 GitHub 应用程序安装到需要执行它的仓库中，您可以在组织中的所有仓库上选择性地安装 GitHub 应用程序。
标识 installation_id，它表示 GitHub 应用与其可以访问的组织存储库之间的连接。每个 GitHub 应用和组织对都最多只有一个 installation_id。可以通过获取经过身份验证的应用的组织安装来标识此 installation_id。这需要使用 JWT 验证为 GitHub 应用，有关详细信息，请参阅验证为 GitHub 应用。
使用相应的 REST API 终结点生成服务器到服务器令牌，为应用创建安装访问令牌。这需要使用 JWT 验证为 GitHub 应用，有关详细信息，请参阅验证为 GitHub 应用以及验证为安装。
使用此服务器到服务器令牌，通过 REST 或 GraphQL API 或者通过 Git 客户端与您的仓库进行交互。

机器用户

如果服务器需要访问多个存储库，你可以创建一个新的你的 GitHub Enterprise Server 实例帐户并附加专用于自动化的 SSH 密钥。由于人们不会使用你的 GitHub Enterprise Server 实例上的这个帐户，因此它被称为“机器用户”。可以将机器用户添加为个人存储库上的协作者（授予读取和写入访问权限），或添加为组织存储库上的外部协作者（授予读取、写入或管理员访问权限），或添加到有权访问其需要自动化的存储库的团队（授予团队权限）。

计算机用户的优点

有权访问仓库和服务器的任何人都能够部署项目。
没有（人类）用户需要更改其本地 SSH 设置。
不需要多个密钥；每台服务器一个就足够了。

计算机用户的缺点

只有组织才能将机器用户限制为只读访问。个人仓库始终授予协作者读取/写入权限。
机器用户密钥（如部署密钥）通常不受密码保护。

设置计算机用户

在服务器上运行 ssh-keygen 过程，并将公钥附加到计算机用户帐户。
授予机器用户帐户访问要自动化的仓库的权限。可以通过将帐户添加为协作者、外部协作者，或添加到组织中的团队来执行此操作。

延伸阅读

配置通知