Compatibility Between SSH-1 and SSH-2 Servers

OpenSSH supports both the SSH-1 and SSH-2 protocols within a single daemon accepting both types of connections. The Protocol keyword can be used to limit the support to either protocol exclusively. [5.3.7]

For Tectia, however, the story is more complicated. The Tectia server itself only supports the SSH-2 protocol, but it can accept connections from clients that request the older SSH-1 protocol. This backward compatibility is achieved by having the Tectia server run some other server program for the SSH-1 protocol instead, whenever an SSH-1 connection is requested. This feature is enabled and disabled with the Tectia Ssh1Compatibility keyword, given a value of yes or no (the default):

    # Tectia
    Ssh1Compatibility yes

When Ssh1Compatibility is enabled, and an SSH-1 client connects to the Tectia server, the two programs exchange strings indicating their versions. [3.6.3] sshd (also known as sshd2, see the sidebar "Tectia's File-Naming Conventions" [5.1]) then locates the sshd1 executable by examining the value of the Sshd1Path keyword:

    # Tectia
    Sshd1Path /usr/local/sbin/sshd1

and invokes sshd1. The Tectia server adds the -i option [5.3.3.2] to the sshd1 command line to indicate that the client connection has already been accepted by Tectia, and sshd1 should expect the socket to be attached to its standard input, output, and error streams. In addition, the Tectia server passes the client's version string using the (mostly undocumented) -V command-line option:

    # Tectia, invoked automatically by sshd
    /usr/local/sbin/sshd1 -i -V "client version string" <other arguments>

Tip

Although sshd2 can accept and reroute SSH-1 client connections, the reverse isn't true: sshd1 can't accept SSH-2 connections.

The -V command-line option is supported by sshd1 implementations for internal use only by sshd2. It is necessary because when sshd1 starts this way, the client has already sent its initial version announcement, which sshd1 needs to get somehow. We can't think of any practical reason to use this option manually, but we mention it here for completeness.

The OpenSSH server also implements the -V option, so you could use OpenSSH to handle SSH-1 protocol connections that are delegated from Tectia in its backward-compatibility mode. Be sure to set OpenSSH's Protocol keyword value to 1 to force protocol SSH-1.

Warning

Unfortunately, Tectia's SSH-1 compatibility mode is scarcely supported by other SSH implementations. Only OpenSSH versions earlier than 3.7 understand the -V option. An alternative is to use the latest implementation of SSH1--the original SSH product—which is still available from ftp://ftp.ssh.com/pub/ssh/, but it is ancient and no longer actively maintained.

Most other command-line options are passed on from sshd2 to sshd1 without modification. Specifically, the Tectia server leaves the following options untouched: -b, -g, -h, -k, -p, -q, and -i. The -d option [5.9] is passed to sshd1, but the debug level argument is removed, since it is Tectia-specific. Similarly, the argument for the -f option is unsuitable for sshd1, since it specifies an alternate configuration file, and the syntax for sshd2 and sshd1 configuration files isn't compatible. Therefore, if an sshd2 -f option is specified, then Tectia uses the Sshd1ConfigFile keyword to modify the argument for the -f option that is used for the sshd1 invocation:

    # Tectia
    Sshd1ConfigFile /usr/local/etc/sshd1_config

The Sshd1ConfigFile is only used if sshd2 was invoked with an explicit -f command-line option. Otherwise, no -f option is passed on the sshd1, and sshd1 uses its own default configuration file, just like sshd2.

All other sshd2 options are removed from the command line that is passed to sshd1.

Warning

Other command-line options besides -f can cause compatibility problems when they are passed on from sshd2 to sshd1. Some sshd2 options are not supported by all sshd1 implementations, and (even worse) some options with the same names have different interpretations. Be sure to carefully compare the sshd2 and sshd1 documentation for any options that are used. It is usually best to use keywords in different configuration files for sshd2 and sshd1 instead of command-line options in SSH-1 compatibility mode.

If SSH-1 compatibility mode is used, only the Tectia server should be started at boot time. sshd1 is then launched by sshd2 only when needed for SSH-1 connections.

5.10.1 Security Issues with Tectia's SSH-1 Compatibility Mode

There's one vital thing to keep in mind if you're using the SSH-1 compatibility feature in Tectia: you must maintain two separate SSH server configurations. When sshd2 starts sshd1, it is an entirely new process, with its own SSH-1 server configuration file. No restrictions set in your sshd2 server configuration apply to it. Even restrictions that could apply, such as AllowHosts, don't, because sshd2 invokes sshd1 before performing such checks.

This means you must keep the two configurations synchronized with respect to your security intent. Otherwise, an attacker can circumvent your carefully crafted sshd2 configuration simply by connecting with an SSH-1 client.

A good strategy for automating the synchronization of sshd2 and sshd1 configurations is to derive the configuration files from a common template file, using a general-purpose macro preprocessor like m4. The following list describes the basic idea.

Invent symbols like TECTIA and OPENSSH to label the implementations for the sshd2 and sshd1 configurations.
Construct the template file using m4 preprocessor conditionals like ifdef to handle incompatibilities between sshd2 and sshd1, such as syntax differences:
```
    ifdef(TECTIA, 'DenyGroups bad.*, worse')
    ifdef(OPENSSH,'DenyGroups bad* worse')
```
The template file helps to maintain the configurations because similar constructs are kept together, and duplicate information is minimized. Any common keywords and values can be specified in the template file without conditionals.
Generate the sshd2 and sshd1 configurations from the template by defining the appropriate implementation symbols on the command line using the m4 preprocessor:
```
    m4 -DTECTIA sshd_config_template > sshd2_config
    m4 -DOPENSSH sshd_config_template > sshd1_config
```

For even more automation, set up a Makefile containing targets for the sshd2 and sshd1 configuration files, with m4 preprocessor commands for each:

    all: sshd2_config sshd1_config
    sshd2_config: sshd_config_template
        m4 -DTECTIA $< > $@
    sshd1_config: sshd_config_template
        m4 -DOPENSSH $< > $@

To ensure that the real sshd2 and sshd1 configuration files are up to date whenever the template file changes, regenerating the configuration files if necessary, simply use the command make. This can be done at boot time before the Tectia server is started, or subsequently when the configuration file is reread using SIGHUP. [5.2.4]