Beruflich Dokumente
Kultur Dokumente
This tutorial is designed for administrators of IBM RS/6000 systems who wish to improve the
security and integrity of their servers running AIX by replacing standard insecure network
services with those provided by the OpenSSH implementation of the Secure Shell protocol.
Neither general network security, nor the use of the SSH client software is discussed in-depth in
this tutorial. The primary focus of this tutorial is to detail the necessary components, the steps, and
the configuration required to compile OpenSSH and its prerequisites from source to deploy across
AIX systems.
The latest stable version of each software package was used for this tutorial. Options and behavior
of software may change across releases, so always refer to the documentation included with the
source distribution for the most recent information.
What is OpenSSH
What is wrong with the default network services?
Like most UNIX implementations, AIX provides a large number of network services enabling
remote users to log in interactively, transfer files to and from the server, and issue commands to
the server in a non-interactive fashion. Unfortunately, most of the daemons (programs running
on the server that fulfill requests for particular services) were designed during a time when the
security of systems and network traffic was an afterthought -- if it was thought of at all.
The protocols behind such services as telnet, rsh, and ftp contain no provision for the encryption
of traffic passed over the network. Most network protocols contain methods for user authentication,
but the methods are extremely weak and easily forged. Protocols allowing the transmission of user
IDs and passwords from the client to the server in clear-text are common-place. In addition, there
is no guarantee that the data transferred through the network has not been intercepted by a third-
party and possibly altered.
The Secure Shell (SSH) protocol was developed to address the aforementioned problems caused
by these inherently insecure services.
In time, limitations and flaws were discovered in the original definition of the protocol. These
problems could not be fixed without breaking compatibility with older versions, so a new protocol
was defined fixing the issues with the original SSH protocol. As the various implementations
of the protocol 2-based software mature and gain features, the use of the older protocol 1-
based software will fade. For now, though, implementations of both protocol 1 and protocol 2
are in widespread use around the world; to provide service to the widest audience of clients, it is
important for servers to support client connections via both protocols.
Currently, the development of OpenSSH is divided into two teams. One team does strictly
OpenBSD-based development, aiming to produce code that is as clean, simple, and secure as
possible. The other team takes the clean version and makes it portable so it builds and runs on
many different operating systems, including AIX. The portable releases can be identified by the "p"
in the version number (e.g., OpenSSH 3.0.1p1); source distributions without the "p" compile only
on OpenBSD.
Unfortunately, this model can make the deployment of OpenSSH a bit like a recipe: numerous
components need to be downloaded and compiled separately, and the various applications often
use different systems for configuration, compilation, and installation of their code.
Although gzip is not a prerequisite for building OpenSSH, its use is required in decompressing the
source bundles used later in this tutorial. The gzip format is used most often for the distribution of
free software on the Internet, and so its presence on an AIX system is almost a requirement.
Fortunately, the source for gzip is available in an uncompressed tape archive (tar) format. After
downloading the tarball and saving it into /usr/local/src, execute the following commands:
tar xvf gzip-1.2.4a.tar cd gzip-1.2.4a ./configure && make check
When the auto-configuration and compilation is complete, the following lines are output:
gzip test OK rm -f _gztest*
Now, run the make install command (as root); the following files will be installed in the
appropriate subdirectories of /usr/local:
/usr/local/man/man1/gzip.1 /usr/local/man/man1/gzexe.1 /usr/local/man/man1/zdiff.1 /usr/local/man/man1/
zgrep.1 /usr/local/man/man1/zmore.1 /usr/local/man/man1/znew.1 /usr/local/man/man1/zforce.1 /usr/local/
man/man1/zcat.1 /usr/local/man/man1/zcmp.1 /usr/local/man/man1/gunzip.1 /usr/local/bin/gzip /usr/local/bin/
zdiff /usr/local/bin/zgrep /usr/local/bin/zmore /usr/local/bin/znew /usr/local/bin/zforce /usr/local/bin/
gzexe /usr/local/bin/zcmp /usr/local/bin/gunzip /usr/local/bin/zcat /usr/local/info/gzip.info
After downloading the source for the latest version of zlib, place it in /usr/local/src, and run the
following commands:
gunzip -c zlib-1.1.3.tar.gz | tar xvf - cd zlib-1.1.3 vi Makefile
Run the make test command to compile and test the library. When that process is complete, the
last line displayed on the screen will be:
As root run make install to install the following header files and library to their correct location:
/usr/local/lib/libz.a /usr/local/include/zlib.h /usr/local/include/zconf.h
Note: -qmaxmem=-1 is a option specific to IBM's C for AIX compiler; it tells the compiler to use as
much memory as necessary during the compilation in order to obtain the best optimization of the
binary.
Unfortunately, AIX 4.3 or 5.1 does not include this source of randomness. On AIX and other
systems lacking /dev/random, the prngd application can provide the entropy required by OpenSSH
and other cryptographic software.
After downloading the source for the latest version of prngd into /usr/local/src, run the following
commands:
gunzip -c prngd-0.9.23.tar.gz | tar xvf - cd prngd-0.9.23.tar.gz vi Makefile
Find the AIX 4.3 w/cc section in Makefile; uncomment and add the-qmaxmem=-1 flag to the
CFLAGS line so that it appears like the following:
# AIX 4.3 w/cc ("Joerg Petersen <j.petersen@msh.de>) # Please also check out contrib/
AIX-4.3/00README.aix-src CFLAGS=-O -DAIX43 -qmaxmem=-1 # SYSLIBS=
The source can then be compiled by issuing the make command. The prngd Makefile does not
include a rule for installing the daemon; it must be installed manually by running the following
command:
mkdir /usr/local/sbin ; cp prngd /usr/local/sbin/ cp contrib/prngd.conf.aix43 /etc/prngd.conf
The longer the prngd daemon process is running, the better the quality of randomness it can
provide to other applications that use entropy. Thus, this daemon should be run at startup and
should never exit. There are numerous methods of running daemons at startup; this tutorial
will present one using the AIX System Resource Controller (SRC). By using SRC, a consistent
interface for starting, stopping, and querying the status of the subsystem will be made available.
To create a subsystem for controlling the prngd daemon, issue the followingcommand:
/usr/bin/mkssys -s prngd -p /usr/local/sbin/prngd -a '-f -c /etc/prngd.conf -s /var/tmp/egd-seed /dev/egd-
pool' -u 0 -S -n 15 -f 9 -R -G local
The prngd subsystem can now be started by executing the startsrc -s prngd command. To have
the prngd subsystem start at system boot, enter the following command, which adds an entry to /
etc/inittab:
After downloading the latest source release of OpenSSL into /usr/local/src, run the following
commands:
gunzip -c openssl-0.9.6b.tar.gz | tar xvf -cd openssl-0.9.6b ./config && make && make test
Note: OpenSSL is a large and complicated package. The compilation and testing can take a very
long time, especially on slower systems. When the test suite has completed, text similar to the
following will be printed to the screen:
OpenSSL 0.9.6b 9 Jul 2001 built on: Sat Nov 17 17:41:15 PST 2001 platform: aix43-cc options: bn(64,32)
md2(int) rc4(ptr,char) des(idx,cisc,4,long) idea(int) blowfish(idx) compiler: cc -DDSO_DLFCN -DHAVE_DLFCN_H -
O -DAIX -DB_ENDIAN -qmaxmem=16384 Target "test" is up to date.
Now as root run make install to install the requisite program files:
/usr/local/ssl/man/man1/CA.pl.1 /usr/local/ssl/man/man1/asn1parse.1 /usr/local/ssl/man/man1/ca.1 /usr/local/
ssl/man/man1/ciphers.1 /usr/local/ssl/man/man1/crl.1 /usr/local/ssl/man/man1/crl2pkcs7.1 /usr/local/ssl/
man/man1/dgst.1 /usr/local/ssl/man/man1/dhparam.1 ---[snip]--- many, many similar lines... /usr/local/ssl/
include/openssl/ssl3.h /usr/local/ssl/include/openssl/ssl23.h /usr/local/ssl/include/openssl/tls1.h /usr/
local/ssl/misc/CA.sh /usr/local/ssl/misc/CA.pl /usr/local/ssl/misc/der_chop /usr/local/ssl/misc/c_hash /usr/
local/ssl/misc/c_info /usr/local/ssl/misc/c_issuer /usr/local/ssl/misc/c_name /usr/local/ssl/openssl.cnf
To build TCP Wrappers, issue the following commands after downloading the source distribution
into /usr/local/src:
gunzip -c tcp_wrappers_7.6.tar.gz | tar xvf - cd tcp_wrappers_7.6 vi Makefile
Before compiling the source, several changes need to be made to the Makefile:
to
FACILITY= LOG_LOCAL7 # tcpd messages will be logged to facility local7
• Change the line:
TABLES = -DHOSTS_DENY=\"/etc/hosts.deny\" -DHOSTS_ALLOW=\"/etc/hosts.allow\"
to
TABLES = -DHOSTS_DENY=\"/etc/tcpd.conf\" -DHOSTS_ALLOW=\"/etc/tcpd.conf\"
• Add -qmaxmem=-1 to the CFLAGS block:
CFLAGS = -O -DFACILITY=$(FACILITY) $(ACCESS) $(PARANOID) $(NETGROUP) \ $(BUGS) $(SYSTYPE) $(AUTH)
$(UMASK) \ -DREAL_DAEMON_DIR=\"$(REAL_DAEMON_DIR)\" $(STYLE) $(KILL_OPT) \ -DSEVERITY=$(SEVERITY) -
DRFC931_TIMEOUT=$(RFC931_TIMEOUT) \ $(UCHAR) $(TABLES) $(STRINGS) $(TLI) $(EXTRA_CFLAGS) $(DOT) \
$(VSYSLOG) $(HOSTNAME) -qmaxmem=-1
After saving the above changes to the Makefile, run the make aix command to compile the
source.
The Makefile for TCP Wrappers does not include an install target. To place the files in the proper
locations, enter the following root commands:
cp tcpdchk safe_finger try-from tcpdmatch tcpd /usr/local/sbin/ cp libwrap.a /usr/local/lib/ cp
hosts_access.3 /usr/local/man/man3/ cp hosts_access.5 hosts_options.5 /usr/local/man/man5/ cp tcpd.8
tcpdchk.8 tcpdmatch.8 /usr/local/man/man8/ mkdir -p /usr/local/share/tcpd/ cp Banners.Makefile /usr/local/
share/tcpd/ mkdir /usr/local/include/ cp tcpd.h /usr/local/include/ touch /etc/tcpd.conf
Configuration of TCP Wrappers will not be detailed in this tutorial. See the included README and
man pages for instructions on usage and configuration settings.
Building OpenSSH
Build configuration options
Now that all of the prerequisites are in place, the OpenSSH source can be compiled. After
downloading the latest version the OpenSSH source into /usr/local/src, extract the contents with
the following commands:
gunzip -c openssh-3.0.1p1.tar.gz | tar xvf -cd openssh-3.0.1p1
There are a number of options that must be defined at compile-time and numerous other options
that can have their default values set during compilation. For a list and description of all of the
compile-time configuration options, type the ./configure --help command in the source directory.
For the purposes of this tutorial, the following options are specified:
./configure --sysconfdir=/etc/ssh --with-cflags="-qmaxmem=-1" --with-tcp-wrappers --with-xauth=/usr/bin/X11/
xauth --with-prngd-socket=/dev/egd-pool --with-ipv4-default --with-pid-dir=/var/tmp
When configuration completes, a summary of the options will be printed to the screen, similar to:
OpenSSH has been configured with the following options: User binaries: /usr/local/bin System binaries: /usr/
local/sbin Configuration files: /etc/ssh Askpass program: /usr/local/libexec/ssh-askpass Manual pages: /usr/
local/man/manX PID file: /var/tmp sshd default user PATH: /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin Random
number collection: PRNGD/EGD (socket /dev/egd-pool) Manpage format: man PAM support: no KerberosIV support:
no Smartcard support: no AFS support: no S/KEY support: no TCP Wrappers support: yes MD5 password support:
no IP address in $DISPLAY hack: no Use IPv4 by default hack: yes Translate v4 in v6 hack: no Host: powerpc-
ibm-aix4.3.3.0 Compiler: cc Compiler flags: -g -qmaxmem=-1 Preprocessor flags: -I/usr/local/ssl/include -I/
usr/local/include Linker flags: -L/usr/local/ssl/lib -L/usr/local/lib -blibpath:/usr/lib:/lib:/usr/local/lib
Libraries: -lwrap -lz -lcrypto
At the start of each new connection to a server, the client compares the public portion of the
server's host key to one from a previous connection, saved in a file in the user's home directory. If
the current version and previous versions are not identical, the client issues a warning to the user
that the server connection may have been spoofed or compromised and should not be trusted. For
this reason, it is important to back up the server keys and ensure that those files are not replaced
during an upgrade of the OpenSSH software.
If the file containing the public half of a key pair is damaged, it can easily be regenerated from the
secret half with the ssh-keygen utility. If the private half is damaged or compromised by a security
breach, the entire key pair is useless and must be regenerated. If this occurs, all users of the
system must be told that there is a new host key, and they will have to delete the public portion
of the old server key from their ~/.ssh/known_hosts or known_hosts2 file. If they don't, they will
receive a warning message each time they connect to the server, or, depending on their local
configuration, they will not be able to connect at all.
• DenyGroups
This keyword can be followed by a number of group names, separated by spaces. Users
whose primary group or supplementary group list matches one of the patterns aren't allowed
to log in. "*" and "?" can be used as wildcards in the patterns. Only group names are valid; a
numerical group ID is not recognized. By default, login is allowed regardless of the group list.
• DenyUsers
This keyword can be followed by a number of user names, separated by spaces. Login
is disallowed for user names that match one of the patterns. "*" and "?" can be used as
wildcards in the patterns. Only user names are valid; a numerical user ID is not recognized.
By default login is allowed regardless of the user name.
• HostbasedAuthentication
Specifies whether rhosts or /etc/hosts.equiv authentication together with successful public
key client host authentication is allowed (hostbased authentication). This option is similar to
RhostsRSAAuthentication and applies to protocol version 2 only. The default is "no".
• IgnoreRhosts
Specifies that .rhosts and .shosts files will not be used in RhostsAuthentication,
RhostsRSAAuthentication or HostbasedAuthentication. /etc/hosts.equiv and /etc/
shosts.equiv are still used. The default is "yes".
• LogLevel
Gives the verbosity level that is used when logging messages from sshd. The possible values
are: QUIET, FATAL, ERROR, INFO, VERBOSE and DEBUG. The default is INFO. Logging
with level DEBUG violates the privacy of users and is not recommended.
• PermitRootLogin
Specifies whether root can login using ssh(1). The argument must be "yes", "without-
password", "forced-commands-only" or "no". The default is "yes". If this option is set to
"without-password" password authentication is disabled for root. If this option is set to "forced-
commands-only", root login with public key authentication will be allowed, but only if the
command option has been specified (which may be useful for taking remote backups even if
root login is normally not allowed). All other authentication methods are disabled for root. If
this option is set to "no" root is not allowed to login.
• Protocol
Specifies the protocol versions sshd should support. The possible values are "1" and "2".
Multiple versions must be comma-separated. The default is "2,1".
• RhostsAuthentication
Specifies whether authentication using rhosts or /etc/hosts.equiv files is
sufficient. Normally, this method should not be permitted because it is insecure.
RhostsRSAAuthentication should be used instead, because it performs RSA-based host
authentication in addition to normal rhosts or /etc/hosts.equiv authentication. The default is
"no". This option applies to protocol version 1 only.
• RhostsRSAAuthentication
Specifies whether rhosts or /etc/hosts.equiv authentication together with successful RSA
host authentication is allowed. The default is "no". This option applies to protocol version 1
only.
• StrictModes
Specifies whether sshd should check file modes and ownership of the user's files and home
directory before accepting login. This is normally desirable because novices sometimes
accidentally leave their directory or files world-writable. The default is "yes".
• Subsystem
Configures an external subsystem (e.g., file transfer daemon). Arguments should be a
subsystem name and a command to execute upon subsystem request. The sftp-server(8)
command implements the "sftp" file transfer subsystem. By default no subsystems are
defined. Note that this option applies to protocol version 2 only.
• SyslogFacility
Gives the facility code that is used when logging messages from sshd. The possible values
are: DAEMON, USER, AUTH, LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5,
LOCAL6, LOCAL7. The default is AUTH.
• X11Forwarding
Specifies whether X11 forwarding is permitted. The default is "no". Note that disabling X11
forwarding does not improve security in any way, as users can always install their own
forwarders. X11 forwarding is automatically disabled if UseLogin is enabled.
To create a subsystem that will control the sshd daemon, issue the following command as root:
/usr/bin/mkssys -s sshd -p /usr/local/sbin/sshd -a '-D' -u 0 -S -n 15 -f 9 -R -G local
This creates a new subsystem named "sshd". The program started by this subsystem is /usr/
local/sbin/sshd with the "-D" argument. The program will be run as root, and will use signals for
communication with the SRC. When requested to stop, the daemon is sent the TERM signal, and
if that fails, the KILL signal. The subsystem will be restarted if it stops abnormally, and it will be
included in the SRC group named "local".
To have the subsystem started at system boot, run the following command to add an entry to /etc/
inittab, after the prngd entry:
They are then prompted to enter their user name and password:
Trying 123.456.789.012 ... Connected to earth.galaxy.com Escape character is '^] AIX Version 4 (C) Copyrights
by IBM and by others 1982, 1996. login: user user's Password: ******
If the user account and password are correct, the user is authenticated and provided access to the
system. To perform the same action using ssh, the user types:
$ ssh earth user@earth's password: ******
As with telnet, the user will then be logged in if the user account and password specified
are valid. The difference, though, is that all network traffic between the client and the server,
including the user name and password, is encrypted, making them immune from packet sniffing
attacks. SSH clients usually use the name of the user that is logged in on the client system when
connecting to the remote system. If the end user wishes to use a different user account, they will
need to add that account name before the host name, joined with an "@" sign. For example:
$ ssh user@earth
The telnet service should be disabled on the server by either deleting or commenting out the
telnet entry in /etc/inetd.conf.
The OpenSSH distribution includes both the client and server programs necessary to replace the
insecure r commands. For the examples presented in the following table, it is assumed that:
• The fully qualified domain name of the client system is listed in either the /etc/hosts.equiv
file on the server named earth, or in the .rhosts file within the user's home directory
• If the client is a UNIX system, the ssh program is set-UID root, and has the
UsePriveligedPort yes option in the /etc/ssh_config configuration file
• The /etc/sshd_config file on the server earth contains the options: HostbasedAuthentication
yes, IgnoreRhosts no, and RhostsRSAAuthentication yes
• The public key for the client system is in either the server's global known hosts file, or the
user's known hosts file.
rsh earthrlogin earth ssh earthslogin earth provides the user with an The host key of the client system
interactive login session on the is checked against the server's
server named earth, without known hosts file. If they do not
having to enter a password. match, the connection is refused.
All communications between
rsh earth uptime ssh earth uptime executes the uptime command on the server and the client are
the server named earth, without encrypted.
having to enter a password.
The rexec command, though similarly named, uses a different but also insecure method of
authorizing a remote user to run a command on a server without entering her password. Instead
of the .rhosts file, a .netrc file in the user's home directory on the client system contains the user
name and password. This data, and all other data transferred over the network is sent in clear-text.
By using the ssh client's ability to execute commands, use of the rexec service can be avoided,
and the daemon that provides this service can be disabled on the server.
In order to take advantage of the increased security provided by the OpenSSH replacements,
the login, shell, and exec services should be commented out or deleted from the server's /etc/
inetd.conf.
If the features provided by the sftpd-server program meet the requirements for your FTP service,
the standard ftpd daemon should be disabled by commenting out or deleting the ftp entry in /
etc/inetd.conf.
Summary
Summary
The Secure Shell protocol is a flexible and powerful tool; this tutorial has only scratched the
surface of its capabilities. SSH can be used in many different ways, including but not limited to:
securing remote X11 sessions, providing encryption for services not designed with such protection,
the use of public keys to provide seamless login and the secure execution of specific commands,
and so on.
OpenSSH can be extended to include Kerberos authentication, AFS token passing, Smart Card
support, and a number of other related technologies. For more information about using these and
other features with OpenSSH, refer to the items listed in the references and resources section on
the next panel.
Related topics
• The web site for the OpenSSH project, http://www.openssh.com/, is the primary source for
information about new releases of OpenSSH. It also contains a Frequently Asked Questions
(FAQ) page, a form for reporting bugs, and an archive of the various OpenSSH related mailing
lists.
• SSH, The Secure Shell: The Definitive Guide, by Daniel J. Barrett and Richard E. Silverman,
published by O'Reilly & Associates, is, as the title states, the definitive guide to the
Secure Shell protocol, providing in-depth explanations about almost everything SSH-related.
The book also has a Web site, http://www.snailbook.com/, containing news, an FAQ, and
discussion forums dedicated to SSH.