Beyond Login and File Transfer: SSH as Virtual Private Network

SSH is capable of much more than mere logins and file transfers. Some of this capability was suggested in the first part of the chapter when we covered X11 forwarding. It turns out we can do more. Much more.

The .ssh/config File

Most of this part of the chapter will concern itself with the the .ssh/config file located off your home directory. It is possible that this file does not yet exist. If it doesn't, create it, and then set its permissions to be at least as restrictive as 0644. A mode of 0600 is probably better. This is definitely a file you want writeable only by you.

Let's look at a sample config file:

 Host alienmystery

 ForwardX11 yes

 LocalForward 2023 oopsbuzz:23

As you can see, many options may be set. We'll cover many (but by no means all) of these options in this part of the chapter. Consult the man page for OpenSSH for full details.

We will also cover a number of items in the SSH daemon option file, typically /etc/ssh/sshd_options. We'll cover the client options first.

SSH CLIENT OPTIONS

Attribute	Description
Host	This specifies the host to which the following options will be applied. Note that this host name must be what is actually passed on the command line. If, for example, you specify an IP address on the command line and the host's DNS name appears with this option, the options will not be applied, because the name passed doesn't lexically match this option. Wildcards of "" and "?" may be used (where these characters have the same meanings as in file matching); thus "Host " may be used to set options for all hosts, and "Host *.bakery.org" may be used to set options for all hosts in the bakery.org domain. All options following a "Host" specification apply only to hosts matching the argument to this option, until another Host option is encountered , of course.
Compression	Argument must be "yes" or "no." Specifies whether data should be compressed before it is encrypted and sent. Whether this is beneficial will depend on the speed of your link and of your processors at each end. Generally , if you have fast processors at both ends of a slow link, compression is probably a good idea.
CompressionLevel	Specifies compression quality on a scale from 1 to 9, where 1 is fast but poor compression and 9 is slow but good compression. The default is 6. This seems to work well in most cases.
ForwardX11	Argument must be "yes" or "no." For X11 forwarding to work, the server side must also be set to allow this. This option is demonstrated in the X17 Forwarding section of this chapter.
GatewayPorts	Argument must be "yes" or "no"; defaults to "no." This specifies whether remote hosts will be allowed to connect to locally forwarded ports. See the later section titled " Getting Out " and the entry for LocalForward.
KeepAlive	Argument must be "yes" or "no"; defaults to "yes." This specifies whether the client and the server will send periodic "keep-alive" message to one another. If a keep- alive gets no response, the connection is dropped. Usually this is desirable, since it allows either or both ends to clear their sessions if there is a loss of connectivity. This may be undesirable on a low-reliability network, since the login session and all forwarded connections and X11 windows will close.
LocalForward	See the later section, Getting Out. This command allows a port on the local (client) machine to be "forwarded" over the encrypted link to a given host and port from the remote (server) machine. This is a secure "outbound tunnel." Let's consider an example. Suppose you work for a consulting firm and you need to visit the company Web site from time to time, but company private information is kept there. You are only supposed to access it from internal machines. Well, if you have an SSH server running on your company's internal network, it is no problem. Put an entry like LocalForward 2080 intranet.bodyshop.com:80 in your .ssh/config file. When you SSH to your SSH server (perhaps secure.bodyshop.com ?), you will find it opens a socket on the client machine on port 2080. If you point your browser at localhost:2080, you will actually connect to port 80 on intranet.bodyshop.com . Not only that, but the connection will appear to come from secure.bodyshop.com , not from your client machine. Moreover, anyone looking at the network the client is on will just see more gibberish traffic over the single SSH connection you have open! That's right. The login shell, the X11 forwards, and the forwarded ports are all passed encrypted over the one open connection. Now you can see what the GatewayPorts option is for: When off, it prevents someone on any host other than the client from connect ing to port 2080 on the client and getting sent through to intranet.bodyshop.com . There may be times when you do want to let others share the hole you open, but generally not. That's why that option defaults to "off."
Port	Specifies the port to connect to on the SSH server. Default is 22. See the later section, Maniacally Restrictive Firewalls, for more information on the use of this option.
RemoteForward	See the later section Getting In. This option is the comple ment of LocalForward. This option takes a port number to use on the server side and specifies a host and port to connect from the client. An example may make this clearer. Suppose that, in order to support the software Bodyshop.com has developed for a client, they need access to Telnet on a certain internal server. Let's even assume that the server has no name and is on a purely internal (10.x.x.x) network. Your client box can SSH to the outside (to secure.bodyshop.com ) and can also reach the 10.x.x.x network. You put the option RemoteForward 5023 10.5.1.40:23 in your .ssh/options file. When you SSH to secure.bodyshop.com , you will find a LISTEN socket open on that host on port 5023. If you were on secure.bodyshop.com you could then execute telnet localhost 5023 and you would get the Telnet login prompt from 10.5.1.40 on the client network! Again, just as with the LocalForward scenario, the connection to 10.5.1.40 would appear to be coming from the SSH client machine and not from secure.bodyshop.com . Moreover, anyone sniffing anywhere from the client's firewall all the way back to bodyshop.com would see no Telnet traffic at all, but, rather, additional gibberish over the one open SSH connection. Together LocalForward and Remote Forward practically eliminate the need for any other type of Virtual Private Network.
RSAAuthentication	Argument must be "yes" or "no." So far, all of our examples have used traditional password authentication. SSH can use many alternative methods of authentication. See the later section, Alternate Authentication Methods for details on this and some passing mention of still other methods SSH supports.
UsePrivilegedPort	See the later section Maniacally Restrictive Firewalls for details on this option.
User	Normally, SSH will try to connect to the specified host with the same username as the user running the SSH client on this host. But what if you have different usernames on different systems? You can specify the username on the SSH command line, but it is nice not to have to remember to do so. Use this option to specify your username on a given host.

