F-Secure SSH Server

F-Secure Corporation, formerly DataFellows, Ltd., a Finnish software company, produces commercial implementations of SSH derived from those of SSH Communications Security. F-Secure's server product line, F-Secure SSH Server, runs on Unix, and SSH-1 and SSH-2 servers are available as separate products. They are repackagings of SSH1 and SSH2 with commercial licenses and a few added features:

• ●  A manual covering F-Secure SSH products for all platforms (Unix, Windows, Macintosh)
  
• ●  Additional encryption algorithms in the SSH-2 product, such as RSA and IDEA. (see the F-Secure manual for the current list)
  
• ●  An additional SSH client, edd ( Encryption Data Dump), a Unix filter that applies SSH encryption or decryption to standard input, writing the results to standard output
  
• ●  A few additional options in SSH1 (see Appendix B)
  4.2.1 Obtaining and Installing
  F-Secure SSH Server is available from http://www.f-secure.com/. In addition to their commercial SSH products, which may be purchased and downloaded from the web site,
  free "evaluation versions" are available.
  
  Except for the few additional features listed in the previous section, installation, configuration, and operation of F-Secure Unix SSH is almost identical to that of the SCS versions. SSH2 has moved ahead with new features not present in its F-Secure counterpart, however, so check the F-Secure documentation to see if particular features are available.
  

Book: SSH, The Secure Shell: The Definitive Guide
Section: Chapter 4. Installation and Compile-Time Configuration
4.3 OpenSSH
OpenSSH is a free implementation of SSH-1 and SSH-2, obtained from the OpenSSH web site:
http://www.openssh.com/
Since it is developed by the OpenBSD Project, the main version of OpenSSH is specifically for the OpenBSD Unix operating system, and is in fact included in the base OpenBSD installation. As a separate but related effort, another team maintains a "portable" version that compiles on a variety of Unix flavors and tracks the main development effort. The supported platforms include Linux, Solaris AIX, IRIX, HP/ UX, FreeBSD, and NetBSD (OpenSSH is included in FreeBSD as well). The portable version carries a "p" suffix. For example, 2.1.1p4 is the fourth release of the portable version of OpenSSH 2.1.1.
4.3.1 Prerequisites
OpenSSH depends on two other software packages: OpenSSL and zlib. OpenSSL is a cryptographic library available at http://www.openssl.com/; all the cryptography used in OpenSSH is pulled from OpenSSL. zlib is a library of data-compression routines, available at http://www.info-zip.org/pub/infozip/ zlib/. Before compiling OpenSSH, you must obtain and install these packages.
4.3.2 Building
Building OpenSSH is similar to building SSH1 and SSH2, with the same configure; make; make install sequence. In some versions of OpenSSH prior to 2.2.0, though, make install didn't generate and install the host keys automatically. If your host keys are missing, you can install them with make host-key.
4.3.3 PAM
By default, OpenSSH uses PAM for password authentication. PAM, the Pluggable Authentication Modules system, is a generic framework for authentication, authorization, and accounting (AAA). The idea is that programs call PAM to perform AAA functions, leaving the sysadmin free to configure individual programs to use various kinds of authentication, via dynamically loaded libraries. Visit http:// www.kernel.org/pub/linux/libs/pam/ for more information on PAM.
Generally, if a program uses PAM, some host configuration is necessary to describe how PAM should behave for that program. The PAM configuration files are usually in the directory /etc/pam.d.

On many operating systems that use PAM, including RedHat Linux, OpenSSH builds with PAM support by default (you can turn this off using configure -without-pam). However, you must then configure PAM on the host to know about sshd, or password authentication will not work. By default, PAM normally denies authentication for programs not specifically configured to use it.

PAM configuration for SSH is usually just a matter of copying the appropriate sshd.pam file from the distribution's contrib directory into place as /etc/pam.d/sshd. Sample files are included for various flavors of Unix.
Note that you don't need to restart sshd when you change the PAM configuration; the configuration files are checked on every use of PAM.
4.3.4 Randomness
The main OpenSSH code base relies on the host operating system to provide a source of entropy, or randomness, via a device driver accessed through /dev/urandom. This is because the OpenBSD operating system has this device. If you build OpenSSH on a platform lacking such a device, such as Solaris, it needs an alternative source of randomness. There are two choices:

• ●  Use the built-in, "internal entropy-gathering" system
  
