Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: OpenSSH: Dev

backdoor by authorized_keys2 leftovers

 

 

First page Previous page 1 2 Next page Last page  View All OpenSSH dev RSS feed   Index | Next | Previous | View Threaded


list2rado at gmx

May 9, 2011, 7:21 AM

Post #1 of 33 (2751 views)
Permalink
backdoor by authorized_keys2 leftovers

Hi devs,

recently I had to replace authorized_keys on several systems to
enforce an access policy change.
I was badly surprised that authorized_keys2(!) was still processed,
which allowed some old keys to enter the systems again, because I
wasn't aware of the file's existance on the server and use by sshd,
since this "backward compatibility" isn't documented, not even a
historical reference about "obsolete" or "deprecated".

Maybe it's time to drop the old stuff not to get haunted by such
leftovers again.

Thanks, regards,
Rado

--
© Rado S. -- You must provide YOUR effort for your goal!
EVERY effort counts: at least to show your attitude.
You're responsible for ALL you do: you get what you give.


djm at mindrot

May 10, 2011, 9:47 PM

Post #2 of 33 (2684 views)
Permalink
Re: backdoor by authorized_keys2 leftovers [In reply to]

On Mon, 9 May 2011, Rado S wrote:

> Hi devs,
>
> recently I had to replace authorized_keys on several systems to
> enforce an access policy change.
> I was badly surprised that authorized_keys2(!) was still processed,
> which allowed some old keys to enter the systems again, because I
> wasn't aware of the file's existance on the server and use by sshd,
> since this "backward compatibility" isn't documented, not even a
> historical reference about "obsolete" or "deprecated".
>
> Maybe it's time to drop the old stuff not to get haunted by such
> leftovers again.

Good point - I just committed a change to remove it for openssh-5.9

-d
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


dan at doxpara

May 10, 2011, 11:01 PM

Post #3 of 33 (2683 views)
Permalink
Re: backdoor by authorized_keys2 leftovers [In reply to]

Sent from my iPhone

On May 10, 2011, at 9:47 PM, Damien Miller <djm [at] mindrot> wrote:

> On Mon, 9 May 2011, Rado S wrote:
>
>> Hi devs,
>>
>> recently I had to replace authorized_keys on several systems to
>> enforce an access policy change.
>> I was badly surprised that authorized_keys2(!) was still processed,
>> which allowed some old keys to enter the systems again, because I
>> wasn't aware of the file's existance on the server and use by sshd,
>> since this "backward compatibility" isn't documented, not even a
>> historical reference about "obsolete" or "deprecated".
>>
>> Maybe it's time to drop the old stuff not to get haunted by such
>> leftovers again.
>
> Good point - I just committed a change to remove it for openssh-5.9
>

I'd document, rather than remove. I think all my systems use authorized_keys2. You will end up locking users and admins out.

> -d
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev [at] mindrot
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


jrollins at finestructure

May 10, 2011, 11:23 PM

Post #4 of 33 (2679 views)
Permalink
Re: backdoor by authorized_keys2 leftovers [In reply to]

On Tue, 10 May 2011 23:01:14 -0700, Dan Kaminsky <dan [at] doxpara> wrote:
> I'd document, rather than remove. I think all my systems use
> authorized_keys2. You will end up locking users and admins out.

I definitely agree with this sentiment.

I also think that being able to specify multiple authorized_keys files
is very useful, so I would prefer to just see this as a documented
feature.

jamie.


efo at basefarm

May 10, 2011, 11:42 PM

Post #5 of 33 (2699 views)
Permalink
Re: backdoor by authorized_keys2 leftovers [In reply to]

On 11. mai 2011 08:23, Jameson Graef Rollins wrote:
> On Tue, 10 May 2011 23:01:14 -0700, Dan Kaminsky<dan [at] doxpara> wrote:
>> I'd document, rather than remove. I think all my systems use
>> authorized_keys2. You will end up locking users and admins out.
> I definitely agree with this sentiment.
>
> I also think that being able to specify multiple authorized_keys files
> is very useful, so I would prefer to just see this as a documented
> feature.
>
> jamie.
I say either remove it, or make it a configuration option to disable it.
Where authorized_keys are controlled by the AuthorizedKeysFile option,
authorized_keys2 are not, which makes our distribution regimes a bit
troublesome as we will have to make use of /etc/ssh/sshrc to
delete/die/remove/something if %h/.ssh/authorized_keys2 is found.

--
BR
Espen Fjellvćr Olsen
Basefarm AS


_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


djm at mindrot

May 11, 2011, 1:44 AM

Post #6 of 33 (2680 views)
Permalink
Re: backdoor by authorized_keys2 leftovers [In reply to]

On Tue, 10 May 2011, Dan Kaminsky wrote:

> >> Maybe it's time to drop the old stuff not to get haunted by such
> >> leftovers again.
> >
> > Good point - I just committed a change to remove it for openssh-5.9
> >
>
> I'd document, rather than remove. I think all my systems use
> authorized_keys2. You will end up locking users and admins out.

We'll document the removal :) Really, there is no reason to have two
files that do exactly the same thing.

-d
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


philipp.marek at linbit

May 11, 2011, 1:52 AM

Post #7 of 33 (2678 views)
Permalink
Re: backdoor by authorized_keys2 leftovers [In reply to]

On Wednesday 11 May 2011, Damien Miller wrote:
> On Tue, 10 May 2011, Dan Kaminsky wrote:
> > >> Maybe it's time to drop the old stuff not to get haunted by such
> > >> leftovers again.
> > >
> > > Good point - I just committed a change to remove it for openssh-5.9
> >
> > I'd document, rather than remove. I think all my systems use
> > authorized_keys2. You will end up locking users and admins out.
>
> We'll document the removal :) Really, there is no reason to have two
> files that do exactly the same thing.
Well, there is a very good reason - easier configurability.

Having one file for the "static" admins, and one for the per-server
(application) executives is nice, IMO.


There are lots of places where instead of a file a directory is used - the
famous /etc/rc*.d/, /etc/cron.d, etc. etc.

Perhaps this should be an alternative - either have ~/.ssh/authorized_keys a
file, or a directory, but not both?


Regards,

Phil
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


jrollins at finestructure

May 11, 2011, 2:58 AM

Post #8 of 33 (2676 views)
Permalink
Re: backdoor by authorized_keys2 leftovers [In reply to]

On Wed, 11 May 2011 18:44:59 +1000 (EST), Damien Miller <djm [at] mindrot> wrote:
> > I'd document, rather than remove. I think all my systems use
> > authorized_keys2. You will end up locking users and admins out.
>
> We'll document the removal :) Really, there is no reason to have two
> files that do exactly the same thing.

