HD Moore from MetaSploit has noted that, given a pubkey (and not the corresponding private key, as might be found in authorized_keys), he can determine if he'd be able to log into an account. It's a small thing, but he's using it for very interesting recon/deanonymization. He'll be releasing a paper shortly, not overplaying the characteristic, but certainly showing it can be used to do cute things. I expect this is easily fixable -- simply provide the challenge for a pubkey whether or not it'd actually be able to log in successfully. But it's worth exploring this space -- perhaps some clients behave badly. --Dan
This is a deliberate feature - it allows testing whether a pubkey can log in without the need to unwrap a private key, an action that may require a passphrase or token PIN. It's been discussed a bit here and elsewhere in the past and we've always concluded that it isn't worth turning off or providing a knob for. On Fri, 20 Jan 2012, Dan Kaminsky wrote:> HD Moore from MetaSploit has noted that, given a pubkey (and not the > corresponding private key, as might be found in authorized_keys), he can > determine if he'd be able to log into an account. > > It's a small thing, but he's using it for very interesting > recon/deanonymization. He'll be releasing a paper shortly, not overplaying > the characteristic, but certainly showing it can be used to do cute things. > > I expect this is easily fixable -- simply provide the challenge for a > pubkey whether or not it'd actually be able to log in successfully. But > it's worth exploring this space -- perhaps some clients behave badly. > > --Dan > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev >
after twelve years, i still think that always sending SSH2_MSG_USERAUTH_PK_OK for users that don't have an account is the only useful option. back then i decided against this, because it adds complexity and wastes CPU cycles. sending PK_OK for uses with an account is evil as it would force them typing the passphrase for public keys that the server does not accept at all. -m On Fri, Jan 20, 2012 at 10:18 AM, Dan Kaminsky <dan at doxpara.com> wrote:> HD Moore from MetaSploit has noted that, given a pubkey (and not the > corresponding private key, as might be found in authorized_keys), he can > determine if he'd be able to log into an account. > > It's a small thing, but he's using it for very interesting > recon/deanonymization. ?He'll be releasing a paper shortly, not overplaying > the characteristic, but certainly showing it can be used to do cute things. > > I expect this is easily fixable -- simply provide the challenge for a > pubkey whether or not it'd actually be able to log in successfully. ?But > it's worth exploring this space -- perhaps some clients behave badly. > > --Dan > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev