# Git repository authentication

> Give ScanSuite access to a private repository: the team SSH key, your own key, and the Git service.

Source: https://scansuite.eu/documentation/usage/static-code-analysis/git-repository-authentication
Last reviewed: 2026-10-19

ScanSuite clones a private repository over SSH, with a key you give it. Public repositories clone over HTTPS without one. HTTPS addresses that contain a user name or password are refused.

> **Note:** An SSH key is the only supported way to reach a protected repository. HTTPS access tokens, such as a GitLab personal access token, are not supported.

## Whose key is used

There are two keys: your own, under My account, and the team's, on the Teams page.

| Scan | Key used |
|---|---|
| Scans you start yourself: the Static Analysis form, Rescan and Scan again, Verify Fixes | Your own key. If you have none, the team key. |
| Schedules (Daily, Weekly, Monthly) and repository watches (Monitor Changes), first run included | Always the team key. |
| Pipeline scans (scansuite-ci) | Always the team key. |

- If your own key cannot reach the repository, the scan fails; it does not fall back to the team key. The scan log names whose key was used.
- A scan keeps the key it started with, so replacing a key affects new scans only.

## 1. Generate a key

Create a key without a passphrase. A key protected by a passphrase is refused when you save it, for both kinds of key.

```bash
ssh-keygen -t ed25519 -f ./scansuite_deploy_key -N ""
```

**Check:** this prints the public key without asking for a passphrase.

```bash
ssh-keygen -y -P "" -f ./scansuite_deploy_key
```

## 2. Add the public key to the Git server

| Platform | Where |
|---|---|
| GitLab | Repository → Settings → Repository → Deploy keys, or your user Settings → SSH Keys |
| Bitbucket | Repository settings → Access keys, or Personal settings → SSH keys |
| GitHub | Repository → Settings → Deploy keys, or your Settings → SSH and GPG keys |

> **Tip:** Prefer a read-only deploy key scoped to one repository over a personal account key. ScanSuite only ever needs to clone.

**Check:** from any machine that can reach the Git server, this lists the repository's branches:

```bash
GIT_SSH_COMMAND="ssh -i ./scansuite_deploy_key -o IdentitiesOnly=yes" git ls-remote git@<GIT_HOST>:<GROUP>/<REPO>.git
```

| Placeholder | Where it comes from |
|---|---|
| <GIT_HOST> | The host name of your Git server, for example gitlab.example.com. |
| <GROUP>/<REPO> | The repository path, as in its SSH clone address. |

## 3. Store the private key in ScanSuite

The key must include its header and footer lines:

```text
-----BEGIN OPENSSH PRIVATE KEY-----
...
-----END OPENSSH PRIVATE KEY-----
```

> **A person does this step:** Paste the private key into ScanSuite yourself.
>
> It is a secret: do not paste it into a chat or hand it to an agent.

### Your own key

For scans you start yourself. Nobody else can read or use it, administrators included.

1. **Open My account and find the Repository access card**
2. **Paste the private key under SSH key for cloning**
3. **Click Save**

**Check:** the heading shows *Saved*, with the date and the key's SHA256 fingerprint; *Not set* means no key is stored. **Remove** deletes it after the question *Remove your SSH key? Scans that started with it will stop cloning.*

### The team key

For schedules, repository watches, pipeline scans and members without a key of their own. Team admins and operators set it.

1. **Open Teams in the sidebar, then the Scanning tab**
2. **In the Team SSH key card, paste the private key into Private key**
3. **Click Save**

![ScanSuite team SSH key](https://scansuite.eu/static/assets/img/docs/usage/static-code-analysis/git-repository-authentication/01.png)

*The Team SSH key card on the Scanning tab of the Teams page*

**Check:** the card shows that a key is saved, with its fingerprint. The key is stored encrypted and never shown again. **Remove** deletes it; scans that still use it stop using it at once.

## 4. Enter the repository in SSH form

On the **Git Repository** tab of the Static Analysis page, enter the SSH address. This is what tells ScanSuite to clone with a key:

```bash
git@<GIT_HOST>:<GROUP>/<REPO>.git
```

An `ssh://` address works too. Full SSH and HTTPS addresses work for GitLab, GitHub and Bitbucket.

**Check:** while you type an SSH address and neither you nor your team has a key, the form warns *SSH repositories need an SSH key for cloning, and neither you nor your team has set one*, with links to My account and the team settings. The warning disappears once a key is saved. If you submit anyway, the scan is refused:

| Message | What to do |
|---|---|
| This repository needs an SSH key. Add your own under My account, or ask a team member who can configure scans to set the team SSH key on the Teams page, under Scanning. | Save your own key (3, Your own key) or have the team key set. |
| Schedules and repository watches clone with the team SSH key, and none is set. | Your own key is not used for schedules. Have the team key set (3, The team key). |

## Repository names and the Git service

Short repository names and Bitbucket project keys, instead of full addresses, work only when the installation's Git service is Bitbucket:

- The **Git service** is one setting for the whole installation, on the System Settings page, Shared services tab, set by a system administrator: **Service** (GitLab, Bitbucket or GitHub), and for Bitbucket the **Bitbucket address** and the **SSH clone address pattern** with `{project}` and `{repo}` placeholders. It also decides how links to source lines are built. See [System Settings](https://scansuite.eu/documentation/administration/platform-administration).
- Your **Git repository API key** (My account → Repository access) is used only to list repositories when you submit a Bitbucket project or a repository name. It is never used to clone.

## If the Git server's host key changes

The first time a scan connects to a Git server, the server's SSH host key is accepted and remembered. If that host key later changes, the clone is refused. Confirm with the Git server's administrators that the change was expected before you ask your ScanSuite operator to accept the new key; an unexplained change can mean the connection is being intercepted.