Actually, there are a lot of reasons to have multiple authorized_keys
files. One user controlled and one admin controlled is just the first
thing that pops in to my head. I'm sure we can think of lots of other
reasons as well.

jamie.


djm at mindrot

May 11, 2011, 4:48 AM

Post #9 of 33 (2678 views)
Permalink
Re: backdoor by authorized_keys2 leftovers [In reply to]

On Tue, 10 May 2011, Jameson Graef Rollins wrote:

> On Tue, 10 May 2011 23:01:14 -0700, Dan Kaminsky <dan [at] doxpara> wrote:
> > I'd document, rather than remove. I think all my systems use
> > authorized_keys2. You will end up locking users and admins out.
>
> I definitely agree with this sentiment.
>
> I also think that being able to specify multiple authorized_keys files
> is very useful, so I would prefer to just see this as a documented
> feature.

Perhaps we should make options.authorized_keys_file an array to let
people who want to use multiple files do so.

-d
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


dkg at fifthhorseman

May 11, 2011, 7:44 AM

Post #10 of 33 (2675 views)
Permalink
Re: backdoor by authorized_keys2 leftovers [In reply to]

On 05/11/2011 07:48 AM, Damien Miller wrote:
> Perhaps we should make options.authorized_keys_file an array to let
> people who want to use multiple files do so.

There are at least two bugzilla issues open about this:

https://bugzilla.mindrot.org/show_bug.cgi?id=172
https://bugzilla.mindrot.org/show_bug.cgi?id=1684

Either way, the current arrangement is pretty counter-intuitive, so i'm
glad something is being done to resolve it.

In the current setup, IIRC, if AuthorizedKeysFile is not set, then both
~/.authorized_keys and ~/.authorized_keys2 are parsed. But if
AuthorizedKeysFile *is* set, then that and only that is parsed (no
~/.authorized_keys2). This is confusing/surprising no matter which
direction you're coming from.

Thanks for addressing the issue,

--dkg
Attachments: signature.asc (1.01 KB)


imorgan at nas

May 11, 2011, 9:50 AM

Post #11 of 33 (2671 views)
Permalink
Re: backdoor by authorized_keys2 leftovers [In reply to]

On Wed, May 11, 2011 at 06:48:38 -0500, Damien Miller wrote:
> On Tue, 10 May 2011, Jameson Graef Rollins wrote:
>
> > On Tue, 10 May 2011 23:01:14 -0700, Dan Kaminsky <dan [at] doxpara> wrote:
> > > I'd document, rather than remove. I think all my systems use
> > > authorized_keys2. You will end up locking users and admins out.
> >
> > I definitely agree with this sentiment.
> >
> > I also think that being able to specify multiple authorized_keys files
> > is very useful, so I would prefer to just see this as a documented
> > feature.
>
> Perhaps we should make options.authorized_keys_file an array to let
> people who want to use multiple files do so.
>
> -d
>

I was going to suggest something similar, but you beat me to it. :-)

One scenario that could potentially be useful in a cluster environment
would be to allow per-host authorized_keys files. Support for the
following syntax might be useful:

AuthorizedKeysFile %h/.ssh/authorized_keys.%H,%h/.ssh/authorized_keys

where '%H' would be expanded as the server's hostname. (I don't
particulary like '%H', but '%h' is already used.)

This would allow clusters which use a shared home filesystem to have
authorized_keys files which are tailored for a specific host and the
capability to fall back to a more generic file in the absence of a
host-specific one.

By the way, I applaud getting rid of the old cruft.

--
Iain Morgan
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


keisial at gmail

May 11, 2011, 10:21 AM

Post #12 of 33 (2671 views)
Permalink
Re: backdoor by authorized_keys2 leftovers [In reply to]

Iain Morgan wrote:
> I was going to suggest something similar, but you beat me to it. :-)
>
> One scenario that could potentially be useful in a cluster environment
> would be to allow per-host authorized_keys files. Support for the
> following syntax might be useful:
>
> AuthorizedKeysFile %h/.ssh/authorized_keys.%H,%h/.ssh/authorized_keys
>
> where '%H' would be expanded as the server's hostname. (I don't
> particulary like '%H', but '%h' is already used.)
>
> This would allow clusters which use a shared home filesystem to have
> authorized_keys files which are tailored for a specific host and the
> capability to fall back to a more generic file in the absence of a
> host-specific one.
>
> By the way, I applaud getting rid of the old cruft.
To fall back? As I understood it, they would be additive.

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


imorgan at nas

May 11, 2011, 11:20 AM

Post #13 of 33 (2663 views)
Permalink
Re: backdoor by authorized_keys2 leftovers [In reply to]

On Wed, May 11, 2011 at 12:24:16 -0500, Ángel González wrote:
> Iain Morgan wrote:
> > I was going to suggest something similar, but you beat me to it. :-)
> >
> > One scenario that could potentially be useful in a cluster environment
> > would be to allow per-host authorized_keys files. Support for the
> > following syntax might be useful:
> >
> > AuthorizedKeysFile %h/.ssh/authorized_keys.%H,%h/.ssh/authorized_keys
> >
> > where '%H' would be expanded as the server's hostname. (I don't
> > particulary like '%H', but '%h' is already used.)
> >
> > This would allow clusters which use a shared home filesystem to have
> > authorized_keys files which are tailored for a specific host and the
> > capability to fall back to a more generic file in the absence of a
> > host-specific one.
> >
> > By the way, I applaud getting rid of the old cruft.
> To fall back? As I understood it, they would be additive.
>

By "fall back," I didn't necessarily mean "stop at the first file," but
there might be some scenarios where that behaviour is desirable.
However, most of the discussion on this list has been with the
expectation that all files would be examined.

--
Iain Morgan
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


mfriedl at gmail

May 12, 2011, 11:49 AM

Post #14 of 33 (2649 views)
Permalink
Re: backdoor by authorized_keys2 leftovers [In reply to]

looks like we've been waiting too long :)

http://www.openssh.com/txt/release-3.0

2) The files
/etc/ssh_known_hosts2
~/.ssh/known_hosts2
~/.ssh/authorized_keys2
are now obsolete, you can use
/etc/ssh_known_hosts
~/.ssh/known_hosts
~/.ssh/authorized_keys
For backward compatibility ~/.ssh/authorized_keys2 will still used for
authentication and hostkeys are still read from the known_hosts2.
However, those deprecated files are considered 'readonly'. Future
releases are likely not to read these files.

