Installing Tectia

Tectia is a commercial implementation of the SSH-2 protocol, with some limited support for compatibility with the older (and deprecated) SSH-1 protocol. Binary distributions can be downloaded for evaluation (with a limited license that is valid for 30 days) from the SSH Communications Security web site:

http://www.ssh.com/

Fully licensed Tectia products, with distribution media and documentation, can be purchased from the same web site.

Tectia is designed for deployment across large corporate networks, and offers tremendous flexibility, power, and reliability. The products include:

4.3.1 Prerequisites

Tectia is fully self contained, and requires no other packages if installed on one of the supported platforms. Some configuration options require you to install other software packages, however; these are discussed below.

4.3.2 Obtaining and Extracting the Files

Binary distributions are packaged according to the target platform, and can be installed according to the documentation provided for each system.

Source distributions are packaged in gzipped tar format. For Version 4.1 and earlier, the sources are included with the distribution media for the Tectia Server for Unix product. Starting with Version 4.2, the sources are available only for commercial licenses and only upon request, via a protected area of the SSH Communications Security web site. No sources are provided for the Windows products.

To extract the files, use the tar command in the usual way. [4.1.4] The results are stored in a directory with a name like ssh-4.2.1.1-commercial.

4.3.3 Verifying with md5sum

Binary and source distribution files are protected from tampering by MD5 message digests. Each file is accompanied by a separate file with an extra .md5 suffix containing the digest.

To verify the integrity of the files, use the md5sum command to compute the digest, and compare the result to the contents of the corresponding .md5 file:

    $ md5sum ssh-4.1.0.34-commercial.tar.gz
    0c7be85eb79e80e893d4c258df8443f0  ssh-4.1.0.34-commercial.tar.gz
    $ cat ssh-4.1.0.34-commercial.tar.gz.md5
    0c7be85eb79e80e893d4c258df8443f0

Here's a brash one-liner for verification in a single step:

    $ md5sum ssh-4.1.0.34-1.i386.rpm | cut -c 1-32 | cmp - ssh-4.1.0.34-1.i386.rpm.md5

If the command succeeds silently, the message digests are equal.

Unfortunately, Tectia doesn't sign installers for binary package formats (like RPM) that support embedded signatures. MD5 message digests are provided for these installers, however.

4.3.4 Building and Installing

To build and install Tectia, use the standard steps that we have described previously: configure, make, and make install. [4.1.6] The following files are installed:

  • The server program sshd2, and a link to it called sshd.

  • The secure FTP server program sftp-server2, and a link to it called sftp-server.

  • The clients ssh2, scp2, and sftp2, and links to them called ssh, scp, and sftp, respectively.

  • Support programs ssh-add2, ssh-agent2, ssh-askpass2, ssh-keygen2, ssh-probe2, and ssh-signer2, and links to them called ssh-add, ssh-agent, ssh-askpass, ssh-keygen, ssh-probe, and ssh-signer, respectively.

  • The additional support programs sshd-check-conf and ssh-dummy-shell.

  • The standard crypto library libsshcrypto-std and the FIPS-compliant library libsshcrypto-fips if supported for the target system. The library filenames will have a platform-dependent suffix, e.g., libsshcrypto.a or libsshcrypto.so.

  • The ssh-crypto-library-chooser script used to switch between standard and FIPS mode. [5.3.5]

  • The password change plugin ssh-passwd-plugin [5.4.2.3] and (if configured) the SecurID plugins ssh-securidv4-plugin and ssh-securidv5-plugin. [5.4.5.2]

  • A newly generated host key pair, created by ssh-keygen2 and placed by default into /etc/ssh2/hostkey (private key) and /etc/ssh2/hostkey.pub (public key).

  • The server configuration file, /etc/ssh2/sshd2_config by default [5.2.1], plus sample subconfiguration files in /etc/ssh2/subconfig.

  • The client configuration file, /etc/ssh2/ssh2_config by default. [7.1.2]

  • The password plugin configuration file, /etc/ssh2/plugin/passwd_config. [5.4.2.3]

  • Manpages for the various programs.

4.3.5 Configuration Options

Tectia's configure script understands a wide variety of options to customize its operation. We cover the most significant ones.

    --prefix         Determine where to install the software

The make install command installs Tectia in the /usr/local directory by default. Programs that are normally run by users (e.g., ssh) are installed in the bin subdirectory, programs run by sysadmins (e.g., sshd) in the sbin subdirectory, manpages in the man subdirectory, etc. Use the --prefix option to specify a different parent directory, such as /usr/local/tectia:

    $ configure --prefix=/usr/local/tectia

If your system uses an unusual layout for specific subdirectories, options such as --bindir, --sbindir, and --mandir allow more precise control over the location of individual components. The configure --help command lists all of the options for the subdirectories.

    --with-foreign-etcdir        Specify directory for system configuration files
    --with-etcdir                Specify directory for Tectia configuration files

By default, Tectia assumes that the standard location for system configuration files is the /etc directory, and installs its own configuration files in a subdirectory, /etc/ssh2. To change the system configuration directory (continuing to use an ssh2 subdirectory for Tectia's files by default), use the --with-foreign-etcdir option:

    $ configure --with-foreign-etcdir=/usr/local/etc

To independently change Tectia's configuration directory, use the --with-etcdir option:

    $ configure --with-etcdir=/usr/local/etc/ssh2
    --with-piddir         Specify directory for pid files

The Tectia server stores its process ID (pid) in a file to facilitate sending signals. [5.3.1.3] By default, the pid file is created in the /var/run directory. Use the --with-piddir option to change this directory:

    $ configure --with-piddir=/var/local/pid

Tip

The --with-foreign-etcdir, --with-etcdir, and --with-piddir options are unusual because there are no corresponding "--without" options.

    --enable-suid-ssh-signer         Install ssh-signer setuid root
    --disable-suid-ssh-signer        Install ssh-signer unprivileged

Tectia uses a separate ssh-signer program to sign authentication packets for trusted-host authentication. Normally this program is installed with setuid root permissions so it can read the local host key file, which is readable only by the superuser.

You can install the program without setuid root permissions to eliminate possible security holes, but then hostbased authentication fails. [3.4.3.6]

    --with-ansi-rng         Use ANSI X9.62 random number generator
    --without-ansi-rng      Use SSH random number generator

Tectia uses its own random number generator by default. The --with-ansi-rng option configures Tectia to use the ANSI X9.62 random number generator (a.k.a. the Elliptic Curve Digital Signature Algorithm, or ECDSA) instead. This might be required for FIPS-standard compliance in some deployments.

    --with-ipv6         Include IPv6 support
    --without-ipv6      Remove IPv6 support

Tectia supports IPv6, the next generation of IP protocols, in addition to IPv4, the current standard. You can remove IPv6 support if you don't need it or if you experience problems with it on your operating system.

    --enable-tcp-nodelay        Enable Nagle Algorithm
    --disable-tcp-nodelay       Disable Nagle Algorithm

If you plan to operate Tectia over a wide-area network as opposed to a speedy Ethernet connection, you might consider disabling TCP/IP's NODELAY feature, a.k.a. the Nagle Algorithm, for SSH connections. The Nagle Algorithm reduces the number of TCP segments sent with very small amounts of data, such as the small byte sequences of a terminal session. You can disable it at compile time with the --disable-tcp-nodelay flag. Alternatively, you can enable or disable it during serverwide configuration using the NoDelay configuration keyword. [5.3.3.9]

    --with-libwrap        Include TCP-wrappers support
    --without-libwrap     Remove TCP-wrappers support

TCP-wrappers is a security feature for applying access control to incoming TCP connections based on their source address. [9.5] For example, TCP-wrappers can verify the identity of a connecting host by performing DNS lookups, or it can reject connections from given addresses, address ranges, or DNS domains. Although Tectia already includes some of this kind of control with features such as AllowHosts, DenyHosts, etc., TCP-wrappers is more complete. It allows some controls not currently implemented in any SSH version, such as restricting the source of forwarded X connections.

Tectia includes support for TCP-wrappers if the flag --with-libwrap is given at compile time. If the TCP-wrappers library and header file were not installed in the standard locations, provide a pathname as an argument. The pathname can refer to the library in a build directory:

    $ configure --with-libwrap=/var/tmp/build/tcp-wrappers/libwrap.a

in which case the tcpd.h header file is assumed to be located in the same directory. Alternately, the pathname can refer to the directory where the library was installed:

    $ configure --with-libwrap=/usr/local/lib

in which case the tcpd.h header file is assumed to be in a directory with its last component replaced by "include" (for the previous command, /usr/local/include).

If your Unix installation doesn't include the TCP-wrappers library, you can retrieve and compile it yourself from:

ftp://ftp.porcupine.org/pub/security/index.html

For more information on TCP-wrappers, read the manpages for tcpd and hosts_access.

    --with-ssh-connection-limit         Specify maximum number of simultaneous connections

You can instruct Tectia to limit the maximum number of simultaneous connections it supports. By default, it accepts an unlimited number of connections, but if you want to conserve resources on the server machine, you can set a limit. The appropriate flag is --with-ssh-connection-limit with a nonnegative integer argument; for example:

    $ configure --with-ssh-connection-limit=50

You can override this value at runtime with the serverwide configuration keyword MaxConnections. [5.3.3.7]

    --with-x        Include X Window System support
    --without-x     Remove X Window System support

If you plan to use SSH to communicate between hosts running the X Window System, make sure to include support for X at compile time. (By default, it is included.) Conversely, if you never have anything to do with X, you can leave out the support, thereby saving some memory and disk space. Few people have a strong need to eliminate X support.

    --enable-X11-forwarding        Enable X forwarding
    --disable-X11-forwarding       Disable X forwarding

These options enable or disable support for X forwarding, which allows X applications opened on the SSH server machine to appear on the SSH client machine's display. [9.4] These flags set Tectia's default behavior only. X forwarding can be further enabled or disabled through serverwide configuration using the ForwardX11 configuration keyword. [9.4.3]

    --with-x11-security        Use the X SECURITY extension
    --without-x11-security     Don't use the X SECURITY extension

By default, Tectia uses the X SECURITY extension (if supported by your X installation) to control the level of display access granted to X clients through forwarded connections. The --without-x11-security option causes Tectia to treat all X clients as trusted, which grants full access to the display. Trusted X clients can use their display access to capture information from other clients, so you should carefully consider the ramifications of disabling the X SECURITY extension.

    --enable-tcp-port-forwarding        Enable port-forwarding support
    --disable-tcp-port-forwarding       Disable port-forwarding support

Port forwarding enables Tectia to encrypt the data passing through any TCP/IP-based program. [9.2] This feature can be disabled at compile time if desired. X Window forwarding isn't affected by these general port-forwarding flags.

    --with-rsa         Include support for RSA encryption
    --without-rsa      Remove support for RSA encryption

By default, Tectia includes an implementation of the RSA encryption algorithm for public-key authentication. [3.8.1.1] You can remove support for RSA if you'll never need it. The option was formerly used to avoid infringing a patent that expired in 2000. Now that the algorithm is in the public domain, it is rarely desirable to remove RSA support.

    --with-passwd-plugin        Include support for password-change plugins
    --without-passwd-plugin     Remove support for password-change plugins

Tectia can run a separate password-change plug-in program to manage the process of changing expired passwords during authentication. [5.4.2.3] The configuration option --with-passwd-plugin includes support for this mechanism in the server, and also builds a generic plugin named ssh-passwd-plugin. The option --without-passwd-plugin can be used to remove these features if they are not needed.

    --enable-server-kbd-interactive        Include support for keyboard-interactive authentication in the server
    --disable-server-kbd-interactive       Remove support for keyboard-interactive authentication from the server
    --enable-client-kbd-interactive        Include support for keyboard-interactive authentication in the client
    --disable-client-kbd-interactive       Remove support for keyboard-interactive authentication from the client

Keyboard-interactive authentication is an extensible, general-purpose mechanism for implementing a variety of authentication techniques that require interaction with the remote user. Support for keyboard-interactive authentication is included by default, but it can be removed from the Tectia server and client using separate configure options.

Note that other authentication techniques such as SecurID and PAM are based on keyboard-interactive authentication, so if you remove support for it, these techniques will not work.

    --with-serversecurid                   Include support for SecurID authentication

SecurID is an authentication mechanism in which users carry electronic cards, approximately the size of a credit card, that display randomly changing integers. During authentication, the user is prompted to type whatever number appears on the card at the time, in addition to a username and password.

To compile Tectia with SecurID support, use the flag --with-serversecurid, providing the path to the directory containing SecurID's header files and libraries:

    $ configure --with-serversecurid=/usr/local/ace

SecurIDv5 is the most recent version at press time.

    --enable-serversecurid-submethod        Include SecurID support in the server
    --disable-serversecurid-submethod       Use an external plugin for SecurID support

By default, SecurID support is built into the Tectia server, and is used as a keyboard-interactive submethod. Alternately, SecurID can be supported by an external program, ssh-securidv5-plugin. [5.4.5.2]

--with-serversecuridv4

Include support for SecurIDv4 plugin authentication

Support for the older SecurIDv4 can be included by specifying the --with-serversecuridv4 option. The SecurIDv4 installation directory must be provided as an argument:

    $ configure --with-serversecuridv4=/usr/local/ace4

    --enable-legacy-securid         Include support for old SecurID clients

Very old SecurID clients can be supported by a legacy securid-1@ssh.com keyboard-interactive submethod.

    --with-daemonpam           Include support for PAM authentication in the server
    --without-daemonpam        Remove support for PAM authentication from the server
    --with-clientpam           Include support for PAM authentication in the client
    --without-clientpam        Remove support for PAM authentication from the client

Normally PAM support is included for both the SSH server and client if it is provided by the target system. This support can be removed using separate options for the server or client, but it is rarely desirable to do so.

    --with-daemon-pam-service-name         Specify PAM service name

By default, Tectia uses "sshd2" as the PAM service name: this refers to Tectia in the PAM configuration files. You can change the name by providing it as an argument for the --with-daemon-pam-service-name option:

    $ configure --with-daemon-pam-service-name=tectia

    --with-pgp           Include support for PGP authentication
    --without-pgp        Remove support for PGP authentication

Pretty Good Privacy, or PGP, is a popular encryption and authentication program available for many computing platforms. [1.6.2] Tectia optionally authenticates users based on their PGP keys, so long as those keys comply with the OpenPGP standard (RFC-2440, "OpenPGP Message Format"; some PGP versions, especially older ones, might not be OpenPGP-compliant). PGP support is included by default. [6.5]

    --with-kerberos5        Include support for Kerberos-5 authentication
    --without-kerberos5     Remove support for Kerberos-5 authentication

Kerberos is an authentication mechanism that passes around tickets, small sequences of bytes with limited lifetimes, in place of user passwords. [11.5.2.2] The configuration flags --with-kerberos5 and --without-kerberos5 control whether Kerberos support is included or excluded during the build. Tectia's Kerberos-5 support is experimental, and is not included by default.

If Kerberos was installed in a nonstandard location, the installation directory can be provided as an argument:

    $ configure --with-kerberos5=/usr/local/kerberos5

    --with-gssapi           Include support for GSSAPI authentication
    --without-gssapi        Remove support for GSSAPI authentication

GSS (Generic Security Services) is an emerging standard that facilitates negotiation of security parameters among a wide variety of platforms. [11.5.2.2] Tectia can be compiled to use GSSAPI libraries and header files to support this standard. If the GSSAPI installation is in a nonstandard location, specify the directory (with lib and include subdirectories) as an argument for the --with-gssapi option:

    $ configure --with-gssapi=/usr/local/gssapi
    --enable-gssapi-dynamic        Enable dynamic loading of GSSAPI libraries
    --disable-gssapi-dynamic       Force static linking of GSSAPI libraries

By default, GSSAPI libraries are linked statically into the SSH server and client. The libraries can optionally be loaded dynamically at runtime: this allows new security mechanisms to be added by replacing the libraries, without recompiling Tectia.

    --with-socks-server            Specify default SOCKS server

SOCKS is a network protocol for proxies. A proxy is a software component that masquerades as another component to hide or protect it. For example, suppose a company permits its employees to surf the Web but doesn't want the hostnames of its internal machines to be exposed outside the company. A proxy server can be inserted between the internal network and the Internet so that all web requests appear to be coming from the proxy. In addition, a proxy can prevent unwanted transmissions from entering the internal network, acting as a firewall.

Tectia supports both Versions 4 and 5 of the SOCKS protocol,[39] and no external library or special configuration options are needed. The SOCKS feature is controlled by the SocksServer client configuration keyword. [7.4.7] In addition to the usual methods of setting this in a configuration file or on the command line with -o, you can also set it using the SSH_SOCKS_SERVER environment variable.

SocksServer has an empty default value, causing Tectia to assume there's no SOCKS server. The configuration flag --with-socks-server gives nonempty default value to this parameter, allowing you to set up a Tectia installation that assumes the presence of a SOCKS server. Note that this isn't the same as using the SocksServer keyword in the global client configuration file, because the keyword overrides the environment variable. If you use the compilation option, users can specify an alternate SOCKS server with SSH_SOCKS_SERVER; if you use the global file, they can't (although they can still override using their own SocksServer directive).

See http://www.socks.permeo.com/ for more information on SOCKS. [7.4.7]

    --enable-debug              Enable light debugging
    --disable-debug             Disable light debugging
    --enable-debug-heavy        Enable heavy debugging
    --disable-debug-heavy       Disable heavy debugging

Tectia programs (both the server and client) produce detailed debugging output on demand. [5.9] If desired, Tectia can be compiled with or without two levels of debugging output. Without the debugging code, the programs might experience a slight increase in performance, but with it, the programs are easier to maintain. We recommend including at least some debugging code, because you never know when you'll need to diagnose a problem.

"Light" and "heavy" debugging are two levels of debugging that you can specify in the source code. Light debugging output is controlled by the configure flags --enable-debug and --disable-debug (the default). Heavy debugging output is controlled by the configure flags --enable-debug-heavy and --disable-debug-heavy (the default). Heavy debugging automatically enables light debugging. We recommend turning on heavy debugging or else the messages will contain too little information to be useful.

    --enable-efence             Use the Electric Fence memory allocation debugger

Tectia's memory allocations can be tracked by Electric Fence, a freely distributable memory allocation debugger created by Bruce Perens. You must have Electric Fence installed on the server machine in order for this to work.

The --enable-efenceflag causes Tectia's programs to be linked with the Electric Fence library, libefence.a, which provides instrumented versions of malloc(), free(), and other memory-related functions. Electric Fence is available from http://www.perens.com/FreeSoftware/.

    --with-purify               Use Rational Purify to track memory accesses

Rational Purify is a commercial product that supports tracking of memory accesses at runtime. It is able to detect memory leaks and corruption due to buffer overruns, etc.

The --with-purify flag includes support for Rational Purify. When the Tectia programs run, they produce a report about memory activity that can be analyzed after each program exits.

Rational Purify is available from http://www.ibm.com/software/awdtools/purify/.

    --with-internal-ssh1-compat          Include SSH-1 protocol support in the client
    --without-internal-ssh1-compat       Remove SSH-1 protocol support from the client

The Tectia SSH client can support the older (and deprecated) SSH-1 protocol by running a separate client program named ssh1, which must be installed separately. [5.10] By default, the Tectia SSH client also supports SSH-1 directly using its own implementation. If you don't use the SSH-1 protocol, use the --without-internal-ssh1-compat option to remove the internal SSH-1 support and save some space in the client.

    --with-ssh-agent1-compat        Include SSH-1 protocol support in the agent
    --without-ssh-agent1-compat     Remove SSH-1 protocol support from the agent

SSH agents [2.5] that use the protocols SSH-1 and SSH-2 are normally not compatible. That is, each version of the agent can't store keys or forward connections from the other. However, the Tectia agent has an optional feature to serve SSH-1 protocol applications, if it is run with the option -1 (that's a one, not a lowercase L).

