Skip to main content

By clicking Submit, you agree to the developerWorks terms of use.

The first time you sign into developerWorks, a profile is created for you. Select information in your profile (name, country/region, and company) is displayed to the public and will accompany any content you post. You may update your IBM account at any time.

All information submitted is secure.

  • Close [x]

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerworks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

By clicking Submit, you agree to the developerWorks terms of use.

All information submitted is secure.

  • Close [x]

developerWorks Community:

  • Close [x]

Deploying OpenSSH on AIX

Sandor W. Sklar (ssklar@stanford.edu), Systems Administrator, Freelance Developer
Sandor W. Sklar is a Unix systems administrator at Stanford University, in beautiful Northern California. When not poking through his systems for real or imagined security holes, he enjoys spending time with his wife and two children.

Summary:  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.

Date:  01 Jun 2001
Level:  Intermediate PDF:  A4 and Letter (343 KB | 20 pages)Get Adobe® Reader®

Activity:  18946 views
Comments:  

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:

  • ssh_host_key and ssh_host_key.pub

    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.

  • ssh_host_dsa_key and ssh_host_dsa_key.pub

    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.

  • ssh_host_rsa_key and ssh_host_rsa_key.pub

    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 ~/.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.


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:

  • 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.


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 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:

/usr/sbin/mkitab -i prngd "sshd:2:wait:startsrc -s sshd > 
/dev/console 2>&1"

5 of 9 | Previous | Next

Comments



static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=AIX and UNIX
ArticleID=124311
TutorialTitle=Deploying OpenSSH on AIX
publish-date=06012001
author1-email=ssklar@stanford.edu
author1-email-cc=