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