SSH-1 protocol support is included in the Tectia agent by default, but you can use the --without-ssh-agent1-compat option to remove it if you never plan to use SSH-1 clients.

RSA support must be included (either by default, or using the --with-rsa configure option) for the agent to support the SSH-1 protocol.

4.3.6 SSH-1 Compatibility Support for Tectia

The Tectia server only supports the SSH-2 protocol, but it can be configured to run a separate SSH-1 server to support clients that are still using the older protocol. [5.10] The Tectia client can similarly run a separate SSH-1 client program, or it can use its own internal SSH-1 implementation.

If separate SSH-1 programs are used, they must be obtained and installed. OpenSSH is a good choice for SSH-1 client support, but for SSH-1 server support, only versions earlier than 3.7 can be used.

An alternative is the latest SSH1 implementation, which is quite old and (even worse) is no longer being actively maintained, but at least is designed to be integrated seamlessly with Tectia.

To install SSH1, download the tar file and associated signature file from ftp://ftp.ssh.com/pub/ssh/. At press time, these were ssh-1.2.33.tar.gz and ssh-1.2.33.tar.gz.sig, respectively.

To verify the signature, you also need to download the key, in the file SSH1-DISTRIBUTION-KEY-RSA.asc. Import the key into your key ring:

    $ gpg --import SSH1-DISTRIBUTION-KEY-RSA.asc

