Basic network access: clients

ssh tunnels

Tunneling is a technique for encapsulating an IP connection inside another IP connection. Why would you want to do that? One reason is to add encryption to an otherwise unencrypted connection, such as telnet or POP. Another is to get access to a service on a system that does not generally supply this service to the Internet.

Let's consider using http first. Assume you are travelling, and you want to access your private web server back home. Normally a connection to the http port of http://presto.example.com might have the following parameters:

Рис. 24.1.

But what if the server is firewalled from the global Internet, so you can't access it directly? That's when you need the ssh tunnel. The ssh tunnel creates a local connection at each end and a separate secure connection across the Internet:

Рис. 24.2.

The ssh connection is shown in fixed italic font. It looks just like any other ssh connection. The differences are the local connections at each end: instead of talking to presto port 80 (http), you talk to port 4096 on your local machine. Why 4096? It's your choice; you can use any port above 1024. If you're on andante, you can set up this tunnel with the command:

$ ssh -L 4096:presto.example.org:80 presto.example.org

To do the same thing from the presto end, you'd set up a reverse tunnel with the –R option:

$ ssh -R 4096:presto.example.org:80 andante.example.org

These commands both set up a tunnel from port 4096 on andante to port 80 on the host http://presto.example.org. You still need to supply the name of the system to connect to; it doesn't have to be the same. For example, you might not be able to log in to the web server, but you could access your machine back home, and it has access to the web server. In this case, you could connect to your machine at home:

$ ssh -L 4096:presto.example.org:80 freebie.example.org

In addition to setting up the tunnel, ssh can create a normal interactive session. If you don't want this, use the -f option to tell ssh to go into the background after authentication. You can also specify a command to execute, but this is no longer necessary for protocol version 2. If you don't want to execute a command, use the -N option:

$ ssh -L 4096:presto.example.org:80 presto.example.org -f –N

If you're running protocol version 1, you can use sleep with an appropriately long timeout, in this example 1 hour:

$ ssh -L 4096:presto.example.org:80 presto.example.org -f sleep 3600

Tunneling X

Running X clients on the remote machine is special enough that ssh provides a special form of tunneling to deal with it. To use it, you must tell ssh the location of an .Xauthority file. Do this by adding the following line to the file ~/.ssh/environment:

XAUTHORITY=/home/yourname /.Xauthority

The name must be in fully qualified form: ssh does not understand the shortcut ~/ to represent your home directory. You don't need to create ~/.Xauthority, though: ssh can do that for you.

Once you have this in place, you can set up X tunneling in two different ways. To start it from the command line, enter something like:

$ ssh -X -f website xterm

As before, the -f option tells ssh to go into the background. The -X option specifies X tunneling, and ssh runs an xterm on the local machine. The DISPLAY environment variable points to the (remote) local host:

$ echo $DISPLAY
localhost:13.1

Other uses of tunnels

Tunneling has many other uses. Another interesting one is bridging networks. For example, http://unix.za.net/gateway/documentation/networking/vpn/fbsd.html describes how to set up a VPN (Virtual Private Network) using User PPP and an ssh tunnel.

Configuring ssh

It can be a bit of a nuisance to have to supply all these parameters to ssh, but you don't have to: you can supply information for frequently accessed hosts in a configuration file. On startup, ssh checks for configuration information in a number of places. It checks for them first in the command line options, then in you configuration file ~/.ssh/config, and finally in the system-wide configuration file /etc/ssh/ssh_config. The way it treats duplicate information is pretty much the opposite of what you'd expect: unlike most other programs, options found in a configuration file read in later do not replace the options found in an earlier file. Options on the command line replace those given in configuration files.

In practice, such conflicts happen less often than you might expect. The file /etc/ssh/ssh_config, the main configuration file for the system, normally contains only comments, and by default you don't even get a local ~/.ssh/config.

sshconfig can contain a large number of options. They're all described in the man page ssh_config(8) ,but it's worth looking at some of the more common ones. In this section we'll look at some of the more common configuration options.

• The entry Host is special: the options that follow, up to the end of the file or the next following Host argument, relate only to hosts that match the arguments on the Host line.
• Optionally, ssh can compress the data streams. This can save a lot of traffic, but it can also increase CPU usage, so by default it is disabled. You can do this by passing the -C flag to ssh, but you can also do so by setting Compression yes in the configuration file.
• You can escape out of an ssh session to issue commands to ssh with the EscapeChar. By default it's the tilde character, ~ Other programs, notably rlogin, use this character as well, so you may want to change it. You can set this value from the ssh command line with the -e option.
• To forward an X11 connection, as shown above, you can also set the ForwardX11 variable to yes. This may be useful if you frequently access a remote machine and require X forwarding. This also sets the DISPLAY environment variable correctly to go over the secure channel.
• By default, ssh sends regular messages to the remote sshd server to check if the remote system has gone down. This can cause connections to be dropped on a flaky connection. Set the KeepAlive option to no to disable this behavior.
• Use the LocalForward parameter to set up a tunnel. The syntax is similar to that of the -L option above: on andante, instead of the command line:

  $ ssh -L 4096:presto.example.org:80 presto.example.org
  

  You would put the following in your ~/.ssh/config:

  host presto.example.org
  LocalForward 4096 presto.exanple.org:80
  

  Note that the first port is separated from the other two parameters by a space, not a colon.
• Similarly, you can set up a reverse tunnel with the RemoteForwar parameter. On presto, instead of the command line:

  $ ssh -R 4096:presto.example.org:80 andante.example.org
  

  you would put the following in your ~/.ssh/config:

  host andante.example.org
  RemoteForward 4096 presto.example.org:80
  
• By default, ssh uses password authentication if it can't negotiate a key pair. Set PasswordAuthentication to no if you don't want this.
• Normally ssh connects to the server on port 22 (ssh). If the remote server uses a different port, specify it with the Port keyword. You can also use the -p option on the ssh command line.
• By default, ssh attempts to connect using protocol 2, and if that doesn't work, it tries to connect using protocol 1. You can override this default with the Protocol keyword. For example, to reverse the default and try first protocol 1, then protocol 2, you would write:

  Protocol 1,2
  
• By default, ssh refuses to connect to a known host if its key fingerprint changes. Instead, you must manually remove the entry for the system from the ~/.ssh/known_hosts or ~/.ssh/known_hosts2 file. This can indicate that somebody is faking the remote machine, but more often it's because the remote machine has really changed its host key, which it might do at every reboot. If this gets on your nerves, you can add this line to your configuration file:

  StrictHostKeyChecking no
  

  This doesn't stop the warnings, but ssh continues:

  @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
  @    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!    @
  @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
  IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
  Someone could be eavesdropping on you right now (man-in-the-middle attack)!
  It is also possible that the DSA host key has just been changed.
  The fingerprint for the DSA key sent by the remote host is
  95:80:4c:fb:cc:96:1b:36:c5:c9:2b:cb:d1:d4:16:68.
  Please contact your system administrator.
  Add correct host key in /home/grog/.ssh/known_hosts2 to get rid of this message.
  Offending key in /home/grog/.ssh/known_hosts2:39
  
• ssh assumes that your user name on the remote system is the same as the name on the local system. If that's not the case, you can use the User keyword to specify the remote user name. Alternatively, you can use the format:

  $ ssh newuser@remotehost.org