backdoor by authorized_keys2 leftovers

Dan Kaminsky dan at
Fri May 13 11:49:13 EST 2011

Sent from my iPhone

On May 12, 2011, at 6:47 PM, Iain Morgan <imorgan at> 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> wrote:
>>> looks like we've been waiting too long :)
>>> 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

More information about the openssh-unix-dev mailing list