[bshep]

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)?

[theblazehen]

There are none. In fact yours is already public: https://github.com/bshep.keys

[bombcar]

There is technically one minor one, which really isn't one - but you should be aware of.

Someone can take your authorized keys and add them to a box they control, and trick you into logging in.

However, this would trigger the "new host" warning SSH gives you, and you can minimize this by minimizing which hosts you allow your private keys to be used on.

And if someone is so actively trying to attack you they probably have more direct methods available.

[dcow]

What? How? What does putting my authorized keys file on another host do in terms of tricking me to log in? Authorized keys only matters on the host you are using when you type `ssh <some.host>`. The ssh client compares the public key of the remote host to the list in your `authorized_keys` file and, only if there is a match, skips serving you TOFU.

EDIT: I mixed up authorized_keys and known_hosts. But, the remote server doesn't need your authorized_keys file to grant you access so not sure the visibility of authorized_keys matters.

[cubesnooper]

You’re thinking of known_hosts, not authorized_keys.

[dcow]

You are right, I am. Now I understand the DNSSEC setup.

[xorcist]

Known_hosts can also be put in DNSSEC, using the SSHFP DNS record. OpenSSH understands that out of the box.

[lapser]

This wouldn't matter anyway because the server can just give you access regardless of the auth provided.

[bombcar]

I know you can restrict the methods on the client (and which keys you use) but can the client determine the host actually used it?

[dcow]

The remote host can do:

    fn authorized(peer: ClientConnection) -> bool {
      return true;
    }

[folmar]

Use `ssh -vv` and you'll see which methods are proposed and used.

[archi42]

Unless your keys are generated with low entropy (like the Debian CVE-2008-0166), publishing the public key file should not be an issue; that's from a cryptographic pov.

& 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').

[dotwaffle]

SSHFP records largely solves the host key problem, but yes, the user is the weak point in the chain there.

[encryptluks2]

A public key can be an identifier. Depending on what other information you share online or if a key is reused on GitHub it can be used to identify other places you visit and other artifacts associated with you. If your goal is anonymity then keeping you public keys secret or not attached to other personal information like a domain name is ideal. Almost all registrars are going to have a way to reveal your true identity.