> For the complete documentation index, see [llms.txt](https://docs.release.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.release.com/reference-documentation/account-settings/build-settings/build-ssh-keys.md).

# Build SSH keys

Securely pass SSH keys to the Docker build command

With Release, you can pass SSH keys to the `docker build` command as part of the build process.

You might need to pass SSH keys to a `docker build` command if the build process pulls code or other dependencies from a private Git repository hosted on a remote server. To access the repository, the build process will authenticate with the server using SSH keys.

## Add the SSH key to a Dockerfile

Start by updating your Dockerfile to use the passed-in SSH keys.

Use `RUN --mount=type=ssh,id=your_key_name` to mount the SSH key in your Dockerfile. Read more about SSH keys and Docker builds in the [Docker documentation](https://docs.docker.com/engine/reference/commandline/buildx_build/#ssh).

If you plan to use only one SSH key in your organization, you can use `RUN --mount=type=ssh` without the ID, and name the SSH key `default` in the Release UI.

## Add the SSH key to Release

In Release, you can set build SSH keys at the account level. These SSH keys will be passed to all the builds in your account.

Access the build SSH keys by going to **Configuration** -> **SSH Keys**

![Add a new SSH key](https://585411240-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-M1neGLLQ0sDXeK6ooSo%2Fuploads%2Fgit-blob-f673b8e427b01f6592ae592b22ec53be66d9f108%2FSSH-Keys.png?alt=media)

The following fields are required to add a new SSH key:

* **Name:** The name of the SSH key. Release uses this name to pass the SSH key when building the Dockerfile. The SSH key name should match the `id` of the SSH key in your Dockerfile.
* **Secret Identifier:** This can be either the full private SSH key (including `BEGIN` and `END` tags) or the secret ID of the SSH key stored in your cloud secret storage and configured in Release.

### Example Dockerfile and Release SSH key

The following Dockerfile example clones a GitHub repo and uses the SSH key with the name `myssh`:

{% code title="Dockerfile" %}

```docker
# start from a base image
FROM ubuntu:20.04

# install dependencies
RUN apt-get update && apt-get install -y git
RUN sed /^StrictHostKeyChecking/d /etc/ssh/ssh_config; \
  echo StrictHostKeyChecking no >> /etc/ssh/ssh_config
  
# clone the target repository
RUN --mount=type=ssh,id=myssh git clone git@github.com:release/example_privaterepo.git
```

{% endcode %}

![Note the name of the SSH key matches the ID in the Dockerfile](https://585411240-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-M1neGLLQ0sDXeK6ooSo%2Fuploads%2Fgit-blob-adbda219c9ba95535ea3d6d05ef7d05736a8ecd5%2Fdocker-ssh.png?alt=media)

## SSH keys and secrets

By default, the SSH keys you add in the Release Build Settings UI are stored in the Release Secrets Manager. However, you can use SSH keys stored in AWS SSM, AWS Secrets Manager, or GCP Secret Manager to pass to Docker builds, as long as these secrets managers are configured with Release. Learn more about configuring your secrets manager with Release in our [importing secrets from external secrets managers](/reference-documentation/environment-settings/environment-specific-environment-variables/secrets.md) documentation.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.release.com/reference-documentation/account-settings/build-settings/build-ssh-keys.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.