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
On Tue, Jan 2, 2018 at 11:13 AM, Cedric Blancher <cedric.blancher at gmail.com> wrote:> 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.And "if wishes were fishes, we'd all swim in riches". Kerberized *anything* requires a Kerberos server, a really reliable server or set of servers, to manage the credentials. Many "kerberized telnet" setups don't actually use the Kerberized telnet protocols on port 6623, they just use the telnetd on port 23 of the telnetd server to authenticate the user against the Kerberos server. And many obsolete, setups don't even bother with *that*. Been there, done that, should have gotten the T-shirt. I'm afraid that many admins, even in DoD environments, fail to bother with setting up these kinds of basic protections. Explaining the distinctions can be... adventuresome.
On 2 January 2018 at 20:12, Nico Kadel-Garcia <nkadel at gmail.com> wrote:> On Tue, Jan 2, 2018 at 11:13 AM, Cedric Blancher > <cedric.blancher at gmail.com> wrote: > >> 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. > > And "if wishes were fishes, we'd all swim in riches". Kerberized > *anything* requires a Kerberos server, a really reliable server or set > of servers, to manage the credentials. Many "kerberized telnet" setups > don't actually use the Kerberized telnet protocols on port 6623, they > just use the telnetd on port 23 of the telnetd server to authenticate > the user against the Kerberos server. And many obsolete, setups don't > even bother with *that*. Been there, done that, should have gotten > the T-shirt. > > I'm afraid that many admins, even in DoD environments, fail to bother > with setting up these kinds of basic protections. Explaining the > distinctions can be... adventuresome.Sure, but strong authentication is still more important than strong encryption, and whats the alternative now that OpenSSH is broken in a way which requires 2 client binaries, one to talk to old servers and one to talk to new servers? I wish project Athena, of which Kerberos is the authentication part, would've become more widespread, that would've avoided the mess we have with single-island solutions a la "SSH". Ced -- Cedric Blancher <cedric.blancher at gmail.com> [https://plus.google.com/u/0/+CedricBlancher/] Institute Pasteur