我们经常发布文档更新,此页面的翻译可能仍在进行中。有关最新信息,请访问英文文档。如果此页面上的翻译有问题,请告诉我们

此版本的 GitHub Enterprise 已停止服务 2020-11-12. 即使针对重大安全问题,也不会发布补丁。 要获得更好的性能、改进的安全性和新功能,请升级到 GitHub Enterprise 的最新版本。 如需升级方面的帮助,请联系 GitHub Enterprise 支持

Managing deploy keys

Learn different ways to manage SSH keys on your servers when you automate deployment scripts and which way is best for you.

本文内容

You can manage SSH keys on your servers when automating deployment scripts using SSH agent forwarding, HTTPS with OAuth tokens, deploy keys, or machine users.

SSH agent forwarding

In many cases, especially in the beginning of a project, SSH agent forwarding is the quickest and simplest method to use. Agent forwarding uses the same SSH keys that your local development computer uses.

Pros
  • You do not have to generate or keep track of any new keys.
  • There is no key management; users have the same permissions on the server that they do locally.
  • No keys are stored on the server, so in case the server is compromised, you don't need to hunt down and remove the compromised keys.
Cons
  • Users must SSH in to deploy; automated deploy processes can't be used.
  • SSH agent forwarding can be troublesome to run for Windows users.
设置
  1. Turn on agent forwarding locally. See our guide on SSH agent forwarding for more information.
  2. Set your deploy scripts to use agent forwarding. For example, on a bash script, enabling agent forwarding would look something like this: ssh -A serverA 'bash -s' < deploy.sh

HTTPS cloning with OAuth tokens

If you don't want to use SSH keys, you can use HTTPS with OAuth tokens.

Pros
  • Anyone with access to the server can deploy the repository.
  • Users don't have to change their local SSH settings.
  • Multiple tokens (one for each user) are not needed; one token per server is enough.
  • A token can be revoked at any time, turning it essentially into a one-use password.
  • Generating new tokens can be easily scripted using the OAuth API.
Cons
  • You must make sure that you configure your token with the correct access scopes.
  • Tokens are essentially passwords, and must be protected the same way.
设置

See our guide on Git automation with tokens.

部署密钥

您可以使用部署密钥从 GitHub Enterprise Server 仓库启动项目到服务器,部署密钥是授予访问单个仓库的 SSH 密钥。 GitHub Enterprise Server 将密钥的公共部分直接附加到仓库而不是个人用户帐户,密钥的私有部分仍保留在服务器上。 更多信息请参阅“交付部署”。

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

Pros
  • Anyone with access to the repository and server has the ability to deploy the project.
  • Users don't have to change their local SSH settings.
  • Deploy keys are read-only by default, but you can give them write access when adding them to a repository.
Cons
  • Deploy keys only grant access to a single repository. More complex projects may have many repositories to pull to the same server.
  • Deploy keys are usually not protected by a passphrase, making the key easily accessible if the server is compromised.
设置
  1. Run the ssh-keygen procedure on your server, and remember where you save the generated public/private rsa key pair.
  2. In the upper-right corner of any GitHub Enterprise Server page, click your profile photo, then click Your profile.
    Navigation to profile
  3. On your profile page, click Repositories, then click the name of your repository.
    Repositories link
  4. From your repository, click Settings.
    Repository settings
  5. In the sidebar, click Deploy Keys, then click Add deploy key.
    Add Deploy Keys link
  6. Provide a title, paste in your public key.
    Deploy Key page
  7. Select Allow write access if you want this key to have write access to the repository. A deploy key with write access lets a deployment push to the repository.
  8. Click Add key.

Machine users

If your server needs to access multiple repositories, you can create a new GitHub Enterprise Server account and attach an SSH key that will be used exclusively for automation. Since this GitHub Enterprise Server account won't be used by a human, it's called a machine user. You can add the machine user as a collaborator on a personal repository (granting read and write access), as an outside collaborator on an organization repository (granting read, write, or admin access), or to a team with access to the repositories it needs to automate (granting the permissions of the team).

Pros
  • Anyone with access to the repository and server has the ability to deploy the project.
  • No (human) users need to change their local SSH settings.
  • Multiple keys are not needed; one per server is adequate.
Cons
  • Only organizations can restrict machine users to read-only access. Personal repositories always grant collaborators read/write access.
  • Machine user keys, like deploy keys, are usually not protected by a passphrase.
设置
  1. Run the ssh-keygen procedure on your server and attach the public key to the machine user account.
  2. Give the machine user account access to the repositories you want to automate. You can do this by adding the account as a collaborator, as an outside collaborator, or to a team in an organization.