3 ms·
Didn't work for me, not because I don't have a Github key, but because I use separate keys for everything, and don't have a default key (requires plenty of ~/.s
by _wmd 11y ago
Didn't work for me, not because I don't have a Github key, but because I use separate keys for everything, and don't have a default key (requires plenty of ~/.ssh/config muckery).
I had been doing this because I'm paranoid, and because I have a tendency to copy keys for my colo boxes to work computers, and my Git keys to the colo boxes. Now I have a new reason -- public keys basically act like a giant supercookie for SSH.
- toxicFork 11y agoSame here. Here's my ~/.ssh/config for anyone interested in what it looks like: Host github.com User toxicFork IdentityFile ~/.ssh/github-toxicFork Host bitbucket.org User toxicFork IdentityFile ~/.ssh/bitbucket-toxicFork And my personal security policy: - Once I want to use a device for development, I create separate key pairs for all of the services I want to use, register it on that server's account config and then add it to my config file by hand ( I should find or write a script to do these automatically :D ) - Once I want to retire a device (or if it gets lost) I just remove the public keys from the services - NEVER move or copy private keys, I'd rather create a new private key and remove the references for the old public keys instead
- ultramancool 11y agoGood policies, the mere presence of an id_<ciphername> key in .ssh means you can be identified between multiple ssh servers. I identified this in the OpenSSH source a while ago and posted it on reddit at one point, but few people understood. Glad someone made a practical attack out of it now. IP correlation may seem a more obvious attack, but such an attack could be used to identify for example, someone running a darknet operation or using VPNs for privacy or simply to tie an IP to a name using a public key service like in this example.