... none of this will do a lick of difference if you are still using telnet to connect into the network; I can snoop your su - root as good as your login. You have to either encrypt or tunnel -if not both- the original connection. Otherwise, your single point of failure (in this case, single point of risk ) still remains, i.e., the original connection into your network using telnet.

With SSH, the connection into the network is encrypted; not that it can't be hacked, but it'll take governent-type resources to do so. Add the use of keys, where the public key in your server has to match the private key in your user's computer, it makes it that much harder to hack. You add a "security verification" after login, and change the SSH port, it adds to the protection.

Also, even if your users have dynamic IP's, you can still use wrappers to deny connections from outside your users' networks. For example, if you have a user that has 32.1.1.10 right now, chances are, next time his IP refreshes, he's not going to go to say 222.123.321.4, since ISP's have a limited number of IP's - and therefore networks - to work with, so you could accept connections from say 32.1.xx.xx only and reject everything else.