Is there any danger to adding keys to the Github account that are used elsewhere?
Depends on the type and number of bits in the key.
If you create an ssh key that is already broken (say you managed to generate a... 512 byte RSA key), then an attacker would know what key he needs to generate before he attempts to authenticate with your server (or github).
But in practice public keys are meant to be public... very public. Like GPG keys! Here's a debian signing key https://ftp-master.debian.org/keys/archive-key-7.0.asc .
We can even verify that it's an RSA key with 4096... exactly what you could (should?) use to generate SSH keys. Effectively posting your public ssh key in the wild is as safe as debian posting their public signing key :)
``` pub rsa4096/0x8B48AD6246925553 2012-04-27 [SC] [expires: 2020-04-25] Key fingerprint = A1BD 8E9D 78F7 FE5C 3E65 D8AF 8B48 AD62 4692 5553 uid [ unknown] Debian Archive Automatic Signing Key (7.0/wheezy) <ftpmaster@debian.org> sub rsa4096/0x85215E51ADD6B7E2 2012-04-27 [E] [revoked: 2014-03-17] ```
I dislike that Github doesn't explicitly mention that it publishes your public keys, because they can be used to figure out your identity across multiple services. I believe someone a while back posted a demo on HN, where you could SSH in and it would greet you with "hello $yourname", which it derived from your github keys.
My advice: if you use different (user)names for different services, you should probably consider using different SSH keys for them as well. That is, if you don't want those two identities to be tied together.
The main problem that Fhilippo pointed out with the service is that ssh by default gives all keys present inn your keyring, or all keys named id_{rsa,dsa,ecdsa}. What should be done is to never present ALL your keys, but turn on "IdentitiesOnly yes" in your SSH config.