Legacy option for key length?

Cedric Blancher cedric.blancher at gmail.com
Wed Jan 3 06:17:43 AEDT 2018


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



More information about the openssh-unix-dev mailing list