On Mittwoch, 11. Mai 2011 at 08:01, Dan Kaminsky wrote:
>
>
> Sent from my iPhone
>
> On May 10, 2011, at 9:47 PM, Damien Miller <djm [at] mindrot> wrote:
>
> > On Mon, 9 May 2011, Rado S wrote:
> >
> > > Hi devs,
> > >
> > > recently I had to replace authorized_keys on several systems to
> > > enforce an access policy change.
> > > I was badly surprised that authorized_keys2(!) was still processed,
> > > which allowed some old keys to enter the systems again, because I
> > > wasn't aware of the file's existance on the server and use by sshd,
> > > since this "backward compatibility" isn't documented, not even a
> > > historical reference about "obsolete" or "deprecated".
> > >
> > > Maybe it's time to drop the old stuff not to get haunted by such
> > > leftovers again.
> >
> > Good point - I just committed a change to remove it for openssh-5.9
>
> I'd document, rather than remove. I think all my systems use authorized_keys2. You will end up locking users and admins out.
>
> > -d
> > _______________________________________________
> > openssh-unix-dev mailing list
> > openssh-unix-dev [at] mindrot
> > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev [at] mindrot
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


dan at doxpara

May 12, 2011, 12:14 PM

Post #15 of 33 (2654 views)
Permalink
Re: backdoor by authorized_keys2 leftovers [In reply to]

On Thu, May 12, 2011 at 11:49 AM, Markus Friedl <mfriedl [at] gmail> wrote:

> looks like we've been waiting too long :)
>
> http://www.openssh.com/txt/release-3.0
>
> 2) The files
> /etc/ssh_known_hosts2
> ~/.ssh/known_hosts2
> ~/.ssh/authorized_keys2
> are now obsolete, you can use
> /etc/ssh_known_hosts
> ~/.ssh/known_hosts
> ~/.ssh/authorized_keys
> For backward compatibility ~/.ssh/authorized_keys2 will still used for
> authentication and hostkeys are still read from the known_hosts2.
> However, those deprecated files are considered 'readonly'. Future
> releases are likely not to read these files.
>

In no uncertain terms, removal of authorized_keys2 support will cause
outages, up to and including requiring physical access for administrators to
resolve. Documentation is not an excuse to make this change.

It's completely reasonable, desirable even, to allow a new configuration
option to explicitly define the set of files that can contain authorized
keys. It'd even be convenient to have an AuthorizationCommand option, that
sent properly escaped strings to a command for external testing and
validation.


>
> On Mittwoch, 11. Mai 2011 at 08:01, Dan Kaminsky wrote:
> >
> >
> > Sent from my iPhone
> >
> > On May 10, 2011, at 9:47 PM, Damien Miller <djm [at] mindrot> wrote:
> >
> > > On Mon, 9 May 2011, Rado S wrote:
> > >
> > > > Hi devs,
> > > >
> > > > recently I had to replace authorized_keys on several systems to
> > > > enforce an access policy change.
> > > > I was badly surprised that authorized_keys2(!) was still processed,
> > > > which allowed some old keys to enter the systems again, because I
> > > > wasn't aware of the file's existance on the server and use by sshd,
> > > > since this "backward compatibility" isn't documented, not even a
> > > > historical reference about "obsolete" or "deprecated".
> > > >
> > > > Maybe it's time to drop the old stuff not to get haunted by such
> > > > leftovers again.
> > >
> > > Good point - I just committed a change to remove it for openssh-5.9
> >
> > I'd document, rather than remove. I think all my systems use
> authorized_keys2. You will end up locking users and admins out.
> >
> > > -d
> > > _______________________________________________
> > > openssh-unix-dev mailing list
> > > openssh-unix-dev [at] mindrot
> > > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
> > _______________________________________________
> > openssh-unix-dev mailing list
> > openssh-unix-dev [at] mindrot
> > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
> >
>
>
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


dkg at fifthhorseman

May 12, 2011, 12:26 PM

Post #16 of 33 (2647 views)
Permalink
Re: backdoor by authorized_keys2 leftovers [In reply to]

On 05/12/2011 03:14 PM, Dan Kaminsky wrote:
> It's completely reasonable, desirable even, to allow a new configuration
> option to explicitly define the set of files that can contain authorized
> keys.

This doesn't need to be a "new configuration option", since it's what
AuthorizedKeysFile does right now. I think if you define an
AuthorizedKeysFile, then ~/.ssh/authorized_keys2 is no longer checked.

The proposal to make AuthorizedKeysFile an array would allow for saying
"the default is ~/.ssh/authorized_keys,~/.ssh/authorized_keys2" if we
wanted to permanently enshrine the current behavior and keep a simple
explanation.

> It'd even be convenient to have an AuthorizationCommand option, that
> sent properly escaped strings to a command for external testing and
> validation.

There is an outstanding proposal for AuthorizedKeysCommand which works
slightly differently:

https://bugzilla.mindrot.org/show_bug.cgi?id=1663

The command itself just produces the equivalent of an AuthorizedKeysFile
on stdout, which is read by sshd in the same way that it currently reads
the AuthorizedKeysFile.

An alternate implementation (e.g. one that feeds the submitted key
(properly escaped) to the command and checks the return value) would be
a welcome contribution.

Regards,

--dkg
Attachments: signature.asc (1.01 KB)


imorgan at nas

May 12, 2011, 3:47 PM

Post #17 of 33 (2657 views)
Permalink
Re: backdoor by authorized_keys2 leftovers [In reply to]

On Thu, May 12, 2011 at 14:14:02 -0500, Dan Kaminsky wrote:
> On Thu, May 12, 2011 at 11:49 AM, Markus Friedl <mfriedl [at] gmail> wrote:
>
> > looks like we've been waiting too long :)
> >
> > http://www.openssh.com/txt/release-3.0
> >
> > 2) The files
> > /etc/ssh_known_hosts2
> > ~/.ssh/known_hosts2
> > ~/.ssh/authorized_keys2
> > are now obsolete, you can use
> > /etc/ssh_known_hosts
> > ~/.ssh/known_hosts
> > ~/.ssh/authorized_keys
> > For backward compatibility ~/.ssh/authorized_keys2 will still used for
> > authentication and hostkeys are still read from the known_hosts2.
> > However, those deprecated files are considered 'readonly'. Future
> > releases are likely not to read these files.
> >
>
> In no uncertain terms, removal of authorized_keys2 support will cause
> outages, up to and including requiring physical access for administrators to
> resolve. Documentation is not an excuse to make this change.
>
> It's completely reasonable, desirable even, to allow a new configuration
> option to explicitly define the set of files that can contain authorized
> keys. It'd even be convenient to have an AuthorizationCommand option, that
> sent properly escaped strings to a command for external testing and
> validation.
>
Provided that sysadmins are aware of the change ahead of time, proactive
measures can easily be taken. On a per-system basis, it's obviously a
simple matter to find and rename such deprecated files. However, we can
expect that some will be caught off guard.

In hindsight, what probably should have been done is have sshd return a
warning to the client about the deprecated file after successful login.
And, for good measure, an appropriate message should be logged on the
server, if that's not already the case.

Given that support for authorized_keys2 hasn't been documented for a
number of years, I have to wonder just how widespread its use is.

--
Iain morgan
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


dan at doxpara

May 12, 2011, 6:49 PM

Post #18 of 33 (2642 views)
Permalink
Re: backdoor by authorized_keys2 leftovers [In reply to]

Sent from my iPhone

On May 12, 2011, at 6:47 PM, Iain Morgan <imorgan [at] nas> wrote:

> On Thu, May 12, 2011 at 14:14:02 -0500, Dan Kaminsky wrote:
>> On Thu, May 12, 2011 at 11:49 AM, Markus Friedl <mfriedl [at] gmail> wrote:
>>
>>> looks like we've been waiting too long :)
>>>
>>> http://www.openssh.com/txt/release-3.0
>>>
>>> 2) The files
>>> /etc/ssh_known_hosts2
>>> ~/.ssh/known_hosts2
>>> ~/.ssh/authorized_keys2
>>> are now obsolete, you can use
>>> /etc/ssh_known_hosts
>>> ~/.ssh/known_hosts
>>> ~/.ssh/authorized_keys
>>> For backward compatibility ~/.ssh/authorized_keys2 will still used for
>>> authentication and hostkeys are still read from the known_hosts2.
>>> However, those deprecated files are considered 'readonly'. Future
>>> releases are likely not to read these files.
>>>
>>
>> In no uncertain terms, removal of authorized_keys2 support will cause
>> outages, up to and including requiring physical access for administrators to
>> resolve. Documentation is not an excuse to make this change.
>>
>> It's completely reasonable, desirable even, to allow a new configuration
>> option to explicitly define the set of files that can contain authorized
>> keys. It'd even be convenient to have an AuthorizationCommand option, that
>> sent properly escaped strings to a command for external testing and
>> validation.
>>
> Provided that sysadmins are aware of the change ahead of time, proactive
> measures can easily be taken. On a per-system basis, it's obviously a
> simple matter to find and rename such deprecated files. However, we can
> expect that some will be caught off guard.
>
> In hindsight, what probably should have been done is have sshd return a
> warning to the client about the deprecated file after successful login.
> And, for good measure, an appropriate message should be logged on the
> server, if that's not already the case.
>
> Given that support for authorized_keys2 hasn't been documented for a
> number of years, I have to wonder just how widespread its use is.
>

Doesn't matter. A failure here locks the admin out of the server, requiring up to and including physical recovery.

A vaguely nice security change cannot justify extensive notification and lockout risk. And we're not really in the position to collect data saying the risk is small enough.


> --
> Iain morgan
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


phil at hands

May 13, 2011, 5:03 AM

Post #19 of 33 (2662 views)
Permalink
Re: backdoor by authorized_keys2 leftovers [In reply to]

On Thu, 12 May 2011 21:49:13 -0400, Dan Kaminsky <dan [at] doxpara> wrote:
...
> > Provided that sysadmins are aware of the change ahead of time, proactive
> > measures can easily be taken. On a per-system basis, it's obviously a
> > simple matter to find and rename such deprecated files. However, we can
> > expect that some will be caught off guard.
> >
> > In hindsight, what probably should have been done is have sshd return a
> > warning to the client about the deprecated file after successful login.
> > And, for good measure, an appropriate message should be logged on the
> > server, if that's not already the case.
> >
> > Given that support for authorized_keys2 hasn't been documented for a
> > number of years, I have to wonder just how widespread its use is.
> >
>
> Doesn't matter. A failure here locks the admin out of the server,
> requiring up to and including physical recovery.

How about if for the first release:

if AuthorizedKeysFile is set, then that's fine, we're not defaulting to
using the authorized_keys2 file anyway

if it is not set, and authorized_keys2 file(s) exist on the system,
put up a warning if it's an interactive login, log a warning, and
pause for 20 seconds before then allowing the login.

That should get people's attention.

To be certain that you're going to alert the sysadmins, you'd want to
check for any authorized_keys2 anywhere, but that's a bit cumbersome.

Perhaps it would be OK to only do it when one were using the keys out of
an authorized_keys2, although there is some danger that only automated
logins would be affected, and the delay and logs would go unnoticed.

Perhaps one could set a flag when an authorized_keys2 file had been
found at some point during the lifetime of the sshd, and change the
behaviour for all subsequent logins.

Leave that behaviour in place for a release or two, then just drop the
default use of authorized_keys2. If anyone then gets caught out,
they've really not been paying attention.

If the above seems like too much effort (which it probably is), just put
it in the release notes, and suggest that people who package ssh make
sure that the user is alerted to the change (if AuthorizedKeysFile is unset).

Anyone who upgrades ssh remotely without testing that they can still log
in before they log out, is a dimwit. That said, I've been that dimwit ;-)

Cheers, Phil.
--
|)| Philip Hands [+44 (0)20 8530 9560] http://www.hands.com/
|-| HANDS.COM Ltd. http://www.uk.debian.org/
|(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND


djm at mindrot

May 14, 2011, 4:02 AM

Post #20 of 33 (2614 views)
Permalink
Re: backdoor by authorized_keys2 leftovers [In reply to]

On Wed, 11 May 2011, Damien Miller wrote:

> > I also think that being able to specify multiple authorized_keys files
> > is very useful, so I would prefer to just see this as a documented
> > feature.
>
> Perhaps we should make options.authorized_keys_file an array to let
> people who want to use multiple files do so.

Here's a lightly-tested patch against -current (OpenBSD version, it
will probably need some editing for portable)

Index: auth.c
===================================================================
RCS file: /cvs/src/usr.bin/ssh/auth.c,v
retrieving revision 1.91
diff -u -p -r1.91 auth.c
--- auth.c 29 Nov 2010 23:45:51 -0000 1.91
+++ auth.c 10 May 2011 11:47:16 -0000
@@ -271,12 +271,6 @@ authorized_keys_file(struct passwd *pw)
}