• ●  Install the "Entropy Gathering Daemon" (EGD) package (http://www.lothar.com/tech/crypto/)
  OpenSSH defaults to the first choice, the internal system, unless you configure it with EGD. The internal system uses a configurable set of commands that monitor changing aspects of the system operation, mixing their output together. You can control which commands are used and how, with the file /etc/ ssh_prng_cmds.
  4.3.5 Compilation Flags
  As with the other SSH implementations, OpenSSH has a number of compilation flags, many the same, some different. Here are the most important ones to know:
  -without-pam Disable PAM support
  Omit PAM support from OpenSSH. This flag isn't normally necessary, since the configure
  process detects whether the host has PAM, and if so, you probably want to use it.
  -with-md5-passwords Enable use of MD5 passwords -without-shadow Disable shadow password support
  These options control OpenSSH's treatment of the Unix account database (passwd map). They are relevant only if OpenSSH isn't using PAM, since otherwise PAM deals with reading the account
  

information, not the OpenSSH code proper.

Enable -with-md5-passwords if your system uses MD5 instead of the traditional crypt function to hash passwords, and you are not using PAM.
"Shadow passwords" refers to the practice of keeping the hashed password in a restricted file /etc/ shadow (/etc/passwd must be world-readable). Use -without-shadow to suppress reading of the /etc/shadow file, should it be necessary.
-with-ssl-dir= PATH Set path to OpenSSL installation
If OpenSSL isn't installed in the usual place, /usr/local/ssl, use this flag to indicate its location.
-with-xauth=PATH Set path to xauth program
In OpenSSH, the default location of the xauth program is a compile-time parameter.
-with-random=FILE Read randomness from given file
Specify the character device file providing a source of random bits, normally /dev/urandom.
-with-egd-pool=FILE
Read randomness from EGD pool FILE (default none)
If you install EGD as described earlier, use this flag to have OpenSSH use EGD as its randomness source.
-with-kerberos4=PATH Enable Kerberos-4 support
-with-afs=PATH Enable AFS support
These flags apply to Kerberos-4 and AFS. [Section 3.4.2.4] Note that there's no Kerberos-5
support in OpenSSH.
-with-skey Enable S/Key support
Enable support for the S/Key one-time password system for password authentication. [Section
3.4.2.5]
-with-tcp-wrappers Enable TCP-wrappers support Equivalent to the SSH1 configure flag -with-libwrap . [Section 4.1.5.3]
-with-ipaddr-display Use IP address instead of hostname in $DISPLAY

In X forwarding, use DISPLAY values of the form 192.168.10.1:10.0 instead of hostname:10.0. This flag works around certain buggy X libraries that do weird things with the hostname version, using some sort of IPC mechanism for talking to the X server rather than TCP.
-with-default-path=PATH Default server PATH
The default path OpenSSH uses when attempting to run a subprogram.
-with-ipv4-default Use IPv4 unless "-6" is given
-with-4in6 Check for and convert IPv4 in IPv6 mapped addresses
OpenSSH supports IPv6, the next-generation TCP/IP protocol suite that is still in the development and very early deployment stages in the Internet (the current version of IP is IPv4). The default configuration of OpenSSH attempts to use IPv6 where possible, and sometimes this results in problems. If you encounter errors mentioning "af=10" or "address family 10," that's IPv6, and you should try the -4 runtime option, or compiling -with-ipv4-default.
-with-pid-dir=PATH Specify location of ssh.pid file
Location of the OpenSSH pid file, where it stores the pid of the currently running daemon. The default is /var/run/sshd.pid.

Book: SSH, The Secure Shell: The Definitive Guide
Section: Chapter 4. Installation and Compile-Time Configuration
4.4 Software Inventory
Table 4.1. Software Inventory

Component	SSH1	OpenSSH	SSH2
Server config	/etc/sshd_config	/etc/sshd_config	/etc/ssh2/ sshd2_config
Global client config	/etc/ssh_config	/etc/ssh_config	/etc/ssh2/ ssh2_config
Host private key	/etc/ssh_host_key	/etc/ssh_host_dsa_key	/etc/ssh2/hostkey
Host public key	/etc/ssh_host_key.pub	/etc/ssh_host_dsa_key. pub	/etc/ssh2/ hostkey.pub
Client host keys	/etc/ssh_known_hosts ~/.ssh/ ssh_known_hosts	/etc/ssh_known_hosts ~/.ssh/ ssh_known_hosts ~/.ssh/ ssh_known_hosts2	/etc/ssh2/ hostkeys ~/.ssh2/hostkeys/ *
Remote host keys	~/.ssh/ ssh_known_hosts	~/.ssh/ ssh_known_hosts ~/.ssh/ ssh_known_hosts2	~/.ssh2/ knownhosts/*

libwrap control files	/etc/hosts.allow /etc/hosts.deny	/etc/hosts.allow /etc/hosts.deny	/etc/hosts.allow /etc/hosts.deny
Authorization for login via public key	~/.ssh/authorized_keys	~/.ssh/authorized_keys ~/.ssh/ authorized_keys2	~/.ssh2/ authorization
Authorization for login via trusted- host	/etc/hosts.equiv /etc/shosts.equiv ~/.shosts ~/.rhosts	/etc/hosts.equiv /etc/shosts.equiv ~/.shosts ~/.rhosts	/etc/hosts.equiv /etc/shosts.equiv ~/.shosts ~/.rhosts
Default keypair for public-key authentication	~/.ssh/identity{.pub}	SSH-1/RSA: ~/.ssh/identity{.pub} SSH-2/DSA: [7] ~/.ssh/id_dsa{.pub}	(No default)
Random seed	~/.ssh/random_seed /etc/ssh_random_seed	~/.ssh/prng_seed [8]	~/.ssh2/ random_seed /etc/ssh2/ random_seed
Commands for generating randomness	-	/etc/ssh_prng_cmds	-

Kerberos	/etc/krb5.conf ~/.k5login	/etc/krb.conf ~/.klogin	-
Terminal client	ssh1 slogin link to ssh1	ssh slogin link to ssh	ssh2
Secure file copy client	scp1	scp	scp2
Signer program	-	-	ssh-signer2
sftp2/scp2 server	-	-	sftp-server2
Authentication agent	ssh-agent1	ssh-agent	ssh-agent2
Key generator	ssh-keygen1	ssh-keygen	ssh-keygen2
Key add/remove	ssh-add1	ssh-add	ssh-add2
Find SSH servers	-	-	ssh-probe2
Get passphrase via terminal or X	ssh-askpass1	-	ssh-askpass2
Server program	sshd1	sshd	sshd2

[7]
This can't be changed using -i as it can with OpenSSH/1; use -o Identity2=key_ file instead.
[8]
Present only if using OpenSSH's internal entropy-gathering mechanism (i.e., no /dev/random or
equivalent on system). SSH1 and SSH2 use seed files even when /dev/random exists.

Book: SSH, The Secure Shell: The Definitive Guide
Section: Chapter 4. Installation and Compile-Time Configuration
4.5 Replacing R-Commands with SSH
SSH and the r-commands (rsh, rcp, rlogin) can coexist peacefully on the same machine. Since the r- commands are insecure, however, some system administrators prefer to replace them by their SSH counterparts (ssh, scp, slogin). This replacement has two parts:

• ●  Installing SSH and removing rsh, rcp, and rlogin; requires some user retraining
  
• ●  Modifying other programs or scripts that invoke the r-commands
  The r-commands are so similar to their analogous SSH commands, you might be tempted to rename the SSH commands as the r-commands (e.g., rename ssh as rsh, etc.). After all, common commands like these are practically identical in syntax:
  

  $ rsh -l jones remote.example.com
  $ ssh -l jones remote.example.com
  

  $ rcp myfile remote.example.com:
  $ scp myfile remote.example.com:
  

  Why not just rename? Well, the two sets of programs are incompatible in some ways. For example, not all versions of ssh support the "hostname link" feature of rsh [Section 2.7.3], and some old versions of rcp use a different syntax for specifying remote filenames.
  In the following sections, we discuss some common Unix programs that invoke the r-commands and how to adapt them to use SSH instead.
  4.5.1 The /usr/hosts Directory
  The program rsh has an interesting feature called hostname links. [Section 2.7.3] If you rename the executable from "rsh" to something else, the program treats its new name as a hostname and
  connects to it by default. For example, if you rename rsh as "petunia," on invocation it executes rsh petunia. The renaming may be done literally or by creating a hard link or symbolic link to rsh:
  

  $ ls -l petunia
  lrwxrwxrwx  1 root      12 Jan 31  1996 petunia -> /usr/ucb/rsh
  $ petunia
  Welcome to petunia!
  Last login was Wed Oct 6 21:38:14 from rhododendron
  You have mail.
  

  Some Unix machines have a directory, commonly /usr/hosts, that contains symbolic links to rsh representing various hosts on the local network (or beyond):
  

$ ls -l /usr/hosts
lrwxrwxrwx  1 root
lrwxrwxrwx  1 root
lrwxrwxrwx  1 root
...

12 Jan 31  1996 lily -> /usr/ucb/rsh
12 Jan 31  1996 petunia -> /usr/ucb/rsh
12 Jan 31  1996 rhododendron -> /usr/ucb/rsh

If you eliminate /usr/ucb/rsh from such a machine, obviously these links become orphaned. Delete them and replace them with links to ssh, perhaps with a shell script like this:

#!/bin/sh
SSH=/usr/local/bin/ssh
cd /usr/hosts
for file in *
do

  rm -f $file
  ln -s $SSH $file
  echo "Linked $file to $SSH"

done
4.5.2 Concurrent Version System (CVS)
CVS is a version-control system. It maintains a history of changes to sets of files, and helps coordinate the work of multiple people on the same files. It can use rsh to connect to repositories on remote hosts. For example, when you check in a new version of a file:

$ cvs commit myfile

if the repository is located on a remote machine, CVS may invoke rsh to access the remote repository. For a more secure solution, CVS can run ssh instead of rsh. Of course, the remote machine must be running an SSH server, and if you use public-key authentication, your remote
[9]
account must contain your key in the appropriate place.
To make CVS use ssh, simply set the environment variable CVS_RSH to contain the path to your ssh client:

# Bourne shell family
# Put in ~/.profile to make permanent.
CVS_RSH=/usr/local/bin/ssh
export CVS_RSH

# C shell family
# Put in ~/.login to make permanent.
setenv CVS_RSH /usr/local/bin/ssh

This approach has one problem: each time you check in a file, the logger's name is the remote account owner, which might not be your own. The problem is solved by manually setting the remote

LOGNAME variable using the "environment=" option in your remote authorized_keys file. [Section 8.2.6.1]
4.5.3 GNU Emacs
The Emacs variable remote-shell-program contains the path to any desired program for invoking a remote shell. Simply redefine it to be the full path to your ssh executable. Also, the rlogin package, rlogin.el, defines a variable rlogin-program you can redefine to use slogin.
4.5.4 Pine
The Pine mail reader uses rsh to invoke mail-server software on remote machines. For example, it might invoke the IMAP daemon, imapd, on a remote mail server. Another program may be substituted for rsh by changing the value of a Pine configuration variable, rsh-path. This variable holds the name of the program for opening remote shell connections, normally /usr/ucb/rsh. A new value may be assigned in an individual user's Pine configuration file, ~/.pinerc, or in the system-wide Pine configuration file, typically /usr/local/lib/pine.conf. For example:

# Set in a Pine configuration file
rsh-path=/usr/local/bin/ssh

A second variable, rsh-command, constructs the actual command string to be executed for the remote mail server. The value is a pattern in the style of the C function printf( ). Most likely, you won't need to change the value because both rsh and ssh fit the default pattern, which is:

"%s %s -l %s exec /etc/r%sd"

The first three "%s" pattern substitutions refer to the rsh-path value, the remote hostname, and the remote username. (The fourth forms the remote mail daemon name, which doesn't concern us.) So by default, if your username is alice and the remote mail server is mail.example.com, rsh- command evaluates to:
/usr/ucb/rsh mail.example.com -l alice ...
By changing the rsh-path, it becomes instead: /usr/local/bin/ssh mail.example.com -l alice ...
As we said, you probably don't need to do anything with rsh-command, but just in case, we've included it for reference. We present a detailed case study of integrating Pine and SSH1 later. [Section 11.3]
4.5.5 rsync, rdist

rsync and rdist are software tools for synchronizing sets of files between different directories on the

same machine or on two different hosts. Both can call rsh to connect to a remote host, and both can easily use SSH instead: simply set the RSYNC_RSH for rsync and use the -P option with rdist. rsync with SSH is a particularly simple and effective method to securely maintain remote mirrors of whole directory trees.
[9]
CVS also has a remote-access method involving its own server, called pserver. This mechanism can
be secured using SSH port forwarding instead; see Chapter 9.