> 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.