9. Tips and Tricks of Secure Shell

This section gives you some tips from folks out there who have found some cool ways to get Secure Shell working in their environment. Click here for the contents of this section.

9.1 Making Secure Shell more transparent to users

Here is a simple script by Ross Golder to make using ssh more transparent. When you first login (open an Xterm etc.), you'll be prompted for your passphrase. After that, it will automatically configure your environment to the ssh-agent it started.

When logging out of a multi-user machine, I just use a 'killall ssh-agent' (not as root!).

Install the following file as $HOME/.ssh/setup and set the execute permission (chmod 700 setup), and add a call to it in your $HOME/.bashrc.

# This script is intended to reside in your ~/.ssh directory (don't
# forget to 'chmod 700'), and be included in your shell init script.
# It works by checking for a working ssh agent, otherwise it starts one
# and requests the passphrase.
# If used on a network-connected machine that is up 24/7, you should
# take care to kill your agent when you leave your machine, using
# "eval `ssh-agent -k`".
# For bash and ksh users:
# include the following in your ~/.bashrc or ~/.kshrc or ~/.profile
#       . $HOME/.ssh/setup
# For csh and tcsh users:
# include the following in your ~/.cshrc or ~/.tcshrc
#       source $HOME/.ssh/setup

# Configuration #

# Enable this if using you have GNOME and the following program.

# If using NFS-based home directories, you probably should specify one
# main workstation here, otherwise it could cause mayhem.

# End of configuration #

