191–200 of 257 posts
Earlier quoted context omitted.
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...
You can dos someone just by knowing their ip or how to get a hold of them. You can also sign up magazines to be delivered to their office address and DOS their workplace. Public keys are supposed to be public.
http://rachelbythebay.com/w/2013/04/07/ssh/
Now, someone, do part two.
Earlier quoted context omitted.
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 a bit of a misleading term here. You're not actually denying them service at all. You're just tricking the service provider into potentially mis-identifying them as a different user, depending on how their SSH is configured, and it's easily solved by a small SSH config change on their end. And it only works against someone who has multiple keys anyway. > A simple solution would be to avoid the single user logi…
The article does mention it. The issue is not fixing the problem, it's actually finding it.
> [...] that URL wouldn't work for anyone else, which breaks git-submodules, breaks any kind of config file that specifies repositories (e.g. for use by a CI server)
It doesn't explain why Heroku uses it. Do you really push different submodules to Heroku?
For Github et. al, that's easily solved by project-level or organization-level identity.
> that URL wouldn't work for anyone else
And using `git@` doesn't work if you use multiple accounts because you'd specify the IdentityFile by host.
> nobody really cares because it's never going to happen accidentally
Except it does. Those service providers often get contacted because this happens BY ACCIDENT.
I've done it to myself by adding my public key to my work account. I couldn't access my personal stuff without changing my SSH config.
A while ago at work, we were using a shared key that was used to setup the initial vagrant config. New hires often added that key to their github or heroku account.
I've heard similar stories elsewhere too.
That's actually super handy. Next time I have to add someone to a shell account, I'll probably just look them up on GitHub first to find their public key instead of asking.
Security and convenience unfortunately conflict often.
Earlier quoted context omitted.
> And without a lot of work, single-factor. Wouldn't a passphrase be a second factor? By the way, we use a security fob at work for that. Seems to work fairly well. The private key never leaves the fob, you have to press a button to sign anything, and every once in a while you have to enter your passphrase.
passphrase is set/unset locally and not communicated to the server if it is present/used/etc. Could be disabled. along with various other things. HW token with ssh key inside is probably the best. The annoying thing is devices w/o USB. For iOS devices and android devices which support it it's probably better to just use the HW sec features. Something which did bt 4.0le and maybe had a single local LED and button woul…
Some new tokens use NFC.
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.…
This is a tiny tutorial I wrote ages ago:
http://retrieve.tumblr.com/post/228790418/create-ssh-key-for...
This, this is true hacking. This is so elegant. I love you Filippo. Keep being awesome!
Earlier quoted context omitted.
It's an attack on privacy expectations. There are at least two ways to escalate from here: - One if agent forwarding is enabled. - Another: learning details like people's names is often a first step in social engineering.
There's also another leak which isn't really shown here and that leak is that, with just a public key, you can offer to servers and they'll tell you if it's present or not. Using this you could scan the internet (given 6-12 hours and a shitty VPS that you can throw away this is quite possible) for someone's public key to find all of their servers, which could lead to a bypass of DDoS protection, identification of a T…
Hey, cool, someone did part one with the GitHub public keys. http://rachelbythebay.com/w/2013/04/07/ssh/ Now, someone, do part two. http://rachelbythebay.com/w/2013/07/20/ssh/