211–220 of 257 posts
"publickey: The details of this method depend on the public-key algorithm chosen. In essence, the client sends a message to the server that contains the client's public key, with the message signed by the client's private key. When the server receives this message, it checks to see whether the supplied key is acceptable for authentication and, if so, it checks to see whether the signature is correct."
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/
Wow after both of those blog posts, TWO years ago, I'm surprised github hasn't stopped exposing this identity information and us HN users haven't started being more paranoid about our ssh_configs.
Perhaps I'm missing something here.
Earlier quoted context omitted.
Is there a way to set that in bulk so all hosts in your config send identities, but those not specified don't, without putting IdentityFile for every one?
You can create a host block that matches multiple hosts: IdentitiesOnly yes Host first second third fourth IdentitiesOnly no If you then wanted to have per-host configs you'd have to create more host blocks, but at least this way the added overhead of "IdentitesOnly yes" doesn't grow too fast with the number of hosts involved.
Match Host *.example.com, 192.0.2.*
IdentitiesOnly noHey, 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/
Wow after both of those blog posts, TWO years ago, I'm surprised github hasn't stopped exposing this identity information and us HN users haven't started being more paranoid about our ssh_configs.
Earlier quoted context omitted.
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…
> and it's easily solved by a small SSH config change on their end 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 G…
I don't use Heroku, but, sure, why not? If I push a repo to Heroku that includes submodules, presumably Heroku then fetches those submodules (I'm assuming it supports submodules at all, which seems like an obvious thing to support). Therefore, those submodules must be specified by a URL that works for everyone, not just you.
> For Github et. al, that's easily solved by project-level or organization-level identity.
How does that solve anything? You're no longer identifying the user whose key is supposed to be used, which means this no longer solves your problem. And if you're going to suggest that it should only consult users who have access to the repo, for a public project that's everybody, which makes it functionally identical to git@.
> And using `git@` doesn't work if you use multiple accounts because you'd specify the IdentityFile by host.
Sure it does. IdentityFile is explicitly allowed to be specified multiple times for a single host, and the files will be tried in turn. So you can specify all your keys that way.
> Those service providers often get contacted because this happens BY ACCIDENT.
Someone uploads a private key that doesn't belong to them by accident, that screws up other innocent people? I'm rather skeptical. What's your source on this? And no, your own anecdotes do not constitute proof that providers often have to deal with this.
> 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.
Your work is handing out a shared public/private keypair and encouraging people to set this up as a default identity in SSH? That sounds awful, and it's entirely a problem you created and not even remotely the burden of GitHub or Heroku to care about.
This is clever, and very sneaky! Let's say I downloaded every public key from GitHub to ~/.ssh. Would this identify me as everyone on GitHub, or just the owner of the first public key to match? Furthermore, I wonder how Go channels compare to libevent (more specifically, epoll/queue) for high-performance network software. Is there any previous work which compares the two?
Adding those public keys would not identify you as everyone, as you do not have all the matching private keys.
> 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)
Therefore, even though I can't authenticate as Linus Torvalds, an SSH server can see me present his public key and hence, log that public key for future use, like sending a message? Is that not correct?
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.…
Exactly! Once I get the keys I just check them against a scraped database of GitHub keys and ask the API for your name. (And if you have agent forwarding active I show you a big WARNING [0].) There's an explanation in the README [1] but the actually interesting stuff is in server.go [2]. Finally I mentioned a few reasons it might not work for you below [3]. [0] http://git.io/vOVYm [1] https://github.com/FiloSottile/w…
[1] http://www.hackinglinuxexposed.com/articles/20040705.html
Earlier quoted context omitted.
The remote ssh process asks your host to unencrypt it's traffic? Your process takes an encrypted stream, sends the plaintext, and your keys never leave your machine. That's...incredibly clever, although I can only think of one scenario where it would be necessary (navigating securely through a sequence of ssh sessions where some of the secondary hosts are inaccessible from your originating host. E.g. a kind of "secur…
its very useful for so called "Bastion Hosts", an SSH server that allows further access into the network and is totally locked down.