Public keys being exposed isn't something I think needs to be mitigated. That's the whole point, they're public.

Security is not binary. In this case it depends on whether disclosing your identity to the servers you connect to is a problem in your threat model.

Saying "they are public so it's ok" is technical oversimplification.

It's not binary, but if your security depends on your public key being secret, something else must be wrong. It's the same as someone who depends on their IP addresses being secret. That's not something you can count on, and your security would be better served by designing your infrastructure with the assumption that it's totally public information.

> public key

The word public is just a name for a kind of key defined in the field of cryptography and doesn't necessary hold the same connotation in application protocols that use public key cryptography. One example would be ephemeral public key that would have to be kept private to be able to retain forward secrecy (although in such schemes DH is usually used).

Consider as well this situation that is closer to SSH. Suppose that you are MS dev working on NT kernel that by night also want to anonymously contribute to Linux. Obviously both camps would not like you to do that for fear of copyright infringement but OpenSSH shouldn't betray you anonymity that could be reasonably expected. It's imaginable that only one public crypto key pair would be needed to authenticate the server if password authentication is used for the client. The user doesn't expect the client software to silently generate key pair, much less that the same pair is used for every domain because the pair is not strictly needed. Although the user should inform himself how the software works a good software similarly shouldn't work in ways that are reasonably unexpected to people that are familiar with the domain. Ideally, if OpenSSH developers can't really foresee it working any other way OpenSSH should at least explicitly inform the user which public key will be used in connection before it is established in order to not assume the consent of poorly informed users.

> Saying "they are public so it's ok" is technical oversimplification.

It's not. The whole idea of the scheme is that you can publish them everywhere with no risk.

In case of Bitcoin pubkeys you don't want to publish them anywhere for privacy reasons (that turn into real physical security reasons once you have enough BTC). Also, notice how pubkeys are normally hidden under hashes and revealed only at spending time. This drastically limits attacks on ECC if/when some weakness in curve math is discovered. And if quantum computer is invented tomorrow, people can safely transition funds to a new signature scheme by introducing 2-phase commitments to safely reveal (now crackable) ECDSA pubkey after another transaction was made with commitment to concrete signature (preventing double-spend attempts using a cracked key).

OMG, people! "Public" in "public key" doesn't mean that you should share it with the whole world, it's just because it's an antonym of "private key", meaning that the other party you want to communicate with doesn't need to have a pre-shared secret key with you. Other party may be the whole world, but may be not. How public key is used is up to a protocol and threat model: it may as well be secret, and yes, in some protocols and threat models security can depend on public key being secret, and it's not wrong, and not "security by obscurity".

"Could be known to an attacker" is not the same as "Is known to an attacker". Certainly, the more determined your attacker is, the more those two converge, and thus you should treat them as indistinguishable in defender against determined attackers. But by Github publishing all users' public SSH keys, they've made the "could be known" into "known" for even casual attackers.

Well, it's not necessary (or even good) to have a Single Master Ssh Key For Everything, right? ;)

Exposing shared public keys creates an information leak; it allows attackers to probe for valid and usable username/key combinations on your servers (and thereby discover valid usernames). This may be a trivial information leak or it may be one that you consider important; it depends on the situation.

Not sharing public keys between different services and contexts (eg not using your Github keys for anything else) mitigates this risk significantly.

> Exposing shared public keys creates an information leak; it allows attackers to probe for valid and usable username/key combinations on your servers (and thereby discover valid usernames).

How? That's now how public key auth works...

> Not sharing public keys between different services and contexts (eg not using your Github keys for anything else) mitigates this risk significantly.

This is true for other reasons, and you can automate it with some shell scripts.

It's how the SSH protocol itself works. When the client connects to a server, it sends the (remote) username and then a series of public keys. If the server will accept the current public key, it asks the client to authenticate with that key to show that you hold the private key; if it doesn't, it says 'try again'.

This means that a malicious client with just the public key can probe to see if a server will accept a given username/public key combo. If the server does, it will challenge you to authenticate that you hold the private key (which you'll have to fail, since you don't have it).

> It's how the SSH protocol itself works. When the client connects to a server, it sends the (remote) username and then a series of public keys.

Well that's an ... interesting (read: stupid) design choice. I get that it reduces load on the server, but how many public keys is one user likely to have? Surely you could do something with ring signatures to make it not even require knowing which key was used?

I think if you consider leaking usernames to be an important risk, there is probably some other problem. Your username can probably be easily guessed based on your email address or first and last name anyway.

My point is you are better off designing things assuming that usernames and public keys are public information. That doesn't mean you have to go publish them on your website, but you also don't need to worry about mitigating it if someone else does.