Regarding Pubkey Enumeration

[Ángel González]

On 20/01/12 23:04, Damien Miller wrote:
> On Fri, 20 Jan 2012, Dan Kaminsky wrote:
>
>> HD is raiding authorized_keys files to successfully get around this 
>> limitation -- there's a reason we call them public keys. Also the 
>> very fact that public keys are only conditionally common between 
>> systems is an issue, as it's strongly deanonymizing nodes. 
> If you have popped an account, then there are myriad sources of data
> that you can use to determined linked hosts (known_hosts, lastlog, shell
> history, [uw]tmp, etc.).
>
>> It's the same UI to type in a password vs. a pass phrase, and we don't
>> bypass the former just because there's no value that could work. It's
>> odd indeed for public key security to be visibly weaker than password.
> That's because it isn't by any normal definition. The most you've shown
> is that, given a public key that is never transmitted in the clear by
> SSH, you can test hosts to find where its private half might be accepted.
> I'm struggling to see why this is interesting.
>
> -d
Isn't that public key also sent in SSH2_MSG_USERAUTH_REQUEST?

When you connect to a low-trust server, it could be enumerating the 
presented
public key identities, and then testing if any of those is accepted by a 
target server.

Suppose that there is a page critizising a technologic company, which 
suspects
it's run by one of its multiple employees. The company could test the 
server with
the public keys of their employees until it finds one that matches. Even 
if he used
a different public key, the company server could fetch keys not copied 
to it from the
user agents to find it out (this assumes the username is known and 
IdentitiesOnly
wasn't set).

On the other hand, that also allows a unificated login, where servers 
will accept a
user key if-and-only-if they would be accepted by a central server.