91–100 of 257 posts
FYI, this happens because SSH automatically presents a public key to the server when trying to authenticate. If the server doesn't know that key, then SSH tries the next one. You can enumerate all of someone's keys this way (like this SSH server does) If you want to disable this sort of behaviour you can disable SSH from sending keys automatically, and then tell SSH which identity files need to be sent to each host.…
FYI, this happens because SSH automatically presents a public key to the server when trying to authenticate. If the server doesn't know that key, then SSH tries the next one. You can enumerate all of someone's keys this way (like this SSH server does) If you want to disable this sort of behaviour you can disable SSH from sending keys automatically, and then tell SSH which identity files need to be sent to each host.…
Right now, cloud-init accepts a list of GitHub usernames that should be allowed to log into the machine (which is pretty clever in-and-of-itself), and then creates users for them and sets their authorized_keys to whatever values the GitHub public-SSH-key API returns.
But, rather than "burning in" a set of allowed users, you could do something much more interesting: allow any key to authenticate, and then map it back to a user and find out if that user has write-access to the GitHub project!
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…
Same 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 the…
FYI, this happens because SSH automatically presents a public key to the server when trying to authenticate. If the server doesn't know that key, then SSH tries the next one. You can enumerate all of someone's keys this way (like this SSH server does) If you want to disable this sort of behaviour you can disable SSH from sending keys automatically, and then tell SSH which identity files need to be sent to each host.…
Earlier quoted context omitted.
> By the way, did you know that GitHub publishes all users' ssh public keys and Ben (benjojo.co.uk) grabbed them all? > That's pretty handy at times :) But not this time :( >Better luck next time, I guess :) Who cares if they publish Public Keys. They're meant to be public, it's one of the few well named things in computer science. They are basically meant to be spewn everywhere.
You may be interested in knowing that you can DOS someone if you know only their public keys. https://medium.com/@gmalette/mistaking-authentication-for-id...
DOS is the one attack one can not defend against, only attenuate.
Earlier quoted context omitted.
It's a public key for a reason. You need to the private key to authenticate, so you're safe having everyone know your public key.
It's fairly pointless of github to publish your public key though. Nobody can trust that it's actually yours.
If it enables security research it's already a win in my eyes.
Might expose classes of weak keys in the future for example.
SSH keys are actually pretty horrible from a security perspective; no expiration, generally held in software, etc. And without a lot of work, single-factor. I love the ssh security model of being pretty good and better than telnet for everything (which it ~fully displaced, unlike https vs. http), but client keys are one of the weak points.
A great reminder that public key identity management is quite the unsolved annoyance. Why should you use the same key everywhere, allowing others to track you? Ideally you would have one key per service.
And all of my machines are named "host", with user "user" :)