nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Stash licensing for CI build systems

Dominik Rauch

We're using TeamCity as our CI build system. Currently we have a single Stash user for TeamCity which has read-only access rights to all repositories.

This is bad from the security point of view, as each project admin knows the password to a user which is able to read all Git repositories. Is there a possiblity to create a read-only user for TeamCity per repository (or per project) without losing a licensed user each time?

Best regards,
Dominik

Accepted answers

Michael Heemskerk

Hi Dominik,

I think "access keys" is what you're looking for: https://confluence.atlassian.com/display/STASH/Using+SSH+keys+to+secure+Git+operations. It allows you to create SSH keys that provide read-only access to a specific repository without them being linked to a user (and taking up a license).

Cheers,

Michael

All comments

Michael Heemskerk

Hi Dominik,

Cheers,

Michael

Dominik Rauch

Hi Michael!

Thanks for your initial reply, while your suggested solution sounds promising, it has drawbacks:

* According to https://confluence.atlassian.com/display/STASH/Enabling+SSH+access+to+Git+repositories+in+Stashit is not recommended to use SSH access for automatic build tools (see performance note on linked page)

* It forces us to create and manage a lot of keys which adds a lot of administrative work for our admin

* It forces us to enable SSH on the Stash server

Is there no chance to create read-only-users per project/repository which do not add to the licencse number? Or any other HTTPS-based way to integrate Stash with TeamCity?

Best regards,
Dominik

Michael Heemskerk

Dominik,

Glad to see someone is reading the documentation! You're right that switching to SSH will add more CPU load to your system and we advise people to use HTTP(S) when possible. It depends on the current load on your system whether this would be an issue or not. We currently don't support HTTP-based access keys, but feel free to open a feature request for it on https://jira.atlassian.com.

With respects to the other two drawbacks:

* Administrative work: you can set up access keys at either the project or repository level. Using SSH access keys or username/password combos for accessing repositories is approximately the same amount of administrative work I think. If you set up access keys at the project level, the overhead wouldn't be too bad?

* Forcing enabling SSH on the Stash server. Please note that Stash ships an embedded SSH server that _only_ allows a small number of operations. Users cannot open a shell on the server using it, nor run arbitrary commands. The SSH server only supports git-upload-pack, git-receive-pack, git-archive-pack and a custom whoami command.

Dominik Rauch

So I guess we have to use Access Keys until https://jira.atlassian.com/browse/STASH-4989is implemented, thank you.