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. This can be a good or a bad thing depending on whether you want to enforce this restriction.

Public keys for known hosts can be stored in $HOME/.ssh/known_hosts files. Whenever a connection is attempted, the system will determine whether the connecting system matches one that is listed in this file and will warn the user if the key isn’t present or if it doesn’t match the key saved in the file from some previous login session.

Various security levels are possible with ssh. You can base all authentication on host keys if you like. This works much like using rsh except you still have the benefit of encryption. Alternately, you can generate key pairs for each user (as opposed to each host) and distribute the user keys to all of your hosts. The only disadvantage to this approach would be that, if an account is compromised, it will be compromised across the board. You can also generate separate keys for each user on each host — a lot more work but more secure as well. The decision on which way to go depends on how much security you really need.

You can also require that each of your users enter a passphrase before his or her private key is accessed. When running the ssh-keygen command that generates the public and private keys, a user has the option of entering a passphrase.

If you use ssh to allow root-level access to systems without passwords, you still need to be wary of access to the trusted systems. If someone gains access to a trusted system, they have access to all the systems that trust it. I generally restrict root-level trust to systems that only a handful of people can access while encouraging user-level trust in any way that facilitates my users’ work.

Inter-host trust on Unix, part 1