51–60 of 156 posts
I store my authorized_keys in DNS TXT records, that are DNSSEC signed, with a validating resolver on the box. I then just use "/usr/bin/hesinfo %u ssh" as my AuthorizedKeysCommand in OpenSSH. I wrote a little tool that allowed you to "#include" other DNS records etc, but "hesinfo" is generally easily installable/available so it's just easier.
I store my authorized_keys in DNS TXT records, that are DNSSEC signed, with a validating resolver on the box. I then just use "/usr/bin/hesinfo %u ssh" as my AuthorizedKeysCommand in OpenSSH. I wrote a little tool that allowed you to "#include" other DNS records etc, but "hesinfo" is generally easily installable/available so it's just easier.
I would love a HOWTO link. Also, can the DNS server be public facing? Any issues with the authorized keys being public (AFAICT there isnt but i am not a security expert)?
& as bombcar said, obviously if you ignore "unknown host" warnings, you can be tricked into logging into an attacker-controlled machine.
Often key files also contain "user@host" for the user&host the key was generated by&on. This identifier is then leaked, and you might want to avoid that. On my personal (and very objective! /s) paranoia scale this a 8/10. I'd definitely point it out to a customer during a pentest, but wouldn't really care if they "fixed" this (most of the time there is a lot of stuff that's more serious than knowing that the devops person is 'bro2000@jims-laptop').
Only downside is that at the moment it doesn't play with SELinux which is a bit unhelpful for me given I mostly use Fedora.
I store my authorized_keys in DNS TXT records, that are DNSSEC signed, with a validating resolver on the box. I then just use "/usr/bin/hesinfo %u ssh" as my AuthorizedKeysCommand in OpenSSH. I wrote a little tool that allowed you to "#include" other DNS records etc, but "hesinfo" is generally easily installable/available so it's just easier.
We looked into them once at work for our "conventional" SSH infrastructure, but immediately rammed into the wall that a certificate can sign a key, but you can't have a full PKI infrastructure like SSL where certs can sign certs that can sign keys. Without the ability to delegate, the logistics of needing to create an absolutely centralized authority to do the useful things we wanted to do within the organization rai…
If "no long-lived keys on laptops" and "central authority for who gets access to what with which credentials" aren't principles for your security practice, then you're right: there's not much of a win to switching to a CA model.
Doing this without something like Vault is very difficult. Vault is designed to provide similar guarantees to an HSM (it's a service designed to make keys usable but not exfiltratable ), and that's essential for any long-lived certificates.
https://github.com/vaporup/ssh-tools/blob/master/ssh-certinf...
What's the difference between a certificate and a public/private keys?
Certificate is short lived and signed on the fly for when you need it. The server trusts your SSH CA, and you can ask it to sign any private key you want, with a ttl. So you get extra security (credentials are dynamic and short -lived, and also per-user if needed) and lower maintenance because you only have the SSH CA public key to setup on all machines and that one needs less rotation/updates than public keys.