/usr/kerberos/bin/telnet client from krb5-workstation-1.2.1-8 does NOT use
encryption by default, thus it uses KRB autentication but doesn't negotiate
for encryption, at least if used for connection against KRB version IV
server (kth-krb-1.0.2 distribution).
Other packages installed on RedHat:
The problem is obeyed by explicit usage of option -x, I suggest recompiling
krb software with encryption enabled by default to allow maximual standard
This would be inconsistent with the existing telnet. Because it does not fall
back to unencrypted operation like the r-commands do, it would cause unexpected
failures for our users who don't use Kerberos, but who install it (which is a
much larger number than I'd prefer).
Much as I'd like to, for this reason, we can't change this behavior.
Date: 30 Jan 2001 17:56:53 +0100
From: Assar Westerlund <firstname.lastname@example.org>
To: Martin MOKREJ) <email@example.com>
> +This would be inconsistent with the existing telnet. Because it
> does not fall +back to unencrypted operation like the r-commands do,
> it would cause unexpected +failures for our users who don't use
> Kerberos, but who install it (which is a +much larger number than
> I'd prefer). + +Much as I'd like to, for this reason, we can't
> change this behavior.
That's wrong. `vanilla telnet' doesn't support any encryption so it
isn't a problem.
I agree that people who do use kerberos use the encryption and those who do NOT
use yet kerberos rely on /usr/bin/telnet so even if the /usr/kerberos/bin/telnet
would request encryption and refuse unencrypted connections, it wouldn't harm to
It remains a problem because /usr/kerberos/bin is ahead of /usr/bin in the PATH,
in order for Kerberized r-commands to be used if they are available. Having
/usr/kerberos/bin/telnet request encryption by default would fail unexpectedly
in many situations, and having it request encryption, but not require it, is not