Regarding Pubkey Enumeration

[Ángel González]

On 21/01/12 13:53, Damien Miller wrote:
> On Sat, 21 Jan 2012, ?ngel Gonz?lez wrote:
>> Isn't that public key also sent in SSH2_MSG_USERAUTH_REQUEST?
> That's the packet that contains the public key when authenticating or
> testing whether a key has a chance of being accepted.
I'll take that as a 'yes'.

>> 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.
> First, this attack would work without public key confirmation. Your client
> would still need to try every key that it knows about to connect, and your
> compromised server would have the same opportunity to collect them.
Learning the user public keys would be useless to find out the (potential)
relationship with the server if the target server didn't acknowledge 
that a key
was acceptable without a challenge signed with the private key.


> The most that turning off key compromisation might buy you in this situation
> is to provide a little more pressure on users who need to enter PINs or
> use key confirmation ("ssh-add -c") to explicitly configure which keys
> are used by annoying them with more PIN/confirm dialogs.
Good point. If it was to be removed, I think it'd have to be replaced with
providing a truncated hash of the public key, which a length such that it
would be unlikely for a single user to own several colliding keys, but 
still
likely when checking keys stolen from many users.


> You can already limit which identities are used in public key authentication
> by setting IdentityFile(s) for a particular host. If you don't like the idea
> of keys in your agent being sprayed around, then the mechanism already exists
> to avoid it.
Indeed, it requires to repeat the settings several times (you can only 
match by
Host) but the ability is already there.


>> 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).
> If the company has access to the user's ssh-agent then it is game
> over anyway - they have the private keys.
>
> -d
The scenary was that the company had access to the server, but not to the
private key or the agent, which would be eg. in a laptop owned by the 
employee.