5 ms·

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 securi

• theblazehen 4y ago
  There are none. In fact yours is already public: https://github.com/bshep.keys https://github.com/bshep.keys
  • bombcar 4y ago
    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 4y ago
      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 4y ago
        You’re thinking of known_hosts, not authorized_keys.
        • dcow 4y ago
          You are right, I am. Now I understand the DNSSEC setup.
          • xorcist 4y ago
            Known_hosts can also be put in DNSSEC, using the SSHFP DNS record. OpenSSH understands that out of the box.
    • lapser 4y ago
      This wouldn't matter anyway because the server can just give you access regardless of the auth provided.
      • bombcar 4y ago
        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 4y ago
          The remote host can do: fn authorized(peer: ClientConnection) -> bool { return true; }
        • folmar 4y ago
          Use `ssh -vv` and you'll see which methods are proposed and used.
• archi42 4y ago
  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 4y ago
    SSHFP records largely solves the host key problem, but yes, the user is the weak point in the chain there.
• encryptluks2 4y ago
  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.