char *
-authorized_keys_file2(struct passwd *pw)
-{
- return expand_authorized_keys(options.authorized_keys_file2, pw);
-}
-
-char *
authorized_principals_file(struct passwd *pw)
{
if (options.authorized_principals_file == NULL)
Index: auth.h
===================================================================
RCS file: /cvs/src/usr.bin/ssh/auth.h,v
retrieving revision 1.67
diff -u -p -r1.67 auth.h
--- auth.h 10 Mar 2011 11:34:25 -0000 1.67
+++ auth.h 10 May 2011 11:47:16 -0000
@@ -146,7 +146,6 @@ char *get_challenge(Authctxt *);
int verify_response(Authctxt *, const char *);

char *authorized_keys_file(struct passwd *);
-char *authorized_keys_file2(struct passwd *);
char *authorized_principals_file(struct passwd *);

FILE *auth_openkeyfile(const char *, struct passwd *, int);
Index: auth2-pubkey.c
===================================================================
RCS file: /cvs/src/usr.bin/ssh/auth2-pubkey.c,v
retrieving revision 1.27
diff -u -p -r1.27 auth2-pubkey.c
--- auth2-pubkey.c 20 Nov 2010 05:12:38 -0000 1.27
+++ auth2-pubkey.c 10 May 2011 11:47:16 -0000
@@ -450,13 +450,7 @@ user_key_allowed(struct passwd *pw, Key
file = authorized_keys_file(pw);
success = user_key_allowed2(pw, key, file);
xfree(file);
- if (success)
- return success;

- /* try suffix "2" for backward compat, too */
- file = authorized_keys_file2(pw);
- success = user_key_allowed2(pw, key, file);
- xfree(file);
return success;
}

Index: pathnames.h
===================================================================
RCS file: /cvs/src/usr.bin/ssh/pathnames.h,v
retrieving revision 1.20
diff -u -p -r1.20 pathnames.h
--- pathnames.h 31 Aug 2010 11:54:45 -0000 1.20
+++ pathnames.h 10 May 2011 11:47:17 -0000
@@ -88,9 +88,6 @@
*/
#define _PATH_SSH_USER_PERMITTED_KEYS ".ssh/authorized_keys"

-/* backward compat for protocol v2 */
-#define _PATH_SSH_USER_PERMITTED_KEYS2 ".ssh/authorized_keys2"
-
/*
* Per-user and system-wide ssh "rc" files. These files are executed with
* /bin/sh before starting the shell or command if they exist. They will be
Index: servconf.c
===================================================================
RCS file: /cvs/src/usr.bin/ssh/servconf.c,v
retrieving revision 1.214
diff -u -p -r1.214 servconf.c
--- servconf.c 29 Mar 2011 18:54:17 -0000 1.214
+++ servconf.c 10 May 2011 11:47:17 -0000
@@ -120,7 +120,6 @@ initialize_server_options(ServerOptions
options->client_alive_interval = -1;
options->client_alive_count_max = -1;
options->authorized_keys_file = NULL;
- options->authorized_keys_file2 = NULL;
options->num_accept_env = 0;
options->permit_tun = -1;
options->num_permitted_opens = -1;
@@ -250,13 +249,6 @@ fill_default_server_options(ServerOption
options->client_alive_interval = 0;
if (options->client_alive_count_max == -1)
options->client_alive_count_max = 3;
- if (options->authorized_keys_file2 == NULL) {
- /* authorized_keys_file2 falls back to authorized_keys_file */
- if (options->authorized_keys_file != NULL)
- options->authorized_keys_file2 = xstrdup(options->authorized_keys_file);
- else
- options->authorized_keys_file2 = xstrdup(_PATH_SSH_USER_PERMITTED_KEYS2);
- }
if (options->authorized_keys_file == NULL)
options->authorized_keys_file = xstrdup(_PATH_SSH_USER_PERMITTED_KEYS);
if (options->permit_tun == -1)
@@ -1207,9 +1199,6 @@ process_server_config_line(ServerOptions
case sAuthorizedKeysFile:
charptr = &options->authorized_keys_file;
goto parse_tilde_filename;
- case sAuthorizedKeysFile2:
- charptr = &options->authorized_keys_file2;
- goto parse_tilde_filename;
case sAuthorizedPrincipalsFile:
charptr = &options->authorized_principals_file;
parse_tilde_filename:
@@ -1474,7 +1463,6 @@ copy_set_server_options(ServerOptions *d
M_CP_STROPT(trusted_user_ca_keys);
M_CP_STROPT(revoked_keys_file);
M_CP_STROPT(authorized_keys_file);
- M_CP_STROPT(authorized_keys_file2);
M_CP_STROPT(authorized_principals_file);
}

@@ -1687,7 +1675,6 @@ dump_config(ServerOptions *o)
dump_cfg_string(sMacs, o->macs);
dump_cfg_string(sBanner, o->banner);
dump_cfg_string(sAuthorizedKeysFile, o->authorized_keys_file);
- dump_cfg_string(sAuthorizedKeysFile2, o->authorized_keys_file2);
dump_cfg_string(sForceCommand, o->adm_forced_command);
dump_cfg_string(sChrootDirectory, o->chroot_directory);
dump_cfg_string(sTrustedUserCAKeys, o->trusted_user_ca_keys);
Index: servconf.h
===================================================================
RCS file: /cvs/src/usr.bin/ssh/servconf.h,v
retrieving revision 1.95
diff -u -p -r1.95 servconf.h
--- servconf.h 13 Nov 2010 23:27:50 -0000 1.95
+++ servconf.h 10 May 2011 11:47:17 -0000
@@ -146,7 +146,6 @@ typedef struct {
*/

char *authorized_keys_file; /* File containing public keys */
- char *authorized_keys_file2;

char *adm_forced_command;

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


dkg at fifthhorseman

May 14, 2011, 8:23 AM

Post #21 of 33 (2609 views)
Permalink
Re: backdoor by authorized_keys2 leftovers [In reply to]

On 05/14/2011 07:02 AM, Damien Miller wrote:
> On Wed, 11 May 2011, Damien Miller wrote:
>
>>> I also think that being able to specify multiple authorized_keys files
>>> is very useful, so I would prefer to just see this as a documented
>>> feature.
>>
>> Perhaps we should make options.authorized_keys_file an array to let
>> people who want to use multiple files do so.
>
> Here's a lightly-tested patch against -current (OpenBSD version, it
> will probably need some editing for portable)

This patch appears to removes authorized_keys2 support, but does not
appear to make authorized_keys_file an array, as the comments above
would suggest.

--dkg
Attachments: signature.asc (1.01 KB)


djm at mindrot

May 14, 2011, 3:28 PM

Post #22 of 33 (2604 views)
Permalink
Re: backdoor by authorized_keys2 leftovers [In reply to]

On Sat, 14 May 2011, Damien Miller wrote:

> On Wed, 11 May 2011, Damien Miller wrote:
>
> > > I also think that being able to specify multiple authorized_keys files
> > > is very useful, so I would prefer to just see this as a documented
> > > feature.
> >
> > Perhaps we should make options.authorized_keys_file an array to let
> > people who want to use multiple files do so.
>
> Here's a lightly-tested patch against -current (OpenBSD version, it
> will probably need some editing for portable)

