Managing deploy keys

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.

Setup

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.

Setup

See our guide on creating a personal access token.

Deploy keys

You can launch projects from a repository on your GitHub Enterprise Server instance to your server by using a deploy key, which is an SSH key that grants access to a single repository. GitHub Enterprise Server attaches the public part of the key directly to your repository instead of a personal account, and the private part of the key remains on your server. For more information, see "Delivering deployments."

Deploy keys with write access can perform the same actions as an organization member with admin access, or a collaborator on a personal repository. For more information, see "Repository roles for an organization" and "Permission levels for a personal account repository."

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.

Setup

1. Run the ssh-keygen procedure on your server, and remember where you save the generated public and private rsa key pair.

2. In the upper-right corner of any GitHub Enterprise Server page, click your profile photo, then click Your profile.

   

3. On your profile page, click Repositories, then click the name of your repository.

4. From your repository, click Settings.

5. In the sidebar, click Deploy Keys, then click Add deploy key.