Handling access for SSH based systems #66

gapodo commented 2022年12月14日 21:14:57 +01:00

Followup to #60

Below is a direct copy from #60...

---

@gapodo in #60

While we should have one key "shared", I belive we should think about it being a "fallback" and build a mechanism to distribute keys.

Long term we should:

• Have an "ultimate" fallback key, which is well kept (and out of reach from most, potentially similar to the gpg keys)
• Have a key for automation tasks (not shared with people)
• Have a mechanism and process with which we allow new keys and distribute them
• Have a mechanism to revoke keys easily (if someone leaves)
• Document the usage of "non-user" keys (such as automation) and prepare for quickly exchanging them, if someone leaves or a machine may be compromised

For now (with only 2 of us we may run a "light" variant of it), but we should strive to achive this.

Another option may be to use ssh certificates instead of keys, since certificates can be revoked (or short lived) and limited to usernames and permissable binaries.

---

This still holds mostly true, but due to the Codeberg infrastructure requiring hardware based ssh keys, for now at least, the fallback key is not really an option (unless we start using something along the lines of the mooltipass and send key cards by snail mail and put up the database in the secrets repo)

Followup to #60 Below is a direct copy from #60... ----- [@gapodo in #60](https://codeberg.org/forgejo/meta/issues/58#issuecomment-704625) While we should have one key "shared", I belive we should think about it being a "fallback" and build a mechanism to distribute keys. Long term we should: - [ ] Have an "ultimate" fallback key, which is well kept (and out of reach from most, potentially similar to the gpg keys) - [ ] Have a key for automation tasks (not shared with people) - [ ] Have a mechanism and process with which we allow new keys and distribute them - [ ] Have a mechanism to revoke keys easily (if someone leaves) - [ ] Document the usage of "non-user" keys (such as automation) and prepare for quickly exchanging them, if someone leaves or a machine may be compromised For now (with only 2 of us we may run a "light" variant of it), but we should strive to achive this. Another option may be to use ssh certificates instead of keys, since certificates can be revoked (or short lived) and limited to usernames and permissable binaries. ----- This still holds mostly true, but due to the Codeberg infrastructure requiring hardware based ssh keys, for now at least, the fallback key is not really an option (unless we start using something along the lines of the mooltipass and send key cards by snail mail and put up the database in the secrets repo)

Ghost commented 2023年01月06日 17:04:28 +01:00

There are no SSH machines in the Forgejo infrastructure just yet. It relies on Codeberg for the CI machine. That means this issue can be closed. And re-opened, when/if Codeberg has its own machines one day.

Although it could stay open, it will cluter this issue tracker. When and if there are machines, a dedicated issue tracker for devops will need to be create anyways. And an issue create there.

Feel free to reopen if you think differently. No need to explain why, just re-open :-)

There are no SSH machines in the Forgejo infrastructure just yet. It relies on Codeberg for the CI machine. That means this issue can be closed. And re-opened, when/if Codeberg has its own machines one day. Although it could stay open, it will cluter this issue tracker. When and if there are machines, a dedicated issue tracker for devops will need to be create anyways. And an issue create there. Feel free to reopen if you think differently. No need to explain why, just re-open :-)