Then check the integrity of the tar file:

    $ gpg --verify ssh-1.2.33.tar.gz.sig

Extract the files from the tar file in the usual way to create a source directory named ssh-1.2.33. [4.1.4]

Run the configure script. We won't go over its options because they are obsolete for the most part, and because fancy features are presumably not needed (or even desirable) if SSH1 is only going to be employed as part of a transition strategy until older SSH-1 clients can be upgraded to use SSH-2. You can, however, remove unneeded features to prevent them from being exploited if any security holes are lurking in the code (which becomes increasingly likely as the software continues to age). As usual, see the output from configure --help for details.

You can install SSH1 in the same directory as Tectia using the same configure --prefix option for each. [4.1.5] Finally, compile everything with make, and install (typically as root) with make install. [4.1.6] The following files are installed:

  • The server program, sshd1, and a link to it called sshd

  • The clients ssh1 and scp1, and respective links called ssh and scp

  • The symbolic link slogin1, pointing to ssh1, and likewise a link called slogin pointing to slogin1

  • Support programs ssh-add1, ssh-agent1, ssh-askpass1, and ssh-keygen1, and links to them called ssh-add, ssh-agent, ssh-askpass, and ssh-keygen, respectively

  • The support program make-ssh-known-hosts

  • A newly generated host key pair, created by ssh-keygen1 and placed by default into /etc/ssh/ssh_host_key (private key) and /etc/ssh/ssh_host_key.pub (public key)

  • The server configuration file, /etc/ssh/sshd_config by default [5.2.1]

  • The client configuration file, /etc/ssh/ssh_config by default [7.1.2]

  • Manpages for the various programs

