Upgrade to the Latest Version of MIT Kerberos on RHEL3.1

Brad De Vries devriesbj
Thu Aug 11 07:39:02 PDT 2005


On 8/11/05, James McDonald <james at jamesmcdonald.id.au> wrote:
> 
> 
> A. Khattri wrote:
> 
> >On Wed, 10 Aug 2005, Net Llama! wrote:
> >
> >
> >
> >>On 08/10/2005 05:41 PM, James McDonald wrote:
> >>
> >>
> >>>I have a Redhat Enterprise Linux Box at work which I have winbind
> >>>authentication running successfully to handle remote logins via a
> >>>kerberised version of telnet which is at version:
> >>>
> >>>
> >
> >Wow, I thought everyone knew how insecure telnet is...
> >
> >
> >
> >
> Aparrently QAD doesn't believe in security ... I asked the same question
> why we weren't using ssh and I got looked at as if I was the idiot.

Actually for character clients into MFG/PRO, SSH works perfectly and
should be used when security is a concern (which I'm sure is the case
for you.)  I use PuTTY as do many of my customers.

For Desktop 2 clients, web browser/java/apache/tomcat, you can
restrict the telnet server to allow telnet in from the tomcat server
only.  There is still a problem with the browser's java telnet client.

Here are my recommendations if the current solution is not viable:
1) Run character clients (Internet or Intranet) via SSH -- it's a lot
faster with almost the same functionality.
2) If they require Desktop clients, setup a VPN server that they need
to run before connecting -- this is the company data we're talking
about.
3) If VPN is not an option and they still require Desktop clients, I
think the best thing you can do is hide the telnet from the client
side on a different port.

In addition to those, submit a support call to QAD asking that it be
changed.  If they get enough, they might react.

Good luck,
Brad.

Brad.



More information about the Linux-users mailing list