If you work with code, chances are you’re familiar with GitHub. GitHub is a code hosting platform that allows developers to share and collaborate on code repositories. In this post, we’re going to take a look at one of GitHub’s features: deploy keys.
Table of Content
Things You Should Know To use GitHub Deploy Keys
- You are familiar with GitHub.
- You need to follow the steps carefully to be able to use GitHub deploy keys.
What are Deploy Keys?
Deploy keys are SSH keys that give read-only or read/write access to a single repository. They’re typically used in situations where multiple developers need to have access to a repository, but you don’t want to give everyone full read/write access.
For example, let’s say you’re working on a website with a team of developers. You might want to use deploy keys so that your team can all have access to the code repository, but you don’t want everyone to be able to make changes to the code. In this case, you would give each developer a read-only deploy key.
Method 1: SSH agent forwarding
In many cases, especially at the beginning of a project, SSH agent forwarding is the quickest and simplest method to use. Agent forwarding makes use of the same SSH keys as your local development computer.
- Locally enable agent forwarding. For more information, see our SSH agent forwarding guide.
- Configure your deployment scripts to use agent forwarding. Enabling agent forwarding in a bash script, for example, would look like this:
ssh -A serverA ‘bash -s’ < deploy.sh |
Method 2: HTTPS cloning with OAuth tokens
You can use HTTPS with OAuth tokens instead of SSH keys if you don’t want to use SSH keys. It has some pros and cons:
Pros:
- Anyone with server access can deploy the repository.
- Users are not required to change their local SSH settings.
- Multiple tokens (one for each user) are unnecessary; one token per server is sufficient.
- A token can be revoked at any time, effectively making it a one-time password.
Cons:
- You must configure your token with the appropriate access scopes.
- Tokens are essentially passwords and must be safeguarded in the same manner.
Or you can follow in further detail here.
Method 3: Deploy Keys
You can use a deploy key, which is an SSH key that grants access to a single repository, to launch projects from a GitHub.com repository to your server. Instead of a personal account, GitHub attaches the public part of the key directly to your repository, while the private part of the key remains on your server. See “Delivering deployments” for more information.
Deploy keys with write access can perform the same actions as an admin-level organization member or a collaborator on a personal repository. See “Repository roles for an organization” and “Permission levels for a personal account repository” for more information.
- Run the ssh-keygen command on your server, and remember to save the generated public and private RSA key pair somewhere safe.
- Click your profile photo in the upper-right corner of any GitHub page, then click Your profile.
- Click Repositories on your profile page, then click the name of your repository.
- Click Settings from your repository.
- Click Deploy Keys in the sidebar, then Add Deploy Key.
- Enter a title and your public key.
- If you want this key to have write access to the repository, select Allow writes access. A deploy key with write permissions enables a deployment to push to the repository.
- Select Add key.
Method 4: Server-to-server tokens
If your server needs to access repositories from multiple organizations, you can use a GitHub App to define the access you require, and then use that GitHub App to generate tightly-scoped, server-to-server tokens. Server-to-server tokens can be restricted to single or multiple repositories, and their permissions can be fine-grained. For example, you can create a token with read-only access to the contents of a repository.
Because GitHub Apps are first-class actors on GitHub, server-to-server tokens are unrelated to any GitHub user, making them comparable to “service tokens.” Furthermore, dedicated rate limits for server-to-server tokens scale with the size of the organizations on which they act. See Rate Limits for GitHub Apps for more information.
- Choose whether your GitHub App should be public or private. You probably want your GitHub App to be private if it will only act on repositories within your organization.
- Determine the permissions required by your GitHub App, such as read-only access to repository contents.
- Create your GitHub App from the settings page for your organization. See Creating a GitHub App for more information.
- Take note of your GitHub App id.
- Create and download your GitHub App’s private key, then keep it safe. See Creating a Private Key for more information.
- Install your GitHub App on the repositories where it will be used; alternatively, install the GitHub App on all repositories in your organization.
- Determine the installation id, which represents the link between your GitHub App and the organization repositories it can access. Each GitHub App and organization pair can only have one installation id. This installation id can be found by using the Get an organization installation for the authenticated app. Authenticating as a GitHub App with a JWT is required for this; for more information, see Authenticating as a GitHub App.
- Using the corresponding REST API endpoint, generate a server-to-server token. Create an app installation access token. Authenticating as a GitHub App with a JWT is required for this; for more information, see Authenticating as a GitHub App and Authenticating as an installation.
- This server-to-server token can be used to interact with your repositories via the REST or GraphQL APIs, as well as a Git client.
Tips
Deploy keys are a handy way to give other developers access to your code repositories without giving them full read/write access. If you’re working on a project with a team of developers, deploy keys can help you keep your codebase secure while still allowing your team to collaborate effectively.