Before you start
About this tutorial
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.
About the examples in this tutorial
The example system used in this tutorial is an RS/6000 running AIX 4.3.3 Maintenance Level 08. The source software was compiled with the IBM C for AIX version 5.0.1 compiler. Note that the instructions presented apply to all currently supported versions of AIX from 4.3.x thru 5.x.
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
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.
The development of the Secure Shell protocol
In 1995, the original SSH protocol was developed by Tatu Ylönen, a researcher at the Helsinki University of Technology, in Finland. Along with developing the protocol, Ylönen also wrote an implementation for UNIX systems, distributing the source as free software for unlimited use. As the popularity of the SSH software grew worldwide, Ylönen formed a company, SSH Communications Security, Ltd., in order to further development of the product (now licensed commercially, but with source available) and provide support.
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.
What does SSH do?
The Secure Shell protocol protects against the following problems, most of which are inherent in the design of the various protocols that SSH can replace:
- User and host authentication
SSH uses several strong cryptographic methods to ensure that both the client and the server are who they say they are. Unless both the server and the client agree that the user and host identities are valid, the connection is denied.
- Encryption of network traffic
All data transmitted over the network between an SSH client and an SSH server is encrypted with algorithms of varying strength. This ensures that if the network traffic is sniffed (intercepted and read by an unauthorized party), the contents of the packets will be unreadable.
- Integrity of data transmission
The SSH protocol assures the integrity of all data transmitted to and from a server. If a third-party attempts to alter the data packets, SSH detects this and alerts the user.
The OpenSSH project
The creation of OpenSSH, a free implementation of both SSH protocol 1 and 2, was undertaken by the OpenBSD project in order to provide a Secure Shell implementation unencumbered by restrictive licensing. OpenSSH was first included with the release of OpenBSD 2.6. The quality and security of the code produced was excellent and it was quickly ported to other UNIX operating systems.
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.
Gathering the pieces
OpenSSH, like many other open source software projects, builds on the work and components of other applications to perform its tasks. This allows the developers of OpenSSH to focus on creating the stable and secure code that is at the core of the application, while relying on the expertise and ability of the developers of other applications to ensure that those components perform as designed.
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.
Obtain the prerequisites
The following open source software projects are required to compile and deploy OpenSSH. The version numbers for each package listed is the most current stable version at the time of this tutorial. Check the project's Web site to find out about updated releases.
gzip:The GNU Zip compression application
Project web site: http://www.gzip.org/zlib/
Source download: http://www.info-zip.org/pub/infozip/zlib/zlib.tar.gz
prngd:The Pseudo Random Number Generation Daemon
- OpenSSL:Secure Sockets Layer and Transport Layer Security
Project web site: http://www.openssl.org/
Source download: http://www.openssl.org/source/openssl-0.9.6b.tar.gz
- TCP Wrappers:Access control for Internet servers (optional)
Project web site: ftp://ftp.porcupine.org/pub/security/index.htmll
Source download: ftp://ftp.porcupine.org/pub/security/tcp_wrappers_7.6.tar.gz
- OpenSSH:Open source implementation of the Secure Shell
Project web site: http://www.openssh.com/
Source download: ftp://ftp5.usa.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-3.0.1p1.tar.gz
Build and install
GNU Zip (
gzip) is an open source data
compression program similar to the standard UNIX compress/uncompress
applications, but unencumbered by patents that might affect its status
as free software.
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
available in an uncompressed tape archive
tar) format. After downloading the tarball
and saving it into
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
/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
Build and install
Zlib is a lossless, general-purpose
compression library used by many open source software projects. The
library uses the same compression algorithms used by the
gzip program, which are more efficient than
those used by UNIX compress.
After downloading the source for the latest version of
zlib, place it in
/usr/local/src, and run the following
gunzip -c zlib-1.1.3.tar.gz | tar xvf - cd zlib-1.1.3 vi Makefile
Makefile, adding -qmaxmem=-1 to
the end of the
make test command to compile and
test the library. When that process is complete, the last line
displayed on the screen will be:
*** zlib test OK ***
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.
Build and install
The Pseudo Random Number Generator Daemon,
prngd, provides a source of entropy on
platforms that do not include a
file for that purpose. Entropy, or randomness, is an integral
part of any encryption process. Generating a quantity of true random
data is critical in securing password, secret phrases, and other
encrypted data. Many UNIX platforms provide a kernel-level source of
random data, via
Unfortunately, AIX 4.3 or 5.1 does not include this source of
randomness. On AIX and other systems lacking
prngd application can provide the entropy
required by OpenSSH and other cryptographic software.
After downloading the source for the latest version of
/usr/local/src, run the following
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
uncomment and add the-qmaxmem=-1 flag to the
CFLAGS line so that it appears like the
# AIX 4.3 w/cc ("Joerg Petersen <firstname.lastname@example.org>) # 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
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
/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
prngd subsystem can now be started by
startsrc -s prngd command. To
prngd subsystem start at system
boot, enter the following command, which adds an entry to
/usr/sbin/mkitab "prngd:2:wait:startsrc -s prngd > /dev/console 2>&1"
Build and install OpenSSL
OpenSSL is an open source implementation of the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols. The general-purpose cryptology libraries provided with OpenSSL are used by a number of encryption-related applications, including OpenSSH.
After downloading the latest source release of OpenSSL into
/usr/local/src, run the following
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
Build and install TCP Wrappers (optional)
TCP Wrappers provides a simple application,
tcpd, that can be used to limit access to
various network services based on the IP address of the client. It is
often used, and in fact, was designed for "wrapping" services spawned
by inetd. The package also provides a library,
libwrap.a, that applications, including
OpenSSH, can link to and gain the access controls that TCP Wrappers
provides. While it is not necessary for deploying OpenSSH, TCP
Wrappers adds another level of access control and logging capability
that an administrator might appreciate.
To build TCP Wrappers, issue the following commands after downloading
the source distribution into
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
- Uncomment the REAL_DAEMON_DIR line for AIX, so that it appears:
# SysV.4 Solaris 2.x OSF AIX REAL_DAEMON_DIR=/usr/sbin
- Uncomment the following line:
#STYLE = -DPROCESS_OPTIONS # Enable language extensions.
- Change the line:
FACILITY= LOG_MAIL # LOG_MAIL is what most sendmail daemons use
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\"
TABLES = -DHOSTS_DENY=\"/etc/tcpd.conf\" -DHOSTS_ALLOW=\"/etc/tcpd.conf\"
-qmaxmem=-1to 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.
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.
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
/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
./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-aix220.127.116.11 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
Compile and install the components
make command to compile the
source. When the build is complete, as root run
jmake install to install the various files
in their proper places.
The following files are installed into
/usr/local/man/man1/ssh.1 /usr/local/man/man1/scp.1 /usr/local/man/man1/ssh-add.1 /usr/local/man/man1/ssh-agent.1 /usr/local/man/man1/ssh-keygen.1 /usr/local/man/man1/ssh-keyscan.1 /usr/local/man/man1/sftp.1 /usr/local/man/man8/sshd.8 /usr/local/man/man8/sftp-server.8 /usr/local/bin/ssh /usr/local/bin/scp /usr/local/bin/ssh-add /usr/local/bin/ssh-agent /usr/local/bin/ssh-keygen /usr/local/bin/ssh-keyscan /usr/local/bin/sftp /usr/local/sbin/sshd /usr/local/share/Ssh.bin /usr/local/libexec/sftp-server
The configuration directory /etc/ssh is also created. It contains following files:
/etc/ssh/ssh_config /etc/ssh/sshd_config /etc/ssh/ssh_prng_cmds /etc/ssh/moduli /etc/ssh/ssh_host_key /etc/ssh/ssh_host_key.pub /etc/ssh/ssh_host_dsa_key /etc/ssh/ssh_host_dsa_key.pub /etc/ssh/ssh_host_rsa_key /etc/ssh/ssh_host_rsa_key.pub
Configuration and usage
The host keys
As part of the install process, host keys are generated and placed in
/etc/ssh. There are three types of host
keys, explained below. Each host key is comprised of two files (a
key pair): a secret portion, whose contents should
not be accessable by any user other then root, and a public
portion, whose contents are transferred to the client system each time
a connection is initiated.
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.
The three types of key pairs are:
This pair of files contains the host key that will be used when clients connect to the server using version 1 of the Secure Shell protocol. This key pair uses the Rivest-Shamir-Adleman (RSA) algorithm for encryption.
This key pair contains the host key used for clients connecting via version 2 of the Secure Shell protocol. It uses the Digital Signature Algorithm (DSA) public-key algorithm for encryption.
This key pair is used with clients connecting with version 2 of the Secure Shell protocol. It also uses the RSA algorithm for encryption, and is most commonly used with key pairs that have been converted from the protocol 1 version for use with protocol 2.
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
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.
Setting configuration options
Secure Shell server (
sshd) options are
defined in the
/etc/ssh/sshd_config file. A
default file is placed into that location during the install process.
For a list and description of all the possible options, see the
sshd(8) man page. A few of the more common
options, and their recommended settings are:
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.
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.
/etc/hosts.equivauthentication together with successful public key client host authentication is allowed (hostbased authentication). This option is similar to
RhostsRSAAuthenticationand applies to protocol version 2 only. The default is "no".
.shostsfiles will not be used in
/etc/shosts.equivare still used. The default is "yes".
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.
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.
Specifies the protocol versions
sshdshould support. The possible values are "1" and "2". Multiple versions must be comma-separated. The default is "2,1".
Specifies whether authentication using
/etc/hosts.equivfiles is sufficient. Normally, this method should not be permitted because it is insecure.
RhostsRSAAuthenticationshould be used instead, because it performs RSA-based host authentication in addition to normal
/etc/hosts.equivauthentication. The default is "no". This option applies to protocol version 1 only.
/etc/hosts.equivauthentication together with successful RSA host authentication is allowed. The default is "no". This option applies to protocol version 1 only.
sshdshould 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".
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.
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.
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
Maintaining configuration defaults
It is useful to set options even if the setting is to the default
value, as defaults can change between version releases. Using the
option settings discussed on the previous panel, the
/etc/ssh/sshd_config configuration file
look as follows:
############################################################# # # /etc/ssh/sshd_config # # configuration file for the OpenSSH ssh daemon # ############################################################ # deny connections from members of these groups: DenyGroups uucp, mail, nobody, nogroup # deny connections from these users: DenyUsers daemon, bin, sys, adm, uucp, guest, nobody, lpd # allow host-based authentication (.rhosts and /etc/hosts.equiv) # if the host key exchange was successful. I realize that this # is reducing the security of my server. [ protocol 2 only] HostbasedAuthentication yes # permit the use of user .rhosts and .shosts files. Again, I # release that I am reducing the security of my server in favor # of functionality for clients: IgnoreRhosts no # messages logged to syslog from sshd will be at priority INFO: LogLevel INFO # root will not be permitted to log in interactively, but can # run commands remotely ... PermitRootLogin forced-commands-only # accept protocol 2 connections first, then fall back to protocol 1 Protocol 2,1 # straight .rhosts authentication will not be permitted, as this is # exactly the same as "rsh/rcp" ... RhostsAuthentication no # however, .rhosts authentication with successful RSA host # authentication will be permitted [protocol 1 only]: RhostsRSAAuthentication yes # ensure that the permissions on a user's ssh-related files are # set properly; deny connections if they are not: StrictModes yes # define the subsystem "sftp" to enable the secure replacement for # the ftp protocol: Subsystem sftp /usr/local/libexec/sftp-server # have syslogd dispatch sshd messages to the AUTH facility ... SyslogFacility AUTH # permit the forwarding of X11 connections. This doesn't decrease # security at all ... X11Forwarding yes ############################################################
Running the SSH daemon at system boot
AIX provides a number of ways a program or service can be automatically started on system reboot. This tutorial presents one possibility using the System Resource Controller (SRC) feature of AIX. Using the SRC provides a method of controlling the daemon consistent with other subsystems present on AIX systems.
To create a subsystem that will control the
sshd daemon, issue the following command as
/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
/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
/usr/sbin/mkitab -i prngd "sshd:2:wait:startsrc -s sshd > /dev/console 2>&1"
Replacing insecure network services
Replacing the use of the insecure
protocol with the much more secure
protocol is simple. Users will have to substitute the use of an
ssh client for their
telnet client. When connecting via
telnet, the user enters
$ telnet earth.
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: ******
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
telnet service should be disabled on the
server by either deleting or commenting out the
telnet entry in
r services are those that use only the
/etc/hosts.equiv file and the
~/.rhosts files within users home
directories to perform authentication. These services include
rcp. All of these services can be replaced
by OpenSSH, exponentially increasing the overall security of the
server. Several "layers" of security may be imposed on the use of
these services, depending on the options set in the
/etc/ssh/sshd_config file by the server's
The OpenSSH distribution includes both the client and server programs
necessary to replace the insecure
commands. For the examples presented in the following table, it is
- The fully qualified domain name of the client system is listed in
/etc/hosts.equivfile on the server named earth, or in the
.rhostsfile within the user's home directory
- If the client is a UNIX system, the
sshprogram is set-UID root, and has the
UsePriveligedPort yesoption in the
/etc/sshd_configfile on the server earth contains the options:
IgnoreRhosts no, and
- The public key for the client system is in either the server's global known hosts file, or the user's known hosts file.
|Insecure command||Secure equivalent||Action performed||Security advantage|
|provides the user with an interactive login session on the server named earth, without having to enter a password.||The host key of the client system is checked against the server's known hosts file. If they do not match, the connection is refused. All communications between the server and the client are encrypted.|
|executes the uptime command on the server named earth, without having to enter a password.|
|copies 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
.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
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
In order to take advantage of the increased security provided by the
OpenSSH replacements, the
services should be commented out or deleted from the server's
For those systems that are required to provide an interactive file
transfer service, the
included with the OpenSSH distribution. Using the same authentication
and encryption methods as
ssh, users can
sftp client program to connect to
and transfer files to and from remote servers. Operation of the
sftp program is similar to standard FTP
clients, though the
lacks some of the "bells and whistles" of the
If the features provided by the
program meet the requirements for your FTP service, the standard
ftpd daemon should be disabled by
commenting out or deleting the
ftp entry in
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.
- 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.
- A number of Internet Drafts (working documents of the Internet Engineering Task Force, IETF) related to Secure Shell have been published: they can be found at the web site http://www.ietf.org/html.charters/secsh-charter.html.
- Participate in the discussion forum.
- A general discussion mailing list for discussion of Secure Shell is hosted by Security Focus. To subscribe to this list, send an empty message to email@example.com. A read-only list for announcements of updates to OpenSSH and related software can be subscribed to by sending a message containing only the word "SUBSCRIBE" in the body, to firstname.lastname@example.org.
Dig deeper into AIX and Unix on developerWorks
Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.
Experiment with new directions in software development.
Software development in the cloud. Register today to create a project.
Evaluate IBM software and solutions, and transform challenges into opportunities.