|Main Archive Page > Month Archives > openssh-unix-dev archives|
Sent from my iPhone
On May 12, 2011, at 6:47 PM, Iain Morgan <email@example.com> 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 <firstname.lastname@example.org> wrote:
>>> looks like we've been waiting too long :)
>>> 2) The files
>>> are now obsolete, you can use
>>> 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
> 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