}> I use encrypted (kerberized) telnet both to and from my various
}> NetBSD boxes, and it works quite well.  I also use kerberos passwords
}> on some of them, it works just fine.  I don't use rsh or rlogin, so
}> I don't see problems with them.

}Hmm, there was something obvious that I was missing.  After hearing that
}it should work, I looked at it some more, and it appears to work fine
}with 'telnet -a host', instead of just 'telnet host' which generates a
}'telnetd: Authorization failed', with 'telnetd -a valid' in /etc/inetd.conf.

I have patches I use that make -ax the default set of options for
telnet, turn off that default when you telnet to localhost, and add
the option -A which turns off encryption & authentication (to use
when you telnet to a machine without the encrypted telnetd, when you
don't want it to try to negotiate).  If someone wants them, I can
make them available.  I created them to match the way we have things
work for our users on the other OSs we use.

I also have a patch that I apply that makes telnet work with pools of
machines represented by a single name.  It breaks telnet when a
machine doesn't have a PTR record, so I have to fix that before it
can be committed.  If someone wants it in that state, it is PR #6918.

}Looking at the manpage, it is not obvious that '-a' enables kerberos support.

It took me *ages* to figure out how to setup telnetd correctly.  I was
initially trying to set it up a few years ago, I figured out how to set
it up late last year when I finally dove into the source code.

}What are the chances of a kerberized rshd/rlogind making it into the tree?

I used to complain on an occasional basis that with KERBEROS set, rshd,
rlogind, and I think mount_nfs would consistently fail, making a make
build less useful.  Since I didn't contribute any patches to fix it,
and I don't know that anyone cared, it stayed broken til someone just
took the kerberos portions out, I assume.

}> I use it regularly.  I find it a benefit.

}Cool.  I think it is good to have it in the tree, but I think working versions
}of rshd and rlogind are needed.  For our environment, we really need rsh
}functionality, and have been using ssh for this.  We would prefer to have
}a builtin solution, and 56bit DES is more than adequate in our environment.

This isn't quite what you want, but you can install ssh so it runs instead
of rsh/rlogin when you run them.  This at least gives you an encrypted
channel, and may not break scripts (and habits) that use them.  I started
setting something like that up where I used to work, and I think it worked
ok, but I left not long after I set it up.

Tracy J. Di Marco White
Project Vincent Systems Manager
gendalia@iastate.edu