Self hosted SSH key repository?

Submitted ⁨⁨1⁩ ⁨year⁩ ago⁩ by ⁨chiisana@lemmy.chiisana.net⁩ to ⁨selfhosted@lemmy.world⁩

I have too many machines floating around, some virtual, some physical, and they’re getting added and removed semi-frequently as I play around with different tools/try out ideas. One recurring pain point is I have no easy way to manage SSH keys around them, and it’s a pain to deal with adding/removing/cycling keys. I know I can use AuthorizedKeysCommand on sshd_config to make the system fetch a remote key for validation, I know I could theoretically publish my pub key to github or alike, but I’m wondering if there’s something more flexible/powerful where I can manage multiple users (essentially roles) such that each machine can be assigned a role and automatically allow access accordingly?

I’ve seen Keyper before, but the container haven’t been updated for years, and the support discord owner actively kicks everyone from the server, even after asking questions.

Is there any other solution out there that would streamline this process a bit?

source

Comments

Sort:hotnew top

Max_P@lemmy.max-p.me ⁨1⁩ ⁨year⁩ ago
I would switch to certificate based SSH authentication.

All the server keys gets signed by your CA, all clients also gets signed by your CA. Everyone implicitly trust eachother though the CA and it’s as safe as regular SSH keys.

You can also sign short lived client keys if you want to make revocations easier, the servers don’t care because now all it cares is that it’s a valid cert issues by the CA, which can be done entirely offline!

HashiCorp Vault can also help managing the above, but it’s also pretty easy to do manually.

source
- mhzawadi@lemmy.horwood.cloud ⁨1⁩ ⁨year⁩ ago
  I do this, use the small step ca/Cli to manage the lot. It’s amazing
  
  source
  - Max_P@lemmy.max-p.me ⁨1⁩ ⁨year⁩ ago
    It’s such an underrated feature. It baffles me how people immediately turn to overly complicated solutions solving a problem they don’t really have to solve, just because everyone assumes the only way is the default commonly known way. Like OP, people immediately jump to the conclusion you need extra software to manage the keys, rather than using another authentication method natively supported, and keep filling their known_hosts file with junk, making the whole validation process useless because everyone just accepts whatever key the host presents.
    
    It’s amazing how simple it is. Developer needs temporary access to debug a web server? Sure, here’s your 2h valid cert to log in as the web user on the server, don’t even need to actually log into the server to put their key in and then remove it. I mint a cert and it’s ready to go on whichever users and servers I specified in the cert. Can’t even gain persistence because regular authorized_keys is disabled and we have limited session durations.
    
    I regularly leave people baffled at work because I come up with a clever and built-in super simple solution to something they expected to just slap more scripts and software to work around the only way they know to use the software. Read your manpages in full folks, it’ll save you so much work. Know what your software is capable of.
    
    source
    -> View More Comments
key@lemmy.keychat.org ⁨1⁩ ⁨year⁩ ago
You could use an LDAP and/or Kerberos solution to centralize user management. Alternatively you could use ansible

source
- kylian0087@lemmy.world ⁨1⁩ ⁨year⁩ ago
  To add to this. If everything is just linux based take a look at freeipa/rhel idm.
  
  source
yacgta@infosec.pub ⁨1⁩ ⁨year⁩ ago
I quite like Tailscale SSH for this, but I don’t have as many machines, so not sure how it will scale. You can definitely assign roles here to allow/deny SSH between hosts in your fleet though.

source
RegalPotoo@lemmy.world ⁨1⁩ ⁨year⁩ ago
You could try SSH certificates using something like smallstep.com/sso-ssh/ - essentially you delegate validation of your public key to a IDP, which your servers are configured to trust.

The other approach would be something like ansible or puppet to deploy trusted keys to all servers

source
kool_newt@lemm.ee ⁨1⁩ ⁨year⁩ ago
Are you initiating SSH connections from all these hosts?

If you just need to SSH to these hosts, use a single key and copy the public key only to the hosts you need to connect to. If you don’t want to copy the pubkeys to target hosts, use LDAP + SSSD or certificates.

Then, if you do need to initiate connections from these hosts and use an SSH agent you can forward your agent and SSH to another host

client> ssh -A host1 host1> ssh host2 host2>

client> ssh -A host1 host1> ssh -A host2 host2> ssh -A host3 host3>

source
FlexibleToast@lemmy.world ⁨1⁩ ⁨year⁩ ago
This is one of the jobs of OpenLDAP.

source
johntash@eviltoast.org ⁨1⁩ ⁨year⁩ ago
You could use ldap with OpenLdap, Keycloak, freeipa, etc to set ssh keys for users.

If you want something simpler, you could use Ansible (or another cm) or just have a startup script that downloads the authorized keys file from GitHub or wherever you can store it.

And if you want something less simple, hashicorp Vault supports dynamic ssh keys using certificates.

source
c2c2@lemmy.world ⁨1⁩ ⁨year⁩ ago
Ansible

source
vegetaaaaaaa@lemmy.world ⁨1⁩ ⁨year⁩ ago
I use ansible for that: docs.ansible.com/…/authorized_key_module.html

Keys stored alongside my playbook in a git repository.

source