History and logging features to aid in debugging
ftp://ftp.ssh.com/pub/ssh/You may reach this repository from the web site of SSH Communications Security:
http://www.ssh.com/
Alternatively, use a single command with a pipe:$ gunzip ssh-1.2.27.tar.gz $ tar xvf ssh-1.2.27.tar
Or, if you have GNU Tar (called gtar or tar on some systems), simply type:$ gunzip < ssh-1.2.27.tar.gz | tar xvf -
The result is a new subdirectory containing all files in the distribution.$ gtar xzvf ssh-1.2.27.tar.gz
ftp://ftp.ssh.com/pub/ssh/SSH1-DISTRIBUTION-KEY-RSA.asc ftp://ftp.ssh.com/pub/ssh/SSH2-DISTRIBUTION-KEY-RSA.asc ftp://ftp.ssh.com/pub/ssh/SSH2-DISTRIBUTION-KEY-DSA.ascAdd them to your PGP key ring by saving each one to a temporary file and typing:
$ pgp -ka temporary_file_name
If no warning messages are produced, the distribution file is genuine.$ pgp ssh-1.2.27.tar.gz
$ ./configure
$ make
The following files are installed:$ su root Password: ******** # make install
$ ./configure
$ make
The following files are installed:$ su root Password: ******** # make install
[46]The configure script is generated by a Free Software Foundation package called autoconf. You don't need to know this to compile SSH1 or SSH2, but if you're interested in learning more about autoconf, visit the GNU web site at http://www.gnu.org/.
and also read the files README and INSTALL in the root of the distribution. Incidentally, the behavior of SSH1 and SSH2 may be controlled at three levels. The first is compile-time configuration as discussed in this chapter. In addition, server-wide configuration (Chapter 5, "Serverwide Configuration") controls global settings for a running SSH server, and per-account configuration (Chapter 8, "Per-Account Server Configuration") controls settings for each user account accepting SSH connections. Figure 4-1 illustrates where compile-time configuration fits into the whole spectrum. We'll remind you of this picture each time we introduce a new type of configuration.$ configure --help
Various string values are used, but the most common are yes and no. For a given package P, the flags -- with-P and -- with-P= yes are equivalent. The following tables illustrate the relationships:-- with-etcdir=/usr/local/etc -- enable-X11-forwarding=no
If you write: | It's equivalent to: |
---|---|
-- with-P=yes | -- with-P |
-- with-P=no |
-- without-P |
This next table shows the relationships for a given feature F :
If you write: | It's equivalent to: |
---|---|
-- enable-F=yes |
-- enable-F |
-- enable-F=no |
-- disable-F |
In the sections that follow, we show many examples of configure with different command-line flags. Most examples demonstrate only one flag at a time, so we use ellipses like this:
to indicate other flags might be present on the command line. The proper way to run configure is just once, before compilation, with all desired flags on the same command line.$ configure ... --enable-fancy-feature ...
WARNING: Be careful when choosing configure flags, or you might waste a lot of time. The configure script is not very smart, performing little or no sanity checking on its input. If you provide an invalid flag, configure can naively run for several minutes, handling a hundred other configuration options, before finally reaching the bad flag and dying. Now you have to run the script all over again. Also, don't depend on flags' default values since they might differ among SSH implementations. For maximum security and control, specify all flags explicitly when running configure.
Some SSH-related system files are installed in the directory /etc. This default location can be overridden with the configure flag -- with-etcdir, supplying an alternative directory name (for OpenSSH, this is --sysconfdir):# SSH1, SSH2, OpenSSH $ configure ... --prefix=/usr/local/ssh ...
The flag -- with-etcdiris unique among flags because there is no corresponding -- without-etcdir flag. SSH1 and SSH2 must have installation directories or their Makefiles will refuse to compile the software. Next, certain executables are installed as setuid root by default: ssh1 (for SSH1) and ssh-signer2 (for SSH2). ssh1 needs to be setuid root for trusted-host authentication (i.e., host-based authentication of various kinds), for the following reasons:# SSH1, SSH2 $ configure ... --with-etcdir=/usr/local/etc ...
Similarly, the setuid bit of ssh-signer2 for SSH2 is controlled by -- enable-suid-ssh-signerand -- disable-suid-ssh-signer; for example:# SSH1 only $ configure ... --disable-suid-ssh ...
Finally, the SSH server requires certain permissions on files and directories in user accounts, such as the .rhosts file and the authorized_keys file.[47] In particular, group write and world write permissions are forbidden. Group write permission may be useful for shared accounts (so members of a group can conveniently modify the account's SSH files). This restriction may be relaxed using the -- enable-group-writeability configure flag:[48]# SSH2 only $ configure ... --disable-suid-ssh-signer ...
[47]Only if StrictModes is turned on in the server. [Section 5.4.2.1, "Acceptable permissions for user files"]
[48]Yes, "writeability" is correct, even though it's a misspelling.
Now the server permits SSH connections to accounts with group-writable SSH files.# SSH1, SSH2 $ configure ... --enable-group-writeability ...
Alternatively, you may enable or disable it during serverwide configuration using the NoDelay configuration keyword. [Section 5.4.3.8, "Controlling TCP_NODELAY"] TCP-wrappers is a security feature for applying access control to incoming TCP connections based on their source address. [Section 9.4, "Forwarding Security: TCP-wrappers and libwrap"] 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 SSH 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. SSH1 and SSH2 both include support for TCP-wrappers if the flag -- with-libwrap is given at compile time, providing the path to the wrapper library, libwrap.a :# SSH1, SSH2 $ configure ... --disable-tcp-nodelay ...
If your Unix installation doesn't include the TCP-wrappers library, you can retrieve and compile it yourself from:# SSH1, SSH2 $ configure ... --with-libwrap=/usr/local/lib ...
ftp://ftp.porcupine.org/pub/security/index.htmlFor more information on TCP-wrappers, read the manpages for tcpd and hosts_access. A rather low-level option for SSH1 concerns the SO_LINGER socket flag, which may be turned on or off at compile time. Suppose SSH1 is communicating via an open socket, but the socket gets closed while data is still queued. What happens to the data? The setting of the SO_LINGER flag determines what should be done. With the flag enabled, the socket close "lingers" (delayed) until the data is delivered or until a specified timeout occurs. Monkeying with this flag requires a detailed knowledge of TCP/IP and socket behavior, so if you know what you're doing, use the -- enable-so-linger flag:
Finally, you may instruct sshd2 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 may set a limit. The appropriate flag is -- with-ssh-connection-limit with a nonnegative integer argument; for example:# SSH1 only $ configure ... --enable-so-linger ...
You may override this value at runtime with the serverwide configuration keyword MaxConnections. [Section 5.4.3.6, "Limiting simultaneous connections"]# SSH2 only $ configure ... --with-ssh-connection-limit=50 ...
Few people have a strong need to eliminate X support, but configure has a few other, more useful, X-related flags. Specifically, you may 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. [Section 9.3, "X Forwarding"] For SSH1, X forwarding support is separately controllable for SSH clients and servers:# SSH1, SSH2 $ configure ... --without-x ...
For SSH2, X forwarding support is controlled as a whole by the compile-time flag -- enable-X11-forwarding (or -- disable-X11-forwarding):# SSH1 only $ configure ... --disable-server-x11-forwarding ... $ configure ... --disable-client-x11-forwarding ...
Remember, these enable/disable flags set only SSH's default behavior. X forwarding may be further enabled or disabled through serverwide configuration using the X11Forwarding (SSH1, OpenSSH) or ForwardX11 (SSH2) configuration keywords. [Section 9.3.3, "Enabling X Forwarding"]# SSH2 only $ configure ... --disable-x11-forwarding ...
# SSH1 only $ configure ... --without-blowfish ...
WARNING: We recommend using --without-none to forbid unencrypted transmissions. Otherwise, an intruder who breaks into your server machine can turn off SSH encryption for clients by adding a simple line to a configuration file ("Ciphers None"). You may also incur other security risks. [Section 5.4.5, "Encryption Algorithms"] If you need unencrypted transmissions for testing, build a second SSH1 server using --with-none and make it executable only by the system administrator. Also, be aware that with the SSH-1 protocol, turning off encryption doesn't just eliminate data privacy; it also renders the server authentication and data integrity features ineffective.Some implementations of SSH include the RSA encryption algorithm for public-key authentication. [Section 3.9.1.1, "Rivest-Shamir-Adleman (RSA)"] At press time, the algorithm is absent from some implementations because RSA was protected by patent until September 2000; it is now in the public domain. While the patent was in force, the company made available a "reference implementation" of RSA, called RSAREF, that was freely used for educational and noncommercial purposes and didn't run afoul of the patent. We suspect that RSAREF will fall into disuse now that other more popular RSA implementations are available to all. Furthermore, we discourage its use because it contains security flaws and is no longer supported. However, you may still instruct SSH1 to use RSAREF instead of its own implementation of RSA via the configure flag -- with-rsaref:
Then, unpack the RSAREF package into a directory named rsaref2 at the top of the SSH1 distribution. RSA encryption is used by default or if you specify the configure flag -- without-rsaref. (There is no -- with-rsa flag.) For more information about RSAREF, visit http://www.rsa.com/.# SSH1 only $ configure ... --with-rsaref
[49]SecurID and Gauntlet-related flags are accepted by the SSH2 configure script, but at press time the source code contains no support for these techniques.Kerberos [Section 11.4, "Kerberos and SSH"] is an authentication mechanism that passes around tickets, small sequences of bytes with limited lifetimes, in place of user passwords. The configuration flags -- with-kerberos5 and -- without-kerberos5 control whether Kerberos support is included or excluded during the build.[50] The -- with-kerberos5 flag is optionally followed by a string value indicating the directory containing Kerberos files:
[50]Don't compile Kerberos support in SSH1 Version 1.2.27 or earlier because there is a serious security bug. [Section 11.4.4.5, "SSH1 Kerberos ticket-cache bug"] Use 1.2.28 or later. OpenSSH doesn't have this bug.
If the directory name is omitted from -- with-kerberos5, the default location is /usr/local. Additionally, the Kerberos feature of forwarding ticket-granting tickets is enabled by default by the flag -- enable-kerberos-tgt-passing:# SSH1 only $ configure ... --with-kerberos5=/usr/kerberos ...
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 SSH1 with SecurID support, use the flag -- with-securid, providing the path to the directory containing SecurID's header files and libraries:# SSH1 only $ configure ... --enable-kerberos-tgt-passing ...
Gauntlet is a firewall toolkit containing an authentication server program, authserv. If you are running Gauntlet and want SSH1 to communicate with its authentication server, use the -- with-tis flag, providing the path to your local Gauntlet directory:# SSH1 only $ configure ... -- with-securid=/usr/ace ...
Pretty Good Privacy, or PGP, is a popular encryption and authentication program available for many computing platforms. [Section 1.6.2, "Pretty Good Privacy (PGP)"] SSH2 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, may not be OpenPGP-compliant). To include this support, compile using the flag -- with-pgp:# SSH1, SSH2 $ configure ... --with-tis=/usr/local/gauntlet ...
# SSH2 only $ configure ... --with-pgp ...
[51]The NEC socks5 reference implementation is licensed free of charge for "for noncommercial purposes only, such as academic, research and internal business use." The full text of the license is available on their web site.There are three SSH1 SOCKS configure options:
gives nonempty default value to this parameter, allowing you to install an SSH2 that assumes the presence of a SOCKS server. Note that this isn't the same as using the SocksServer directive in the global client configuration file, because the configuration parameter always overrides the value of 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 Section 7.4.6, "Proxies and SOCKS" for a detailed discussion of how SSH SOCKS support works and http://www.socks.nec.com/ for more information on SOCKS.-- with-socks-server=string
Your alternative login program must support the same command-line flags as /bin/login, including -h (specify the hostname), -p (pass environment variables to the login shell), and -f (force login without checking the password). This is because sshd1 spawns the login program using the command line:# SSH1 only $ configure ... -- with-login=/usr/local/bin/my-login ...
If you specify --with-login, and you wish to use the alternative login program, you must also turn on the UseLogin keyword during serverwide configuration: [Section 5.5.3, "Selecting a Login Program"]name_of_login_program -h hostname -p -f --username
Login programs do useful things like set the default search path for users. If sshd1 doesn't invoke a login program (i.e., it was compiled using -- without-login), you can tell it to set the default search path for SSH-invoked sessions. This is done with the configuration flag --with-path:# Keyword in SSH1 server-wide configuration file UseLogin yes
If you don't specify -- with-path , and your Unix environment doesn't provide a default path, the sshd1 default is:# SSH1 only $ configure ... --with-path="/usr/bin:/usr/local/bin:/usr/mine/bin" ...
PATH="/bin:/usr/bin:/usr/ucb:/usr/bin/X11:/usr/local/bin"
# SSH1 only $ configure ... --with-nologin-allow=/etc/nologin.allow ...
If the statistics code is included, further configure flags control scp's default behavior for statistics display. The flags -- enable-scp-stats and -- disable-scp-stats set the default for single file transfers. If neither flag is used, statistics are enabled. To disable:# SSH1 only $ configure ... --without-scp-stats ...
Likewise, the flags -- enable-all-scp-stats and -- disable-all-scp-stats set the default for multiple file transfers. Again, if neither flag is used, statistics are enabled. To disable:# SSH1 only $ configure ... --disable-scp-stats ...
Regardless of the configuration for single and multiple file transfers, statistics may be turned on or off using scp's command-line options (-Q and -a) and user environment variables (SSH_SCP_STATS, SSH_NO_SCP_STATS, SSH_ALL_SCP_STATS, and SSH_NO_ALL_SCP_STATS). [Section 7.5.7, "Statistics Display"] Of course, the statistics code must be present ( -- with-scp-stats) for this runtime configuration to work.# SSH1 only $ configure ... --disable-all-scp-stats ...
If you include rsh support, individual users can selectively control it for clients launched in their accounts with the keywords FallBackToRsh and UseRsh. [Section 7.4.5.8, "RSH issues"] Or, to prevent ssh from using rsh entirely, compile with:# SSH1, OpenSSH $ configure ... --with-rsh=/usr/ucb/rsh ...
# SSH1, OpenSSH $ configure ... -- without-rsh ...
# SSH2 only $ configure ... --with-ssh-agent1-compat ...
# SSH2 only $ ssh-agent2 -1
The two debug levels aren't mutually exclusive: you may select light, heavy, both, or neither. We recommend turning on heavy debugging; otherwise the messages contain too little information to be useful. Finally, SSH2 memory allocations may be tracked by Electric Fence, a freely distributable memory allocation debugger created by Bruce Perens of Pixar. You must have Electric Fence installed on the server machine in order for this to work. The configure flags -- enable-efence and -- disable-efence (the default) control whether Electric Fence is used:# SSH2 only $ configure ... --enable-debug --disable-debug-heavy ...
This flag causes SSH2'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:# SSH2 only $ configure ... -- enable-efence ...
http://sources.isc.org/devel/memleak/
make-ssh-known-hosts has quite a few command-line flags for tailoring its behavior. [Section 4.1.6.1, "make-ssh-known-hosts command-line flags"] In addition, you may limit which machines are queried by providing Perl-style regular expressions as arguments following the domain name. For example, to print the host keys of all hosts in example.com whose names begin with z:# SSH1 only $ make-ssh-known-hosts example.com > /etc/ssh_known_hosts
A second regular expression argument performs the opposite task: it excludes the keys of hosts that match the regular expression. You can extend the previous example to exclude hosts ending in x:$ make-ssh-known-hosts example.com '^z'
Just for fun, here's a command that produces no host keys at all:$ make-ssh-known-hosts example.com '^z' 'x$'
because it includes and excludes the same string.$ make-ssh-known-hosts example.com mymachine mymachine
foo foo.bar foo.bar.baz foo.bar.baz.geewhiz.eduThis option allows you to pick a subset of these subdomains to be included, instead of all of them.
3.12. Summary | 4.2. F-Secure SSH Server |
Copyright © 2002 O'Reilly & Associates. All rights reserved.