If you're cloning a specific application, the server could have its own key with read-only access to the repo. But if you're using that for deployment, you could (in AWS) grant the instance access to specific S3 paths and pass a specific artefact URL to be downloaded. (Or something similar for other environments)
But maybe you've got a different use case? I'd start with "why are you using git directly on a (production?) server?"
I'm gonna out myself because nobody is giving reasons
Why is it bad to git clone on a production server? Let's assume I'm not an idiot please, just misguided. This isn't reddit.
Let's also assume I'm using an ssh key that is only used for the purposes of pulling the repo, no write access, never reused (deploy keys as the git* services call them)
It's really hard to see these tips as anything but parroting someone else if nobody throws down a reason
I don't think you're outing yourself exactly; this is a scale-dependent question. People will give different answers because their experience is coloured by the size of the systems and organisations they have experience with.
At small scale it's fine. Plenty of useful and valuable stuff runs on a handful of servers that have consistent identities etc and people manage them interactively. Process lives in people's heads or (better) a wiki.
At large scale it's a completely bonkers thing to do. There are tons of nodes; it doesn't make sense to mutate just one unless something has gone badly wrong. Interactive login to a production system should be triggering an incident or at least linked to one. Really you shouldn't be mutating systems in any kind of "manual" way because that kind of change is supposed to be locked down to authorised deployment methods. The current state of the system has to be legible to other team members and other teams, and the easiest way to do that is by looking at what's gone through the deployment process, which is usually navigable via a dashboard.
In the middle, it's possible you could have a deployment system that relies on "git clone" with a key on the instance. That would be a little weird because git is not a great way to store or distribute build artefacts. Not crazy though - could make sense in some situations.
So you already protected most of it - no write access and scoped keys fix most of the issues.
Other potential problems:
- bad checkout ___location may mean unexpected content is available via .git paths on the web
- anyone with access to the server can copy the key and have external access to both the history of the project and all new commits - they can see the PRs with proposed security fixes before they get merged
- repository may contain ___domain names, credentials and other things which don't need to be deployed, but can be useful for the attacker doing recon
- potentially exposing information about customers if they got mentioned in the history
It's not terrible to use git directly. There are just ways you can deploy a little bit better if it's worth your time investment.
> Why is it bad to git clone on a production server? Let's assume
> I'm not an idiot please, just misguided. This isn't reddit.
This cargocult ritual is for those who manage farms of identical servers. If you have a single production server with no load balancing, it's fine.
But be careful, Git does not handle file permissions well by default. If you have a directory or file that needs special permissions (like a cron job script) then you should set `core.fileMode` to `false` in your git config.
It _is_ cargo-culting when publications begin to recommend it as standard practice, without explaining the reasoning. Because at that point either the publisher is doing it without understanding why, or the reader will follow the ritual without understanding why.
But maybe you've got a different use case? I'd start with "why are you using git directly on a (production?) server?"