Notice that SSH1 and Tectia create some files with the same names, such as the link sshd. What happens if you install both SSH1 and Tectia on the same machine? Happily, everything works out, even if you install the two products into the same bin and etc directories, provided you install the most recent versions. Each of their Makefiles is constructed to check for the existence of the other version and respond appropriately.[40]

Specifically, both SSH1 and Tectia create symbolic links called sshd, ssh, scp, ssh-add, ssh-agent, ssh-askpass, and ssh-keygen. If you install SSH1 and then Tectia, the Tectia Makefile renames these files by appending the suffix .old and then creates new symbolic links pointing to its own Tectia programs. For instance, ssh originally points to ssh1; after installing Tectia, ssh points to ssh2, and ssh.old points to ssh1. This is appropriate since Tectia is considered a later version than SSH1.

On the other hand, if you install Tectia and then SSH1, the SSH1 Makefile leaves Tectia's links untouched. As a result, ssh remains pointing to ssh2, and no link points to ssh1. This is consistent with the practice of installing SSH1 to allow Tectia to provide fallback SSH1 support.

You need to set up the SSH1 configuration files in addition to the Tectia configuration files, and then keep them synchronized. [5.10.1]


[39] Except for SOCKS5 authentication methods.

[40] Installers for Tectia binary distributions behave the same way when integrating with SSH1 installations.