There are many more options. Take a look at the SSH man pages for more details. This is quite enough to be getting on with for now.

There is also a configuration file for the SSH server. This is usually in /etc/ssh/sshd_config. We'll take a look at some of the more interesting server options in the next table.

SSH CLIENT OPTIONS

Attribute	Description
AllowUsers	This allows you to restrict secure login to a list of users. By default, login is allowed for all users defined on the box. This keyword may be followed by a white space “separated list of names . The "*" and "?" wildcards are allowed.
DenyUsers	This command also allows you to restrict who may log in. Where AllowUsers allows only matching users in, DenyUsers allows everyone except matching users.
GatewayPorts	Specifies whether remote users (users connecting from other hosts) may use ports forwarded from this host by sshd for SSH clients . Unless you absolutely need this, I strongly recommend against setting this to "yes." If your server is on the "outside" (by which I mean on an unsecured public network) and you use an SSH client to forward a private port from the "inside" (by which I mean a secured private network) to the server box, you expose the port to the entire Internet! The one case where this makes sense to me is where the port you are forwarding to the outside from the inside is an sshd server port. Then it does not (in theory) decrease security to allow access to the port from the whole Internet, since you will still be using an encrypted and cryptographically authenticated connection end to end. Argument must be "yes" or "no"; defaults to "no."
ListenAddress	Specifies which local address SSHD should listen on. On a multihomed host (a host with more than one network interface and/or more than one address per interface), the default is to accept connections from all local addresses. You may wish to restrict access to a certain interface. For example, you might configure one SSHD server with a certain set of options to listen only to the public network interface while configuring another SSHD server instance with a totally different set of options (perhaps less restrictive) to listen only to the internal network interface. This option must be preceded by the Port option.
PasswordAuthentication	Specifies whether an SSH client may connect to a user's account using only that user's password. So far we have shown you only this form of authentication. For most purposes, this is sufficient. If you presently use Telnet, you are so exposed to attack that simply replacing Telnet with SSH will dramatically increase your security. There are other methods of authentication that are much more secure. You might choose to use those. Argument must be "yes" or "no"; defaults to "yes."
PermitEmptyPasswords	When password authentication is allowed, this specifies whether or not login to accounts without passwords is permitted. Argument must be "yes" or "no"; defaults to "no." Never set this to "yes."
PermitRootLogin	This determines whether or not one may SSH into the root account. Argument may be "yes," "without-password," or "no." The "without-password" option disables password login for root while still allowing it for other users (depending on the setting of PasswordAuthentication, of course). With that setting, some other form of authentication must be used for root login. Defaults to "no." Leave this set to "no." There are other ways to gain root privilege after establishing a secure encrypted connection to an unprivileged account.
Port	Specifies the port to listen on. More than one port directive may appear.
RSAAuthentication	Specifies whether pure RSA authentication is allowed. Must be "yes" or "no"; defaults to "yes." See the later section on " Alternate Authentication Methods " for details.
StrictModes	Specifies whether sshd should check permissions and modes on user SSH files before allowing login. This is a good idea, since some users leave critical files writeable, such as the key file, which totally destroys the security of the system.
X11Forwarding	Specifies whether or not X11 forwarding is permitted. Must be "yes" or "no"; defaults to "no."

As with the client options list, this is not a complete list of all the options, nor does it fully document all of the aspects of the options described. Be sure to take a look at the man pages to get the full picture.