Dave McGuire <mcguire at neurotica.com> writes:
On 11/27/2013 12:13 PM, Brian Schenkenberger, VAXman- wrote:
The Telnet protocol itself makes no promises about the presence OR
absence of encryption, and it has a very flexible do/don't/will/won't
option negotiation protocol. Kerberos-enabled telnet, in particular,
allows for automatic authentication and/or stream encryption, with
either enabled or disabled on an invocation-by-invocation basis.
Kerberos-enabled telnet doesn't work unless the target is setup to and
willing to provide for it. I have no knowledge of how Sampsa has his
configured but from the initial discussion, I'd doubt that Kerberos is
involved.
As do I. I was merely nit-picking that "telnet" does not exclusively
mean "cleartext". Given that it was an open and outward-facing service,
I'd certainly HOPE it was Kerberized telnet! ;)
Sampsa already explain that it is not.
I do have telnet enabled but only for specific captive accounts. These
accounts -- such as the VTTEST account -- run an application that can't
be escaped from to tinker with anything on the system. For the general
cases, though, I only permit 'ssh' for external access and that runs on
an alternate port too. Port scanning ssh on a VMS system can consume a
over-generous amount of CPU resources. I also limit, becasue of this,
how many 'ssh' session can be created at any one time. For me, this is
a pretty low number as I should be the only party accessing my systems.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
Well I speak to machines with the voice of humanity.
Show replies by date