function start_agent {
	echo "Initialising new Secure Shell agent..."
	ssh-agent | head -2 > ${SSH_ENV}
	chmod 600 ${SSH_ENV}
	. ${SSH_ENV} > /dev/null
	ssh-add  /dev/null
	ps ${SSH_AGENT_PID} > /dev/null || {

9.2. How do I find out which version of Secure Shell is running at the remote end?

The simpliest way is to do a telnet hostname 22.

The response you get is something like SSH-[1.99]-2.x.x for a version 2 server and SSH-[1.5]-1.x.x for a version 1 server.

Connected to hostname.example.com.
Escape character is '^]'.
SSH-1.99-2.1.0.pl2 SSH Secure Shell

9.3. How do I get SSH2 to compile on a MacOSX server?

(Contributed from Dorian Moore) Here's what I had to do:

# untar ssh1
# cd  
# cp /usr/libexec/config.* . 
# ./configure --host=nextstep --disable-asm 
# mv gmp-2.0.2-ssh-2/gmp-impl.h gmp-2.0.2-ssh-2/gmp-impl.h.old 
# sed "s/\!defined(NeXT)/defined(NeXT)/g" gmp-2.0.2-ssh-2/gmp-impl.h.old > \
# make 

And it seems to work fine, though the make install doesn't work. I don't know if there is a way of patching the makefile to do the above changes, as thats not really my area.

Credit for this info goes to Joshua Marker (lux@umich.edu) and I found the info via:


9.4. Running SSH2 With SSH1 Compatibility

Since there are many folks still running SSH1, many people want to run SSH2. Even though the protocols are incompatible, you can set up "compatibility" with SSH1 and SSH2--so SSH2 forwards the SSH1 connections to the sshd1.

9.4.1 What Is SSH1 Compatibility?

The SSH1 and SSH2 protocols are not compatible. This means that SSH1 clients cannot connect to a SSH2 daemon. However, the SSH2 daemon can be configured to start up a SSH1 daemon when it receives a connection from a SSH1 client. This allows both SSH1 and SSH2 clients to connect to such a Secure Shell daemon. The process of handing off to a SSH1 daemon is transparent to the end user.

9.4.2 Setting Up Compatibility

By default, SSH2's ./configure process will look for a compatible SSH1 and will build itself with support for SSH1 compatibility. This means that if you want to set up SSH2 with SSH1 compatibility on a machine that' s not running any Secure Shell at all, you should install SSH1 first so that SSH2's configure process will find it.

If you are already running SSH2 and you want to add in SSH1 compatibility, it is not necessary to rebuild SSH2. Build and install SSH1. Then, in the sshd2_config file, make sure that the "Ssh1Compatibility" variable is set to "yes" and that the "Sshd1Path" variable is set to the path to your sshd1 binary. Example:

	Ssh1Compatibility	yes
	Sshd1Path	"/usr/local/sbin/sshd1"
Be careful about the "sshd" symbolic link. The installation process for both SSH1 and SSH2 changes the sshd symbolic link to point to their binary, either sshd1 or sshd2. If you run your Secure Shell daemon as "sshd", make sure that the symbolic link is correct so that the right daemon is being started!

A Note on Startup Performance

When a SSH1 request comes in, a SSH1 daemon is started up at that time to process the incoming connection. Because the SSH1 daemon has to initialize itself at that time, the initial connection for SSH1 clients can take longer than if the SSH1 server were running as a standalone daemon. The effect is much the same as running the SSH1 daemon via inetd, which is discussed elsewhere in section 4.6.

Making Changes to the sshd_config File

Since the SSH1 daemon is started up with every connection, it will reread the sshd_config file with each new connection. If the sshd_config file is modified, there is no need to HUP the SSH2 daemon to make the SSH1 daemon see the changes.

9.4.3 About TCP Wrappers and SSH1 Compatibility

The SSH2 daemon answers the incoming requests. As such, the tcpwrapper entries pertaining to your SSH2 daemon prevail and any such entries pertaining to your SSH1 daemon aren't processed at all.

For example, if you had these entries in your /etc/hosts.allow file, then SSH1 connections would in fact be allowed from the entire subnet because it is the sshd2 that answers the incoming request.

	# Allow SSH1 only from a specific computer
	# Allow SSH2 from the entire subnet

9.4.4 Authentication in Compatibility Mode

The SSH2 daemon handles the incoming connection, including tcpwrapper processing. After that point, it hands off to the SSH1 daemon. This means that the SSH1 daemon handles authentication for SSH1 clients, and the SSH2 daemon handles authentication for SSH2 clients.

This means that if a SSH1 client is trying to use hostbased or publickey authentication, the SSH1 daemon must be properly configured to handle those requests. The SSH2 daemon doesn't need to be configured to handle those requests at all (in fact, those authentication methods could be disabled in the SSH2 daemon), unless such requests will be coming from SSH2 clients.

9.4.5 How do I get hostbased authentication to work with SSH2 and SSH1?

Below is a stepwise HOWTO for setting up hostbased authentication for SSH1 or SSH2 or SSH2 with SSH1 compatibility. Also included are some notes on using SSH2 with SSH1 compatibility.

Note that, before SSH 2.1.0.pl2, hostbased authentication does not work properly on a Solaris 2.6 server if libwrap support is compiled into the ssh daemon. For older version fo the ssh daemon, a workaround using SSH2 with SSH1 compatiblity is discussed below.

Here, I'll use the following terms:

As an example, our backups are done via username "backup" on host Tapeserv. On our Authserv server, user "root" is trying to connect to Tapeserv to make Authserv's backups on Tapeserv's tape drive. This means that the Server is Tapeserv, the ServerUser is backup, the Client is Authserv, and the ClientUser is "root".

Step 1.

Of course, install Secure Shell on the Server and Client machines.

Step 2 - SSH1.

On the Client, cat the file /etc/ssh_host_key.pub and copy-n-paste it into Notepad or some other text editor. It will look something like this:

     1024 35 1255908028087833976430... root@authserv
(the actual number will be much longer)
Remove the root@Client from the end and add the Client hostname to the beginning:

     authserv 1024 35 1255908028087833976430...
Then copy-n-paste this single, very long line into Server's /etc/ssh_known_hosts file.

This gives the Server the Client's public key so the Server can verify the Client's identity based on a public key signature. By contrast, rsh only uses the IP address for authentication.

Step 3 - SSH2.

Copy the Client's /etc/ssh2/hostkey.pub file over to the Server and name it /etc/ssh2/knownhosts/authserv.ssh-dss.pub

Of course, since your host isn't named Authserv, use your own hostname. Generally, you'll want to use the "short" hostname and not the fully qualified hostname.

This gives the Server the Client's public key so the Server can verify the Client's identity based on a public key signature. By contrast, rsh only uses the IP address for authentication.

Step 4.

On the Server, create a file in the ServerUser's home directory named ".shosts". The contents of this file should be the Client hostname, some tabs or spaces, and the ClientUser username.

For example, to allow root@Authserv to log into backup@Tapeserv, I'd place this .shosts file into backup's home directory on Tapeserv:

authserv      root

Be sure to chown and chmod the .shosts file. The .shosts file must be owned by the remote user and should be mode 0400.

Step 5 - SSH1.

Make sure that this line exists in /etc/sshd_config:

     RhostsRSAAuthentication yes
This enables the SSH1 daemon to do what we need it to do.

For safety, you may also want to verify this line:

     RhostsAuthentication no
This disables the use of rhosts-style authentication without corresponding public key authentisation.

If you had to modify the sshd_config file, you have to HUP the sshd to make the change take effect.

Step 6 - SSH2.

Check the file /etc/ssh2/sshd2_config and make sure that AllowedAuthentications contains the word "hostbased" For example, it may read:

     AllowedAuthentications     hostbased,password
If you had to modify the sshd2_config file, you'll have to HUP the sshd to make the change take effect.

Step 7.

You should be all set.

On the Client, log in as the ClientUser and try this:

     ssh ServerUser@Server uptime
You should get back the results of "uptime" run on the remote server.

The first time you run ssh to that particular server, you'll have to answer "yes" when asked if you want to connect to the server. This is because the local ssh doesn't yet have the remote server's Secure Shell public key. This will only hapen the first time.

Common Pitfalls

Did you copy the hostkey properly? Did it get mangled when you copied it over?

With SSH2, did you name the hostkey file appropriately? It should be /etc/ssh2/knownhosts/HOSTNAME.ssh-dss.pub and HOSTNAME may need to be the short hostname or the long hostname.

Check your spelling in the .shosts file

Is the .shosts file owned by the ServerUser?

Try running the server with the -v flag (for SSH2) or the -d flag (for SSH1) and see if anything useful is generated. This is a great way to see if a hostkey file is missing.

About SSH1 and SSH2 Compatibility

At our site we use SSH2 with password-based authentication for interactive sessions. Because hostbased authentication doesn't work with SSH2 on Solaris, we installed SSH2 with SSH1 compatibility and we use SSH1 for noninteractive hostbased-authenticated backups. It is important to note that it is SSH1 and not SSH2 which handles the hostbased sessions, which means the following:

| Previous Chapter | | Next Chapter |

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

This SSH FAQ mirror is made available by Brian Hatch and Onsight, Inc. Contact the FAQ maintainers if you have changes or comments on this material.