[1523] in Kerberos_V5_Development
Re: rlogin -x --> rlogin -noencryption
daemon@ATHENA.MIT.EDU (Ken Raeburn)
Thu Aug 8 18:18:36 1996
To: "Barry Jaspan" <bjaspan@MIT.EDU>
Cc: hartmans@MIT.EDU, krbdev@MIT.EDU
From: Ken Raeburn <raeburn@cygnus.com>
Date: 08 Aug 1996 18:18:05 -0400
In-Reply-To: "Barry Jaspan"'s message of Wed, 7 Aug 96 22:24:56 -0400
"Barry Jaspan" <bjaspan@MIT.EDU> writes:
> I'd rather see the right decision made once and
> enforced with no extra effort, particularly in this case when the
> right decision is obvious.
If the "right" way is so obvious, why provide any option to do
otherwise? And if there's a reason for providing the option, are you
so sure that the default behavior is still "obviously" the same for
all sites?
There's no reason we couldn't have the compiled-in default be to
enable encryption, which krb5.conf could override, and have
command-line options override both.
Also, the right defaults for forwarding tickets (also part of our
patches) are not "obviously" the same for all sites.
On a related note, I'd like to see the "...using DES encryption..."
message printed by the client side rather than the server side. (And
maybe add a "not encrypting" message if we're changing defaults -- or
maybe just add it anyways.) Then we can add yet another option to
make it shut up, for programs that want "rsh" to be a clean,
non-intrusive communications channel.
Something like this is needed for rdist. It uses rsh to make the
connection, and expects all the data it receives back to be from
rdistd, no random garbage from rshd. The solution sent over the
rdist-dev list was basically to disable the encryption status banner
on the server side, totally independent of what application you might
be running.
(Yes, it'd be nice to throw out rsh and use telnet for this instead,
but until the DO-RUN-COMMAND, DONT-USE-TTY, DO-MULTIPLEX-IO-STREAMS
telnet options are implemented, rsh is what we're stuck with.)
