Unix as a Second Language

Unix tip: Inter-host trust on Unix, part 2

Ssh provides a method of connecting to Unix systems which is superior to that provided by rsh and rlogin if only because ssh connections are protected by the underlying encryption that ssh employs. Just how much better depends on which version of ssh you are using and how you set it up. While some may might assume that all ssh connections are handled the same, there are significant differences between the two versions of ssh and numerous ways that ssh can be deployed.

Ssh version 1 is in a number of ways very similar to rsh. It uses files that are similar to those used by rsh both in name and function. For example, on a system using ssh 1, you might see a .shosts file that mimics the use of the .rhosts file and an /etc/ssh/shosts.equiv file that acts like the /etc/hosts.equiv file. There's even a slogin command that works like rlogin. The reason for these similarities is more than accidental. Its designer wanted to provide an easy replacement for rsh; the similarities made it easy for early adopters to switch from one tool to the other.

For ssh1, if a host in listed either in the /etc/hosts.equiv or in the /etc/ssh/shosts.equiv file on a system, the user is permitted to log in. Similarly, if the .rhosts or the .shosts file in a user's home contains the name of the system, the user can also log in.

A server using ssh 2 can be configured to allow use of .rhosts or .shosts for authenticating hosts, but the more rigorous authentication mechanisms, based on public key encryption, are far more secure and almost always in use. For public key authentication to work, the private key on one system and the public key on the other have to have been generated in the same operation. This is next to impossible to fake. For the .rhosts or .shosts method to work, you just have to be able to add a host name to one of these files.

Today, version 1 of SSH is generally considered obsolete due to inherent security weaknesses, so you are unlikely to see it in use and should always elect to use ssh2 instead and to disable ssh1 support on your servers to keep them from accepting less secure connections.

Ssh isn't just a protocol for securing connections between unix hosts, of course. It can also provide secure connections from windows to unix, using tools such as PuTTY or VanDyke's SecureCRT that run on the Windows desktop. I routinely log into my Unix servers from my Windows laptop using PuTTY and have my students download the PuTTY exe file when they need to log in to a vmware Linux system during lab. Most Linux systems have the insecure protocols like telnet and ftp disabled by default, so this gives the student the access they need with almost no effort and no expense.

Unlike rsh, ssh is not affected by the CONSOLE setting in the /etc/default/login file. In other words, it will not deny you access as root because you are not logging it at the console.

Sign up for ITworld's Daily newsletter
Follow ITworld on Twitter @IT_world