Regarding Pubkey Enumeration

[Aris Adamantiadis]

Le 23/01/12 14:33, Nico Kadel-Garcia a écrit :
> Hardly. Logs that are sophisticated enough, and go back far enough, to
> pin SSH traffic to a particular external host from a particular
> identifiable client are awkward to maintain. They're also unreliable
> in a DHCP based network setup, since especially for laptops that go
> home, the IP addresses are likely to change from day to day for
> employee machines and would have to be cross-correlated with the DHCP
> logs.
Ok, this may be hard.
> 
>> When you're in a pentest environment, and all you have is a public key,
>> a user name and an IP address + a hint that the three match together,
>> you're not *that* much advanced. Passwords can be bruteforced, not
>> private keys.
> 
> Many private keys are poorly passphrase protected. Since the default
> behavior of ssh-keygen allows passphrase free keys, there are one
> *hell* of a lot of people who don't bother and make the common
> assumption "if someone has access to my network, I have much bigger
> problems" and refuse to provide any passphrase protection. (I've been
> encountering that problem since the original ssh-1 was published, and
> it's particularly egregious for Subversion svn+ssh users.)
I think if you're in a situation where you're able to retrieve public
key + private key (encrypted or not), you do not need any hint from the
server anymore.
> 
> Every time I audit for passphrase free keys, I tend to catch at least
> 20% of the private keys being used without passphrase, even in NFS
> based environments. It's an ongoing problem. Even among those that are
> protected, far too many have the same password as the login password,
> which is often accessible by other means. (I just went through that
> problem with someone storing their username and password in autofs
> mounting tables for CIFS.)
Yep. But this implies that you have access to the encrypted private key,
so we're outside of the hypothesis "what you can do when you only have
the public key".
> 
>> Moreover, I find strange that nobody ever complained that openssh client
>> leaks the whole list of your available public keys to every server you
>> try to connect to, even if you don't complete authentication.
> 
> Does it? I thought it went down the list one at a time, hadn't looked
> at that chunk of the code in..... well, it's been a long time.
Indeed. It tries a public key at a time, before getting thrown out from
the server (in the times of the debian PRNG debacle, this number was 3).
> 
> Potential confusion about which key to use is why I like to use the
> 'Host" option in $HOME/.ssh/config. It lets me select a login key
> versus a Subversion svn+ssh access key, for example, for specific
> servers.
This is the proper way of managing your keys.

Aris