5. Secure Shell and other applications

This section gives you some information on how getting Secure Shell to work with other applications. Click here for the contents of this section.

5.1. Can I run backups over ssh?

Yes. The easiest possible way to do this is:

# tar cvf - | ssh user@host "dd of=/dev/tape"

Since ssh is a drop-in replacement for rsh, backup scripts should continue to work. You can use datbkr by David Cinege, which uses Secure Shell to do backups over an Secure Shell connection. You can get datbkr at http://www.psychosis.com/datbkr.

You can also use rdist and rsync, which there is more information at below.

5.2. Can I use ssh to communicate across a firewall?

Yes. All you need is an open port on the firewall and the sshd or sshd2 listening on the other side.

Most people do this on port 22 (the standard port for Secure Shell), but if you have a BOFH, you can also tunnel through another open port through the firewall (I'm sure all those system admins love me now :-) by running a daemon on the remote side on a port that's allowed through a firewall, like SSL (port 443).

Set up the remote daemon running sshd on port 443:

# sshd -p 443

Then, on your local system, open a connection on port 443:

$ ssh -p 443 remotehost.example.org

You can also use Secure Shell to tunnel insecure traffic like POP, IMAP, and others through the firewall as well.

5.3. Can I use rdist or rsync with ssh?

Yes.

If you use rdist, don't forget to compile the path to ssh into it. Alternatively, you may specify the -P option so rdist uses ssh, and not rsh.

If you use password authentication with rdist 6.1.2 through 6.1.5, you will need to apply the following patch to rdist to make it work:

--- src/rshrcmd.c.orig  Tue Jun 11 16:51:21 1996
+++ src/rshrcmd.c       Tue Jun 11 16:52:05 1996
@@ -63,7 +63,7 @@
                /* child. we use sp[1] to be stdin/stdout, and close
                   sp[0]. */
                (void) close(sp[0]);
-               if (dup2(sp[1], 0) < 0 || dup2(0,1) < 0 || dup2(0, 2) < 0) {
+               if (dup2(sp[1], 0) < 0 || dup2(0,1) < 0) {
                        error("dup2 failed: %s.", SYSERR);
                        _exit(255);
                }
This also applies if you get a "Warning: Denied agent forwarding because the other end has too old version." error (which occurs if your client is 1.2.17 or later, and it connects to an older server).

Another alternative would be to use rsync, a rdist replacement, which was designed to work with ssh, and makes better use of bandwidth. More information can be found at http://rsync.samba.org/rsync. You can use the --rsh=/usr/local/bin/ssh option to use Secure Shell as a transport.

5.4. Can I use ssh to securely connect two subnets across the Internet?

You can run PPP over a regular ssh connection. See http://www.inka.de/~bigred/sw/ssh-ppp-new.txt for a working solution. It's a good idea to enable compression for this. Another implementation of this is available at http://www.linuxdoc.org/HOWTO/mini/VPN.html.

However, this may cause problems for forwarding TCP connections, because both the TCP connection over which ssh runs and a TCP connection forwarded over the PPP/ssh tunnel may retransmit at the same time. In this case, it is better to use encrypted IP tunneling via UDP. A possible implementation of this is http://www.inka.de/~bigred/devel/cipe.html .

Also look into Magnus Lundström's replacement for ssh-ppp in C for Linux, which is now being ported to other OS's. See http://detached.net/vpnstarter. The vpnstarter is more reliable (and easier to set up) than ssh-ppp.

5.5. Can I use ssh to securely forward UDP-based services, such as NFS or NIS?

This is not currently implemented in SSH1 or SSH2.

However, there is a general working solution for RPC-based services. This project uses Secure Shell to increase the security of RPC-based services; so far this has been implemented for NIS and NFS.

You can download the latest version of this software from http://www.math.ualberta.ca/imaging/snfs/.
More information is available at ftp://ftp.tu-chemnitz.de/pub/Local/informatik/sec_rpc/README.RPC

5.6. Can I use ssh to protect services like FTP or POP?

If you want to avoid sending FTP passwords in cleartext over the net, you can use ssh to encrypt your command channel. This will still leave your data channel open to all attacks on TCP, and will not work through a firewall.

You can either use ftpsshd by Per-Erik Martin at http://www.docs.uu.se/~pem/hacks/ for SSH1, or you can do this by hand.

SSH1: Suppose you are on a host called myhost and want to initiate a ftp connection to ftphost. On myhost, you do

myhost$ ssh -L 1234:ftphost.example.com:21 ssh-server
This logs you on to ftphost and also forwards connections to 1234 on myhost to ftphost.

Note: You need to use -g if you're forwarding to localhost (SSH1 only).

Then, in another window, you do

myhost$ ftp localhost 1234
220 ftphost FTP server (Foonix 08/15) ready.
Name: (myhost:yourname):
331 Password required for yourname
Password:
230 User yourname logged in.
This works if the remote ftp daemon accepts PORT commands which specify a different host from the one the command channel appears to come from, and if the ftp client always uses PORT. This is true for vanilla UNIX ftp client and ftpd servers; it may not work for more advanced ftpds, such as wu-ftpd.

For servers which do not accept this, you can see wether you ftp client supports passive mode, and wether the ftp server accepts PASV.

Note, however, that unencrypted ftp data connections are still vulnerable to session hijacking and snooping.

SSH2: Just use sftp instead. :-)

For POP, Stephane Bortzmeyer (bortzmeyer@pasteur.fr) has written a script which protects the mail transfer and passwords ussing ssh. It requires no modification to existing POP servers or clients, and is available from ftp://ftp.internatif.org/pub/unix/gwpop/ .

Or, you can use similar means for secure POP:

myhost$ ssh -L 1234:popserver.example.com:110 ssh-server

Other services could be secured by similar means.

5.7. Can I use ssh across a Socks firewall?

Socks 4 and 5 support should work in 1.2.16 or later. Socks support in version 2.0.11 and later should work.

5.8. Is there ssh support for AFS/Kerberos?

There's two patches available for AFS in Secure Shell. See Section 6 of the Secure Shell FAQ.

5.9. Can I use TCP wrappers for added security on Secure Shell?

Yes, the Secure Shell daemon can use TCP wrappers. Unlike other tcpwrapped services, the Secure Shell daemon is NOT run via inetd and tcpd (doing that will give "packet too long" errors). TCP wrapper support (also called "libwrap support") is compiled into the sshd binary and the sshd runs as a standalone daemon.

To build Secure Shell with libwrap support, run ./configure with the --with-libwrap=PATH flag, where PATH is the full pathname to the libwrap.a file that you installed when you built the TCP wrappers. For example:

	./configure --with-libwrap=/usr/local/lib/libwrap.a
When you installed TCP wrappers, you should have kept the tcpd.h and libwrap.a files. Usually tcpd.h goes in /usr/local/include and libwrap.a goes in /usr/local/lib. By default, installing TCP wrappers doesn't install these two files, so you may need to grab the TCP wrappers source and recompile it, then install those two files.

In the /etc/hosts.allow and /etc/hosts.deny files, make an entry for the Secure Shell daemon. Be sure that the name of the service matches the name of the sshd binary you're running. e.g. If you run the daemon as "sshd2" then the service must be named "sshd2", and if you run it as "sshd" then the service name must be "sshd"

Here are some example hosts.allow entries. For more examples, check the hosts_access(5) man page that came with the TCP wrapper distribution.

# Example 1 - Allow Secure Shell from this one subnet
# Secure Shell daemon is started as /usr/local/sbin/sshd
sshd:	192.168.1.0/255.255.255.0

# Example 2 - Allow Secure Shell access from two subnets
# Secure Shell is started as /usr/sbin/sshd2
sshd2:	192.168.1.0/255.255.255.0 10.0.0.0/255.0.0.0

# Example 3 - Won't work because service name is wrong, unless
# you really start your daemon as ssh instead of sshd!
ssh:	10.0.0.0/255.0.0.0

See the TCP Wrappers documentation for more details.

5.10. How do I tunnel X through Secure Shell?

To configure the sources and create an Secure Shell build that supports X forwarding:

# ./configure --with-x

Run make and make install normally. You'll also want to make sure your configuration file is set properly. Note that this is the default, and you really do not need --with-w defined.

5.10.1 Basic configuration

For SSH1:
In /etc/ssh_config:
ForwardX11 yes

In /etc/sshd_config:
X11Forwarding yes

For SSH2:
In /etc/ssh2/sshd2_config:
ForwardX11 yes

Note that you do not have to change the /etc/ssh2/ssh2_config file. If you are running TCP Wrappers along with X forwarding, you need to make sure you add the necessary sshdfwd-X11: line in the /etc/hosts.allow file. This should not contain the host you are coming from.

You also do not need to open any additional ports. Everything is sent through port 22.

5.10.2 Can I configure XDM to go through Secure Shell?

It is not possible to forward XDMCP over ssh, because it uses UDP, not TCP. See section 5.5 of this FAQ.

In a nutshell: if you want the PC to look like an X terminal, you can't do this securely.

But maybe you'll be able to start dtwm manually after having logged in, if your X server on the PC allows you to use a window manager on the remote end instead of using Windows for that purpose. I seem to remember eXceed used to allow this, but it's a good while since I did anything with Windows, so I'm not so sure about the current breed.

Thanks to Atro Tossavainen for this information.

5.11. Can I forward SGI GL connections over ssh?

It is not likely that this will be implemented. GL uses a totally different protocol from X, and at least gld would have to be replaced.

OpenGL, when run as an X server extension, should pose no problem. You may need to set the environment variable GLFORCEDIRECT=no.

5.12. Does Secure Shell support digital certificates?

No, not currently. As digital certificates become more popular, Secure Shell will probably support digital certificates in the future.

5.13. Does Secure Shell work with PGP keys?

Only in SSH2. It's supported in release 2.0.13 or later.


| Previous Chapter | | Next Chapter |

| Table of contents of this chapter | | General table of contents | | Beginning of this section |