backdoor by authorized_keys2 leftovers

Damien Miller djm at mindrot.org
Fri May 20 11:19:29 EST 2011


On Fri, 20 May 2011, Darren Tucker wrote:

> On 16/05/11 1:14 PM, Damien Miller wrote:
> > On Mon, 16 May 2011, Damien Miller wrote:
> [...]
> > > AuthorizedKeysFile .ssh/authorized_keys
> > > AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2
> > > AuthorizedKeysFile /etc/ssh/authorized_keys/keys_%u .ssh/authorized_keys
> > > 
> > > So maybe all-keys-on-one-line is better.
> > 
> > Here's a diff that implements this:
> 
> Diff looks mostly OK, however I suggest the following:
>  - all-one-line as mentioned earlier

done

>  - continue to accept authorized_keys2 in sshd_config and stash in serveropts.
>  - when the config file parsing is done, if it's set append the value of
> authorized_keys2 to the authorized_keys_files array.  This should be
> equivalent to the current behaviour (maybe log a deprecation warning or
> something).

I disagree here:

I accept the argument against changing the silently-working behaviour
of looking for .ssh/authorized_keys2, but I think we should just
deprecate the AuthorizedKeysFile2 option. It hasn't been documented for
(10?) years and has been broken wrt Match blocks.

By deprecating AuthorizedKeysFile2, server admins would get a clear
warning on server start and restart and have a simple path to achieve
the same result (multiple AuthorizedKeysFile).

This wasn't the case with actually looking for authorized_keys2 files -
there the faliure was completely silent.

>  - explicitly set AuthorizedKeysFile in the shipped sshd_config without
> authorized_keys2 (similar to the Protocol 1 deprecation).

Yes - new installations shouldn't look for authorized_keys2 files.
We can remove looking for them by default completely some time in 2015 :)

-d


More information about the openssh-unix-dev mailing list