On 2 January 2018 at 20:12, Nico Kadel-Garcia <nkadel@xxxxxxxxx> wrote: > On Tue, Jan 2, 2018 at 11:13 AM, Cedric Blancher > <cedric.blancher@xxxxxxxxx> 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@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
