How NOT to Use the Secure Shell
(and other unwise/foolish acts)
Just because you have secure shell on your machine does NOT mean that you have a secure machine. It just means that you have the potential of having secure connections across the network. Unless insecure commands (such as telnet, ftp, rlogin, rsh, and rcp) are disabled from your host machine, then anyone can [foolishly] connect to the server using clear text to convey information such as login name, password, and any other data necessary for the login process.
To prove this, this demonstration shows the effect of running telnet from a machine running sshd2 (the Secure Shell daemon) to another machine also running the sshd2.
Obviously, this is not good, and we want to do something about it.
If our goal is to have a machine that is relatively secure in its actions across the network, then we will have to disable the insecure commands as root and allow only the ssh2 commands to work. Once we have done that, we should be left with a system that will only enable users to connect to (or from) a machine.
There is one more problem, though, and that occurs when the server uses a login scheme where it puts the login screen on several terminals. Login names and passwords are sent across the network via clear text. Thus, anyone can still sniff the passwords off that type of network. However, Secure Shell was not intended to prevent this type of security. Instead, Secure Shell was meant to make a secure connection from a secure machine to another secure machine.