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:
Client programs for remote logins, remote command execution, and secure file copying across a network, all with many runtime options
A highly configurable SSH server
Command-line interfaces for all programs, facilitating scripting with standard Unix tools (shells, Perl, etc.)
Numerous, selectable encryption algorithms and authentication mechanisms
An SSH agent, which caches keys for ease of use
Support for SOCKS proxies
Support for TCP port forwarding and X11 forwarding
History and logging features to aid in debugging
FIPS 140-2 certification for U.S. government applications
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.
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.
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
0c7be85eb79e80e893d4c258df8443f0Here’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.
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.
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 softwareThe 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 filesThe 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 connectionsYou 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 authenticationSecurID 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 clientsVery 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 nameBy 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 authenticationPretty 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 authenticationGSS (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 librariesBy 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 serverSOCKS 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 debuggerTectia’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 accessesRational 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.
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]
Get SSH, The Secure Shell: The Definitive Guide, 2nd Edition now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
