openssh-unix-dev May 2011 archive
Main Archive Page > Month Archives  > openssh-unix-dev archives
openssh-unix-dev: Re: backdoor by authorized_keys2 leftovers

Re: backdoor by authorized_keys2 leftovers

From: Dan Kaminsky <dan_at_nospam>
Date: Fri May 13 2011 - 01:49:13 GMT
To: Iain Morgan <imorgan@nas.nasa.gov>

Sent from my iPhone

On May 12, 2011, at 6:47 PM, Iain Morgan <imorgan@nas.nasa.gov> 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@gmail.com> 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@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev