On 2 January 2018 at 17:08, Marc Haber <mh+openssh-unix-dev@xxxxxxxxxxxx> 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@xxxxxxxxx> [https://plus.google.com/u/0/+CedricBlancher/] Institute Pasteur _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