doh, wrong diff


Index: auth-rsa.c
===================================================================
RCS file: /cvs/src/usr.bin/ssh/auth-rsa.c,v
retrieving revision 1.79
diff -u -p -r1.79 auth-rsa.c
--- auth-rsa.c 3 Dec 2010 23:55:27 -0000 1.79
+++ auth-rsa.c 13 May 2011 12:22:18 -0000
@@ -157,44 +157,27 @@ auth_rsa_challenge_dialog(Key *key)
return (success);
}

-/*
- * check if there's user key matching client_n,
- * return key if login is allowed, NULL otherwise
- */
-
-int
-auth_rsa_key_allowed(struct passwd *pw, BIGNUM *client_n, Key **rkey)
+static int
+rsa_key_allowed_in_file(struct passwd *pw, char *file,
+ const BIGNUM *client_n, Key **rkey)
{
- char line[SSH_MAX_PUBKEY_BYTES], *file;
+ char line[SSH_MAX_PUBKEY_BYTES];
int allowed = 0;
u_int bits;
FILE *f;
u_long linenum = 0;
Key *key;

- /* Temporarily use the user's uid. */
- temporarily_use_uid(pw);
-
- /* The authorized keys. */
- file = authorized_keys_file(pw);
debug("trying public RSA key file %s", file);
- f = auth_openkeyfile(file, pw, options.strict_modes);
- if (!f) {
- xfree(file);
- restore_uid();
- return (0);
- }
-
- /* Flag indicating whether the key is allowed. */
- allowed = 0;
-
- key = key_new(KEY_RSA1);
+ if ((f = auth_openkeyfile(file, pw, options.strict_modes)) == NULL)
+ return 0;

/*
* Go though the accepted keys, looking for the current key. If
* found, perform a challenge-response dialog to verify that the
* user really has the corresponding private key.
*/
+ key = key_new(KEY_RSA1);
while (read_keyfile_line(f, file, line, sizeof(line), &linenum) != -1) {
char *cp;
char *key_options;
@@ -232,7 +215,10 @@ auth_rsa_key_allowed(struct passwd *pw,
}
/* cp now points to the comment part. */

- /* Check if the we have found the desired key (identified by its modulus). */
+ /*
+ * Check if the we have found the desired key (identified
+ * by its modulus).
+ */
if (BN_cmp(key->rsa->n, client_n) != 0)
continue;

@@ -261,11 +247,7 @@ auth_rsa_key_allowed(struct passwd *pw,
break;
}

- /* Restore the privileged uid. */
- restore_uid();
-
/* Close the file. */
- xfree(file);
fclose(f);

/* return key if allowed */
@@ -273,7 +255,33 @@ auth_rsa_key_allowed(struct passwd *pw,
*rkey = key;
else
key_free(key);
- return (allowed);
+
+ return allowed;
+}
+
+/*
+ * check if there's user key matching client_n,
+ * return key if login is allowed, NULL otherwise
+ */
+
+int
+auth_rsa_key_allowed(struct passwd *pw, BIGNUM *client_n, Key **rkey)
+{
+ char *file;
+ u_int i, allowed = 0;
+
+ temporarily_use_uid(pw);
+
+ for (i = 0; !allowed && i < options.num_authkeys_files; i++) {
+ file = expand_authorized_keys(
+ options.authorized_keys_files[i], pw);
+ allowed = rsa_key_allowed_in_file(pw, file, client_n, rkey);
+ xfree(file);
+ }
+
+ restore_uid();
+
+ return allowed;
}

/*
Index: auth.c
===================================================================
RCS file: /cvs/src/usr.bin/ssh/auth.c,v
retrieving revision 1.92
diff -u -p -r1.92 auth.c
--- auth.c 11 May 2011 04:47:06 -0000 1.92
+++ auth.c 13 May 2011 12:22:18 -0000
@@ -241,7 +241,7 @@ auth_root_allowed(char *method)
*
* This returns a buffer allocated by xmalloc.
*/
-static char *
+char *
expand_authorized_keys(const char *filename, struct passwd *pw)
{
char *file, ret[MAXPATHLEN];
@@ -262,12 +262,6 @@ expand_authorized_keys(const char *filen
fatal("expand_authorized_keys: path too long");
xfree(file);
return (xstrdup(ret));
-}
-
-char *
-authorized_keys_file(struct passwd *pw)
-{
- return expand_authorized_keys(options.authorized_keys_file, pw);
}

char *
Index: auth.h
===================================================================
RCS file: /cvs/src/usr.bin/ssh/auth.h,v
retrieving revision 1.68
diff -u -p -r1.68 auth.h
--- auth.h 11 May 2011 04:47:06 -0000 1.68
+++ auth.h 13 May 2011 12:22:18 -0000
@@ -145,7 +145,7 @@ struct passwd * getpwnamallow(const char
char *get_challenge(Authctxt *);
int verify_response(Authctxt *, const char *);

-char *authorized_keys_file(struct passwd *);
+char *expand_authorized_keys(const char *, struct passwd *pw);
char *authorized_principals_file(struct passwd *);

FILE *auth_openkeyfile(const char *, struct passwd *, int);
Index: auth2-pubkey.c
===================================================================
RCS file: /cvs/src/usr.bin/ssh/auth2-pubkey.c,v
retrieving revision 1.28
diff -u -p -r1.28 auth2-pubkey.c
--- auth2-pubkey.c 11 May 2011 04:47:06 -0000 1.28
+++ auth2-pubkey.c 13 May 2011 12:22:18 -0000
@@ -435,7 +435,7 @@ user_cert_trusted_ca(struct passwd *pw,
int
user_key_allowed(struct passwd *pw, Key *key)
{
- int success;
+ u_int success, i;
char *file;

if (auth_key_is_revoked(key))
@@ -447,9 +447,12 @@ user_key_allowed(struct passwd *pw, Key
if (success)
return success;

- file = authorized_keys_file(pw);
- success = user_key_allowed2(pw, key, file);
- xfree(file);
+ for (i = 0; !success && i < options.num_authkeys_files; i++) {
+ file = expand_authorized_keys(
+ options.authorized_keys_files[i], pw);
+ success = user_key_allowed2(pw, key, file);
+ xfree(file);
+ }

return success;
}
Index: pathnames.h
===================================================================
RCS file: /cvs/src/usr.bin/ssh/pathnames.h,v
retrieving revision 1.21
diff -u -p -r1.21 pathnames.h
--- pathnames.h 11 May 2011 04:47:06 -0000 1.21
+++ pathnames.h 13 May 2011 12:22:18 -0000
@@ -88,6 +88,9 @@
*/
#define _PATH_SSH_USER_PERMITTED_KEYS ".ssh/authorized_keys"

+/* backward compat for protocol v2 */
+#define _PATH_SSH_USER_PERMITTED_KEYS2 ".ssh/authorized_keys2"
+
/*
* Per-user and system-wide ssh "rc" files. These files are executed with
* /bin/sh before starting the shell or command if they exist. They will be
Index: servconf.c
===================================================================
RCS file: /cvs/src/usr.bin/ssh/servconf.c,v
retrieving revision 1.215
diff -u -p -r1.215 servconf.c
--- servconf.c 11 May 2011 04:47:06 -0000 1.215
+++ servconf.c 13 May 2011 12:22:19 -0000
@@ -119,7 +119,7 @@ initialize_server_options(ServerOptions
options->use_dns = -1;
options->client_alive_interval = -1;
options->client_alive_count_max = -1;
- options->authorized_keys_file = NULL;
+ options->num_authkeys_files = 0;
options->num_accept_env = 0;
options->permit_tun = -1;
options->num_permitted_opens = -1;
@@ -249,8 +249,12 @@ fill_default_server_options(ServerOption
options->client_alive_interval = 0;
if (options->client_alive_count_max == -1)
options->client_alive_count_max = 3;
- if (options->authorized_keys_file == NULL)
- options->authorized_keys_file = xstrdup(_PATH_SSH_USER_PERMITTED_KEYS);
+ if (options->num_authkeys_files == 0) {
+ options->authorized_keys_files[options->num_authkeys_files++] =
+ xstrdup(_PATH_SSH_USER_PERMITTED_KEYS);
+ options->authorized_keys_files[options->num_authkeys_files++] =
+ xstrdup(_PATH_SSH_USER_PERMITTED_KEYS2);
+ }
if (options->permit_tun == -1)
options->permit_tun = SSH_TUNMODE_NO;
if (options->zero_knowledge_password_authentication == -1)
@@ -286,7 +290,7 @@ typedef enum {
sMaxStartups, sMaxAuthTries, sMaxSessions,
sBanner, sUseDNS, sHostbasedAuthentication,
sHostbasedUsesNameFromPacketOnly, sClientAliveInterval,
- sClientAliveCountMax, sAuthorizedKeysFile, sAuthorizedKeysFile2,
+ sClientAliveCountMax, sAuthorizedKeysFile,
sGssAuthentication, sGssCleanupCreds, sAcceptEnv, sPermitTunnel,
sMatch, sPermitOpen, sForceCommand, sChrootDirectory,
sUsePrivilegeSeparation, sAllowAgentForwarding,
@@ -391,7 +395,6 @@ static struct {
{ "clientaliveinterval", sClientAliveInterval, SSHCFG_GLOBAL },
{ "clientalivecountmax", sClientAliveCountMax, SSHCFG_GLOBAL },
{ "authorizedkeysfile", sAuthorizedKeysFile, SSHCFG_ALL },
- { "authorizedkeysfile2", sAuthorizedKeysFile2, SSHCFG_ALL },
{ "useprivilegeseparation", sUsePrivilegeSeparation, SSHCFG_GLOBAL},
{ "acceptenv", sAcceptEnv, SSHCFG_GLOBAL },
{ "permittunnel", sPermitTunnel, SSHCFG_ALL },
@@ -1197,11 +1200,19 @@ process_server_config_line(ServerOptions
* AuthorizedKeysFile /etc/ssh_keys/%u
*/
case sAuthorizedKeysFile:
- charptr = &options->authorized_keys_file;
- goto parse_tilde_filename;
+ while ((arg = strdelim(&cp)) && *arg != '\0') {
+ if (options->num_authkeys_files >= MAX_AUTHKEYS_FILES)
+ fatal("%s line %d: "
+ "too many authorized keys files.",
+ filename, linenum);
+ options->authorized_keys_files[
+ options->num_authkeys_files++] =
+ tilde_expand_filename(arg, getuid());
+ }
+ break;
+
case sAuthorizedPrincipalsFile:
charptr = &options->authorized_principals_file;
- parse_tilde_filename:
arg = strdelim(&cp);
if (!arg || *arg == '\0')
fatal("%s line %d: missing file name.",
@@ -1420,6 +1431,10 @@ parse_server_match_config(ServerOptions
dst->n = src->n; \
} \
} while(0)
+#define M_CP_STRARRAYOPT(n, num_n) do {\
+ for (dst->num_n = 0; dst->num_n < src->num_n; dst->num_n++) \
+ dst->n[dst->num_n] = xstrdup(src->n[dst->num_n]); \
+} while(0)

/*
* Copy any supported values that are set.
@@ -1462,8 +1477,8 @@ copy_set_server_options(ServerOptions *d
M_CP_STROPT(chroot_directory);
M_CP_STROPT(trusted_user_ca_keys);
M_CP_STROPT(revoked_keys_file);
- M_CP_STROPT(authorized_keys_file);
M_CP_STROPT(authorized_principals_file);
+ M_CP_STRARRAYOPT(authorized_keys_files, num_authkeys_files);
}

#undef M_CP_INTOPT
@@ -1674,7 +1689,6 @@ dump_config(ServerOptions *o)
dump_cfg_string(sCiphers, o->ciphers);
dump_cfg_string(sMacs, o->macs);
dump_cfg_string(sBanner, o->banner);
- dump_cfg_string(sAuthorizedKeysFile, o->authorized_keys_file);
dump_cfg_string(sForceCommand, o->adm_forced_command);
dump_cfg_string(sChrootDirectory, o->chroot_directory);
dump_cfg_string(sTrustedUserCAKeys, o->trusted_user_ca_keys);
@@ -1687,6 +1701,8 @@ dump_config(ServerOptions *o)
dump_cfg_string(sLogFacility, log_facility_name(o->log_facility));

/* string array arguments */
+ dump_cfg_strarray(sAuthorizedKeysFile, o->num_authkeys_files,
+ o->authorized_keys_files);
dump_cfg_strarray(sHostKeyFile, o->num_host_key_files,
o->host_key_files);
dump_cfg_strarray(sHostKeyFile, o->num_host_cert_files,
Index: servconf.h
===================================================================
RCS file: /cvs/src/usr.bin/ssh/servconf.h,v
retrieving revision 1.96
diff -u -p -r1.96 servconf.h
--- servconf.h 11 May 2011 04:47:06 -0000 1.96
+++ servconf.h 13 May 2011 12:22:19 -0000
@@ -27,6 +27,7 @@
#define MAX_HOSTCERTS 256 /* Max # host certificates. */
#define MAX_ACCEPT_ENV 256 /* Max # of env vars. */
#define MAX_MATCH_GROUPS 256 /* Max # of groups for Match. */
+#define MAX_AUTHKEYS_FILES 256 /* Max # of authorized_keys files. */

/* permit_root_login */
#define PERMIT_NOT_SET -1
@@ -145,7 +146,8 @@ typedef struct {
* disconnect the session
*/

- char *authorized_keys_file; /* File containing public keys */
+ u_int num_authkeys_files; /* Files containing public keys */
+ char *authorized_keys_files[MAX_AUTHKEYS_FILES];

char *adm_forced_command;

Index: sshd.8
===================================================================
RCS file: /cvs/src/usr.bin/ssh/sshd.8,v
retrieving revision 1.260
diff -u -p -r1.260 sshd.8
--- sshd.8 28 Oct 2010 18:33:28 -0000 1.260
+++ sshd.8 13 May 2011 12:22:19 -0000
@@ -435,7 +435,7 @@ is run, and if that
does not exist either, xauth is used to add the cookie.
.Sh AUTHORIZED_KEYS FILE FORMAT
.Cm AuthorizedKeysFile
-specifies the file containing public keys for
+specifies the file or files containing public keys for
public key authentication;
if none is specified, the default is
.Pa ~/.ssh/authorized_keys .
Index: sshd_config
===================================================================
RCS file: /cvs/src/usr.bin/ssh/sshd_config,v
retrieving revision 1.83
diff -u -p -r1.83 sshd_config
--- sshd_config 6 May 2011 01:03:35 -0000 1.83
+++ sshd_config 13 May 2011 12:22:19 -0000
@@ -42,7 +42,7 @@

#RSAAuthentication yes
#PubkeyAuthentication yes
-#AuthorizedKeysFile .ssh/authorized_keys
+#AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#RhostsRSAAuthentication no
Index: sshd_config.5
===================================================================
RCS file: /cvs/src/usr.bin/ssh/sshd_config.5,v
retrieving revision 1.131
diff -u -p -r1.131 sshd_config.5
--- sshd_config.5 8 Dec 2010 04:02:47 -0000 1.131
+++ sshd_config.5 13 May 2011 12:22:19 -0000
@@ -170,6 +170,10 @@ is taken to be an absolute path or one r
directory.
The default is
.Dq .ssh/authorized_keys .
+Multiple files may be listed, either on a single line separated by
+whitespace or on additional
+.Cm AuthorizedKeysFile
+lines.
.It Cm AuthorizedPrincipalsFile
Specifies a file that lists principal names that are accepted for
certificate authentication.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


djm at mindrot

May 14, 2011, 3:52 PM

Post #23 of 33 (2607 views)
Permalink
Re: backdoor by authorized_keys2 leftovers [In reply to]

On Sun, 15 May 2011, Damien Miller wrote:

> On Sat, 14 May 2011, Damien Miller wrote:
>
> > On Wed, 11 May 2011, Damien Miller wrote:
> >
> > > > I also think that being able to specify multiple authorized_keys files
> > > > is very useful, so I would prefer to just see this as a documented
> > > > feature.
> > >
> > > Perhaps we should make options.authorized_keys_file an array to let
> > > people who want to use multiple files do so.
> >
> > Here's a lightly-tested patch against -current (OpenBSD version, it
> > will probably need some editing for portable)
>
> doh, wrong diff

This will apply to -current portable as checked out from cvs, hg or from
the 20110516 snapshot tomorrow.

-d
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


dkg at fifthhorseman

May 15, 2011, 9:43 AM

Post #24 of 33 (2595 views)
Permalink
Re: backdoor by authorized_keys2 leftovers [In reply to]

On 05/14/2011 06:28 PM, Damien Miller wrote:
> Index: sshd_config.5
> ===================================================================
> RCS file: /cvs/src/usr.bin/ssh/sshd_config.5,v
> retrieving revision 1.131
> diff -u -p -r1.131 sshd_config.5
> --- sshd_config.5 8 Dec 2010 04:02:47 -0000 1.131
> +++ sshd_config.5 13 May 2011 12:22:19 -0000
> @@ -170,6 +170,10 @@ is taken to be an absolute path or one r
> directory.
> The default is
> .Dq .ssh/authorized_keys .
> +Multiple files may be listed, either on a single line separated by
> +whitespace or on additional
> +.Cm AuthorizedKeysFile
> +lines.
> .It Cm AuthorizedPrincipalsFile
> Specifies a file that lists principal names that are accepted for
> certificate authentication.

It seems somewhat unclear how AuthorizedKeysFile interacts with a Match
clause.

If the following makes an array of two authorizedkeysfiles:

AuthorizedKeysFile foo
AuthorizedKeysFile bar


then what does this mean for user X:

AuthorizedKeysFile foo
Match user x
AuthorizedKeysFile bar

Is it worth explicitly stating that, for a matching connection, setting
an AuthorizedKeysFile within a Match block explicitly removes all other
AuthorizedKeysFile settings *not* in that match block?

--dkg
Attachments: signature.asc (1.01 KB)


djm at mindrot

May 15, 2011, 7:51 PM

Post #25 of 33 (2617 views)
Permalink
Re: backdoor by authorized_keys2 leftovers [In reply to]

On Sun, 15 May 2011, Daniel Kahn Gillmor wrote:

> It seems somewhat unclear how AuthorizedKeysFile interacts with a Match
> clause.
>
> If the following makes an array of two authorizedkeysfiles:
>
> AuthorizedKeysFile foo
> AuthorizedKeysFile bar

So the question is whether to allow multiple directives that add to the
list (as is the case in the slightly-broken patch I sent out yesterday)
or to allow a single directive that specifies all the files on one line.

The latter is more clear for Match, but long lines are more likely to wrap
and are harder to read in sshd_config.

That being said, there is plenty of room for the common cases that I can
think of:

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.

-d
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

First page Previous page 1 2 Next page Last page  View All OpenSSH dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.