@hukl

I am not big fan of giving out interactive ssh access to a 3rd parties. Even with a restricted account.

What you can do is to use ssh's "ForceCommand" to make it more secure. But that moves the actually deploy logic from the CI to the server.

It basically turns the ssh just into a fancy webhook with ssh auth.

https://github.com/tcurdt/nixcfg/blob/main/modules/hook-ssh.nix

@tcurdt yup - definitely adjustable to individual paranoia levels :)

will have a look at you link :)

@tcurdt @hukl we have an intermediate server for this role. GH can webhook to server, server has ssh to deploy on target.

@janl @hukl

Speaking of Github, their auth story feels so incredible frustrating:

- classic PAT
- fine-grained PAT
- Github Apps
- deploy keys

...and all have major drawbacks.

What do you use on the servers after the webhook triggered? Using a PAT to access GH feels so incredible bad/dirty.

You don't happen to know someone at Github that we could try to annoy into some progress?

@tcurdt @hukl just an encrypted env var with a secret of our making.

I know @reconbot possibly knows the right person to bug :)

@janl @hukl @reconbot

Don't you need access to the GH package registry or GH repo from that intermediate server?

Or how do you pass on the build artefacts?

@tcurdt oh right, I had to look that up. Limited PTA for now. But yes, not a happy situation.

We could send the artifact in the we hook maybe.

@janl

Yeah, but as soon as we are talking OCI registry, sending the full image via webhook is less than ideal.

And access to the GH registry requires the classic PAT 🙄 (unless that has changed and I missed it).

So if @reconbot knows a person we could bug (or bribe, or offer help), that would be nice.

This is frustrating me for years now.