1. 20
  1.  

  2. 3

    The enumeration bit makes this seem just a little bit worrying. Meanwhile, it is really cheap to have loads and loads of ssh keys. I think these two factors make it worth using a separate SSH key for every polity you connect to. e.g. one for bitbucket, another for gitlab, another for project A’s servers, another for project B’s servers.

    1. 2

      I don’t know if this is much of a risk since the owner of a repo is typically already known by looking at the commit history.

      Perhaps if the public key is registered to an identity with more info than is displayed on a GitHub profile, it might leak some. But I can’t imagine a situation where someone signs GitHub commits and repos and doesn’t use a real name on their profile, but uses a real name for their public key.

      1. 2

        I can imagine it: people have blown their own cover in even dumber ways. ;)

        But the point remains, if you fail to consistently keep your secret identity completely separate from your other identities, whose fault is it?

        1. 2

          The thread model is a bit different.

          Attacker downloads all GitHub account -> public keys. With that in hand they can start scanning the Internet and test those keys against other hosts.

          The attack in itself doesn’t grant the the attacker access to the target hosts but it given them a bit of information that was unexpected. With that in hand they can start deciding which host looks interesting and then target the attached GitHub accounts.

        2. 2

          I don’t consider this a real risk in my book.

          1. People do a decent job of keeping the private key, private. So while someone might know that you could use a particular key, they don’t have access to it. Not very useful knowledge.
          2. Most security advice ensures you do not expose SSH to the public, or have a separate host/FQDN away from the obvious or very public hosts.

          This is useful as a bit of enumeration, but doesn’t seem that worrisome.

          1. 3

            Most security advice ensures you do not expose SSH to the public

            What would be the more secure entry point to your system? Some VPN? I consider ssh, only keyfile login allowed, no root login, to be a fairly good and secure entry point to my home network.

            1. 1

              Agreed, VPN is an encrypted tunnel, just like SSH. It’s not inherently more secure than SSH.

            2. 1
              1. Likely that few people are lucky enough to have a github/gitlab account name that matches their login id making the username effectively a salt. This could have been a problem if the comment was retained on the keys served up though.

              Enumeration can be worrying for some, similar to how you can use SSL certs to discover supersets of a group of machines you are trying to tie together and identify ownership of.

            3. 1

              Am I misreading this, or is testing this against a server predicated on guessing the relevant username, or on the attackees having attached the authorized keys to root?

              1. 1

                I think the better question is why GitHub/GitLab offer your SSH public keys to anyone that asks. Yes, this openness is the model for PGP - but you can’t do the same kind of enumeration with PGP public keys. I don’t know about the rest of you, but I don’t make my public SSH keys freely available.

                1. 1

                  The only use case I can see is an actor with great resources, like a nation state. When they show up in the middle of the night demanding your private key to a server, you can’t as easily say “I don’t have access.”