Regarding Pubkey Enumeration

[Nico Kadel-Garcia]

On Mon, Jan 23, 2012 at 8:40 AM, Aris Adamantiadis <aris at 0xbadc0de.be> wrote:
> Le 23/01/12 14:33, Nico Kadel-Garcia a écrit :

>>> 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.

Well, yes. I just wanted to encourage folks to be careful about the
idea that one is safe because "private keys cannot be bruteforced".
Robust OpenBSD and OpenSSH software security needs to be coupled with
good security practices for private key protection to be effective,
and it's startlingly rare.

>> 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.

It's useful. It becomes awkward in a large, deployed environment where
the hostnames change frequently. It's why I really like GSSAPI for
genuine single-sign-on behavior, and can use Kerberos credentials
rather than SSH key management: And in an NFS home directory
environment, I can block the use of an authorized_keys file, too, and
insist on Kerberos that can be expired and more actively managed.

Kerberized key access would in fact eliminate this alleged
vulnerability to public key testing. Its availability in OpenSSH 5 is
a very real security improvement of that package, because the keys are
no longer under the management of a local user likely to mishandle
them, or which a snooping employer could test against.