Legacy option for key length?

[Cedric Blancher]

On 2 January 2018 at 17:08, Marc Haber <mh+openssh-unix-dev at zugschlus.de> wrote:
> On Tue, Jan 02, 2018 at 04:03:34PM +1030, David Newall wrote:
>> On 02/01/18 03:29, Michael Ströder wrote:
>> > How high is the risk that this unmaintained device is added to
>> > yet-another-bot-net in the Internet-of-shitty-devices or is used to
>> > enter parts of your network.
>>
>> I think that is what is called a straw-man argument.  If a device can be
>> compromised in the way you suggest, then I am sure it will be replaced, but
>> it will be replaced because it needs to be, not because its management
>> interface cannot be accessed via the latest openssh.  Disallowing use of
>> openssh doesn't encourage people to throw away expensive gear, it encourages
>> them to throw away new versions of openssh.
>
> Imagine an organization which has only reluctantly allowed their network
> / Unix admins to run Linux on their workstations and has only done so
> with the admins' promise to run only the latest software.
>
> And now, a bunch of older enterprise devices in the data center cannot
> be accessed from those workstations any more.
>
> The admins are forced to say "yes" to the question "will accessing the
> device from an enterprise-standard Windows client work".
>
> Now imagine the chance of the admins still being allowed to keep their
> Linux workstations.
>
> Not all installations are clueful.
>
> And this all goes without mentioning that people are re-enabling telnet
> on their APC powerstrips right in this second because OpenSSH won't work
> any more.

There is a simple solution: Hardware certified per MIL standards (US
DOD MIL standards) support kerberized telnet, so ssh can be declared
as "not needed" / "obsolete" for that purpose.

Ced
-- 
Cedric Blancher <cedric.blancher at gmail.com>
[https://plus.google.com/u/0/+CedricBlancher/]
Institute Pasteur