Softpanorama
(slightly skeptical) Open Source Software Educational Society

May the source be with you, but remember the KISS principle ;-)

Softpanorama Search

SSH Configuration

News SSH Recommended Links Private and Public key managemen Mini-tutorial FAQs
ssh-keygen man page     Tips humor Etc

In order of precedence, Secure Shell configuration occurs at the following places: the software build-time, the server command-line options, the server configuration file (sshd_config), the client command-line options, the user client configuration file (~/.ssh/config), and the global client configuration file (ssh_config). Build-time configuration is the strongest. It cannot be changed without rebuilding the software. This makes it inconvenient if a change is needed.

The server configuration involves the following: how the sshd(1M) daemon will present itself on the network, what protocols and authentication methods are acceptable, and how the user environment is constructed. The client configuration involves the following: determining which server to transact with which protocol, verifying the server identity, determining the user identity presentation, and choosing the ease-of-use features. Policy details are implemented on the server side. The client cannot override or provide a feature that the server does not offer.

The available features can be enabled or disabled by either command-line options or the applicable configuration file. Command-line options apply to a particular instantiation of either the server or client. Configuration file options are persistent until the file is altered and a new instantiation started. The most reliable configuration method uses the configuration file. This gives a repeatable, reproducible invocation. Changes can also be tracked by using source control. For information on command-line options, consult the vendor documentation.

When OpenSSH is built, sshd_config and ssh_config are placed at the location specified by sysconfdir. Usual locations are /etc,/usr/local/etc,/etc/ssh or /etc/openssh. The Solaris Secure Shell software stores the two files at /etc/ssh. These files should be owned by user root and group sys. The file permission mode should be either 644 or 444.

Configuration files contain two types of entries: comments and keyword-value pairs. Comments are blank lines and lines beginning with the hash mark (#). Keyword-value pairs consist of an identifier (keyword), a space, and the value associated with the identifier. Keywords are case insensitive, where as values are case sensitive.

Traditionally, the first letter of each word in a keyword is capitalized for readability. Some values are lists that are either comma delimited or space delimited, depending on the keyword. Consider keeping configuration files under source control to track revisions. The source control tags can be hidden by the comment character (the hash mark).

server configuration options supported by the Solaris Secure Shell software and OpenSSH. The list is formatted in the following manner:

Name of the option and the value or values it takes

Note: Server options override the client's configuration.

AllowGroups pattern

   # Allow only the sysadmins access
   AllowGroups sysadmin

 

   # Allow both staff and sysadmin access
   AllowGroups s*

AllowUsers pattern

 

   # Allow only Suzie and Buster access.
   AllowUsers suzie buster

AllowTCPForwarding yes | no

Note

If users have shell access, they can install their own port forwarders. If this is an issue, consider RBAC to limit access.

 

   # Protect user's traffic
   AllowTCPForwarding yes


 

 

 

 

 
[View full width]
# Only allow a remote job restricted access to
 gather logs.
   AllowTCPForwarding no


 

 

 

Banner value

 

 

   Banner /etc/issue


 

 


 

CheckMail yes | no

 

 

   CheckMail no


 

 

 

Ciphers list

 

 

   Ciphers aes128-cbc,blowfish-cbc,3des-cbc


 

 

 


 

Compression yes | no

 

 

   Compression yes


 

 

DenyGroups pattern

 

 

   # Prevent the users from logging in to the server  
   DenyGroups users


 

 

DenyUsers pattern

 

 

   DenyUsers Cheng Atkinson


 

 

 

DSAAuthentication yes | no

 

   DSAAuthentication yes


 

 

 


 

GatewayPorts yes | no

Note

Users can chain together port forwarders (that is, create a bouncer) on the local machine to circumvent this restriction.


 

 

 

   GatewayPorts no


 

 

 


 

HostKey value

 

 

   HostKey /etc/ssh/ssh_host_key
   HostKey /etc/ssh/ssh_host_rsa_key
   HostKey /etc/ssh/ssh_host_dsa_key


 

 

 

IgnoreRhosts yes | no

 

 

   IgnoreRhosts yes


 

 

 

IgnoreUserKnownHosts yes | no

 

   IgnoreUserKnownHosts yes


 

 

 


 

KeepAlive yes | no

 

 

   keepAlive yes


 

 

 

KeyRegenerationInterval value

 

 

   KeyRegenerationInterval 1800


 

 

 

ListenAddress value

 

 

   ListenAddress 192.168.0.5


 

 

 


 

LoginGraceTime value

 

   LoginGraceTime 60


 

 

 

LogLevel value

 

 

   LogLevel DEBUG


 

 

 

MACs list

 

   MACS hmac-sha1, hmac-md5


 

 

MaxAuthTries value

 

   MaxAuthTries 6


 

 

 

The following is an example of when MaxAuthTries is set to 2, and the user fails to log in successfully:

 

 

 
[View full width]
hook /home/suzi $ ssh blackbeard
   suzi@blackbeard's password: password
   Permission denied, please try again.
   suzi@blackbeard's password: password
   Received disconnect: 2: too many failed
 userauth_requests
   hook /home/suzi $


 

 

MaxAuthTriesLog value

 

   MaxAuthTriesLog 3

 


 

MaxStartups value

 

   MaxStartups 10

PAMAuthenticationViaKBDInt yes|no

 

   PAMAuthenticationViaKBDInt yes

PasswordAuthentication yes|no

 

   # Internal mail server
   PasswordAuthentication yes

 

   # DMZ Bastion host
   PasswordAuthentication no


 

 

 


 

PermitEmptyPasswords yes|no

 

 

   PermitEmptyPasswords no


 

 

 


 

PermitRootLogin yes|no|without-password|forced-commands-only

 

 

   # Force the system admins to su
   PermitRootLogin no


 

 

 


 

 

 

   # Only a root account exists
   PermitRootLogin without-password


 

 

 


 

PermitUserEnvironment yes|no

 

 

   PermitUserEnvironment no


 

 

 


 

Port value

 

 

   # For LAN access 
   Port 22
   # For Internet access
   Port 2345


 

 

 


 

PrintMotd yes|no

 

 

   PrintMotd no


 

 

 


 

Protocol list

 

 

   # Protocol 2 only is recommended
   Protocol 2


 

 

 


 

 

 

   # Enable legacy support but default to Protocol 2.
   Protocol 2,1


 

 

 


 

PubKeyAuthentication yes|no

 

 

   PubKeyAuthentication yes


 

 

 


 

RhostsAuthentication yes|no

 

 

   RhostsAuthentication no


 

 

 


 

RhostsRSAAuthentication yes|no

 

 

   RhostsRSAAuthentication no


 

 

 


 

RSAAuthentication yes|no

 

 

   RSAAuthentication yes


 

 

 


 

ServerKeyBits value

 

 

   ServerKeyBits 1024


 

 

 


 

StrictModes yes|no

 

 

   StrictModes yes


 

 

 


 

SyslogFacility value.value

 

 

   SyslogFacility AUTH.INFO


 

 

 


 

UseLogin yes|no

 

 

   UseLogin no


 

 

 


 

UsePrivilegeSeparation yes|no

Note

The compilations options presented in Chapter 2 disable this feature.


 

 

 

   UsePrivilegeSeparation no


 

 

 


 

X11DisplayOffset value

 

 

   # For desktops or server
   X11DisplayOffset 10


 

 

 


 

 

 

 
[View full width]
# For Sun Ray appliance servers, may need to be
 more.
   X11DisplayOffset 100


 

 

 


 

X11Forwarding yes|no

 

 

 
   # Protect user's X sessions
   X11Forwarding yes


 

 

 


 

 

 

   # Only allow restricted access for a remote job
   X11Forwarding no


 

 

 


 

XAuthLocation Value

 

 

   XAuthLocation /usr/X/bin/xauth


 

 

 

Appendix C. Client Configuration Options

This appendix contains a list of the client configuration options supported by the Solaris Secure Shell software and OpenSSH. The list is formatted in the following manner:

Name of the option and the value or values it takes

Note

Client options cannot override the server's configuration.


 

BatchMode yes|no

 

 

   # For automated scripts
   BatchMode yes


 

 

 


 

CheckHostIP yes|no

 

 

   CheckHostIP yes


 

 

 


 

Cipher 3des|blowfish|des

 

 

   # For legacy protocol 1 servers only
   Cipher 3des,blowfish


 

 

 


 

Ciphers list

 

 

   Ciphers 3des-cbc,blowfish-cbc,aes-128-cbc


 

 

 


 

Compression yes|no

 

 

   Compression yes


 

 

 


 

CompressionLevel value

 

 

   CompressionLevel 9


 

 

 


 

ConnectionAttempts value

 

 

   ConnectionAttempts 3


 

 

 


 

DSAAuthentication yes|no

 

 

   DSAAuthentication yes


 

 

 


 

EscapeChar Value

 

 

   # Completely transparent connection
   EscapeChar


 

 

 


 

FallBackToRsh yes|no

 

 

   FallBackToRsh no


 

 

 


 

ForwardAgent yes|no

 

 

   ForwardAgent no


 

 

 


 

ForwardX11 yes|no

 

 

   ForwardX11 yes


 

 

 


 

GatewayPorts yes|no

 

 

   GatewayPorts no


 

 

 


 

GlobalKnownHostsFile value

 

 

   GlobalKnownHostsFile /etc/ssh_known_hosts


 

 

 


 

Host value

 

 

   # Only for legacy host
   Host legacy
   Protocol 1
   # defaults
   Host *
   Protocol 2
   CheckHostIP yes
   ConnectionAttempts 3


 

 

 


 

HostName value

 

 

   Host legacy
   HostName legacy.extremefoosticks.com.
   Protocol 1


 

 

 


 

IdentityFile value

 

 

   IdentityFile ~/ .ssh/dsa_ident_2


 

 

 


 

KeepAlive yes | no

 

 

   KeepAlive yes


 

 

 


 

LocalForward localhost_port destination_host:port

 

 

   LocalForward 8080 intranet.extremefoosticks.com:80


 

 

 


 

LogLevel value

 

 

   LogLevel DEBUG


 

 

 


 

MACs list

 

 

   MACs hmac-sha1, hmac-md5


 

 

 


 

NumberOfPasswordPrompts value

 

 

   NumberOfPasswordPrompts 3


 

 

 


 

PasswordAuthentication yes | no

 

 

   PasswordAuthentication yes


 

 

 


 

Port value

 

 

   Port 22


 

 

 


 

Protocol list

 

   # Protocol 2 only is recommended
   Protocol 2

 

   # Enable legacy support but default to Protocol 2.
   Protocol 2,1


 

 

 


 

ProxyCommand

 

 

 
[View full width]
Host remote
   ProxyCommand /usr/lib/ssh
/ssh-socks5-proxy-connect -h socks.corp -p 1080
   homebox.myhome.org 22


 

 

 


 

PubkeyAuthentication yes | no

 

 

   PubkeyAuthentication yes


 

 

 


 

RemoteForward port destination_host:port

 

 

   RemoteForward 8080 www.sun.com:80


 

 

 


 

RhostsAuthentication yes|no

 

 

   RhostsAuthentication no


 

 

 


 

RhostsRSAAuthentication yes|no

 

 

   RhostsRSAAuthentication no


 

 

 


 

RSAAuthentication yes|no

 

 

   RSAAuthentication yes


 

 

 


 

StrictHostKeyChecking yes|ask|no

 

 

   StrictHostKeyChecking yes


 

 

 


 

UsePrivilegedPort yes|no

 

 

   UsePrivilegedPort no


 

 

 


 

User value

 

 

   Host legacy
   User buster44


 

 

 


 

UserKnownHostsFile value

 

 

 
[View full width]
UserKnownHostsFile /home/suzi/ .ssh
/backup_known_hosts


 

 

 


 

UseRsh yes|no

 

 

   UseRsh no


 

 

 


 

XAuthLocation value

 

 

   XAuthLocation /usr/X/bin/xauth


 

 

init Script

The OpenSSH tool provides strong authentication and privacy for network connections. The init script in this section provides a mechanism to start and stop the OpenSSH system daemon at system boot and shutdown. This script is written for the Solaris 2.6, 7, 8, and 9 OE releases. The latest version of this script is available from the Blueprints Online tools area at:

http://www.sun.com/blueprints/tools/

Automatic Installation

The init script is automatically configured by makeOpenSSHPackage.ksh. It is installed by the resulting package installation.

Manual Installation

You can install the init script manually by using the following procedure.

To Manually Install the init Script
1.
Edit theinit script by making the changes to values denoted by %%.

 
2.
Copy the script to /etc/init.d/openssh.server.

 
3.
Change the permissions to 744.

 

 

 

# chmod 744 /etc/init.d/openssh.server


 

 

 


 
4.
Change the owner of the script.

 

 

 

# chown root:sys /etc/init.d/openssh.server


 

 

 


 
5.
Create the following links:

 

 

 

 
[View full width]
# ln /etc/init.d/openssh.server /etc/rc3.d
/S25openssh.server
# ln /etc/init.d/openssh.server /etc/rcS.d
/K30openssh.server
# ln /etc/init.d/openssh.server /etc/rc0.d
/K30openssh.server
# ln /etc/init.d/openssh.server /etc/rc1.d
/K30openssh.server
# ln /etc/init.d/openssh.server /etc/rc2.d
/K40openssh.server


 

 

 


 

Contact

For inquiries or feedback, contact openssh_tools@sun.com.

init Script Sample

 

 

 
[View full width]
#!/sbin/sh
#
#
umask 022
PATH=/usr/bin

configDir=%%configDir%%
openSSHDir=%%openSSHDir%%

usePRNGD=%%includePRNGD%%

PRNGDConfig=$configDir/prngd.conf
PRNGDEntropyDir=/var/run
PRNGDSeedFile=$PRNGDEntropyDir/prngd-seed
PRNGDEntropyPool=$PRNGDEntropyDir/egd-pool
PRNGDCmd=$openSSHDir/sbin/prngd
PRNGDCmdOptions="--cmdfile $PRNGDConfig --seedfile
 $PRNGDSeedFile \
          $PRNGDEntropyPool"

DSAKeyFile=$configDir/ssh_host_dsa_key
RSA2KeyFile=$configDir/ssh_host_rsa_key
RSA1KeyFile=$configDir/ssh_host_key
keyGenerator=$openSSHDir/bin/ssh-keygen

sshdConfig=$configDir/sshd_config
sshdPIDFile=sshd.pid
sshdCmd=$openSSHDir/sbin/sshd
sshdCmdOptions=""

#
# Checks for the existence of the host DSA key 
(protocol version 2)
#
DSAKeyExists() {
    [ -f "$DSAKeyFile" ] && return 0
    return 1
}

#
# Checks for the existence of the host RSA key 
(protocol version 2)
#
RSA2KeyExists () {
    [ -f "$DSAKeyFile"  ]  && return 0
    return 1
}


 

 

 


 

 

 

 
[View full width]
#
# Checks for the existence of the RSA host key 
(protocol version 1)
#
RSA1KeyExists () {
    [ -f "$RSA1KeyFile" ] && return 0
    return 1
}

#
# Checks for the existence of the PRNGD initial seed
#
PRNGDSeedExists () {
    [ -s "$PRNGDSeedFile" ] && return 0
    return 1
}

#
# Configures the appropriate PRNGD config file
#
setPRNGDConfigFile () {
    [ ! -f "$PRNGDConfig" ] && {
      OSrev= 'uname -r'
      case "$OSrev" in
          "5.7"|"5.8"|"5.9")
              ln -s $PRNGDConfig-solaris-2.7
 $PRNGDConfig
              ;;
          *)
              ln -s $PRNGDConfig-solaris-2.6
 $PRNGDConfig
              ;;
      esac
   }
}

#
# Generates DSA (protocol version 2) key
#
generateDSAKey () {
    echo "Generating OpenSSH server DSA (protocol
 version 2) key...\c"
    if $keyGenerator -q -t dsa -f $DSAKeyFile -N
 ''; then
      echo "done."
    else
      echo "failed!"
    fi
}

#
# Generates RSA (protocol version 2) key
#
generateRSA2Key () {


 

 

 


 

 

 

 
[View full width]
echo "Generating OpenSSH server RSA (protocol
 version 2) key...\c"
    if $keyGenerator -q -t rsa -f $RSA2KeyFile -N
 ''; then
        echo "done."
    else
        echo "failed!"
    fi
}

#
# Generates RSA (protocol version 1) key
#
generateRSA1Key () {
    echo "Generating OpenSSH server RSA (protocol
 version 1) key...\c"
    if $keyGenerator -q -t rsal -f $RSA1KeyFile -N
 ''; then
        echo "done."
    else
        echo "failed!"
    fi
}

#
# Checks for keys and generates them if necessary
#
generateKeys () {
    if DSAKeyExists; then
        echo "OpenSSH DSA key exists: $DSAKeyFile"
    else
        generateDSAKey
    fi

    if RSA2KeyExists; then
        echo "OpenSSH RSA2 key exists: $RSA2KeyFile"
    else
        generateRSA2Key
    fi

    if RSA1KeyExists; then
        echo "OpenSSH RSA1 key exists: $RSA1KeyFile"
    else
        generateRSA1Key
    fi
}

#
# Checks for the seed file and generates one if
 necessary
#
generateSeed () {
    if [ "$usePRNGD" = "yes" ]; then
      if PRNGDSeedExists; then


 

 

 


 

 

 

 
[View full width]
echo "PRNGD seed exists: $PRNGDSeedFile"
      else
          echo "Generating PRNGD initial seed file
...\c"
          touch $PRNGDSeedFile
          chmod 600 $PRNGDSeedFile
          # Newly installed system may not have
 log files
          [ -s /var/adm/messages ] && \
              cat /var/adm/messages >> $PRNGDSeedFile
          [ -s /var/log/syslog ] && \
              cat /var/log/syslog >> $PRNGDSeedFile
          [ -s /var/cron/log ] && \
              cat /var/cron/log >> $PRNGDSeedFile
          1s -alni /proc >> $PRNGDSeedFile
          ps -efly >> $PRNGDSeedFile
          chmod 400 $PRNGDSeedFile
          echo "done".
      fi
    fi
}

#
# Start the OpenSSH server process
#
startSSHD() {
    # check for configuration file
    if [ ! -f "$sshdConfig" ] ; then
        echo "OpenSSH is not configured. Missing
 file $sshdConfig."
        exit 1
    fi

    # check for all of the keys
    if DSAKeyExists && RSA2KeyExists &&
 RSA1KeyExists; then
        :
    else
        generatekeys
    fi

    $sshdCmd $sshdCmdOptions
}

#
# Start the PRNGD process
#
startPRNGD() {
    if [ "$usePRNGD" = "yes" ] ; then
      if PRNGDSeedExists; then
        :
      else
          generateSeed


 

 

 


 

 

 

 
[View full width]
fi

        setPRNGDConfigFile

        # check that the directory containing the
 entropy pool exists
        [ ! -d $PRNGDEntropyDir ] && mkdir -p
 $PRNGDEntropyDir

        $PRNGDCmd $PRNGDCmdOptions
    fi
}

#
# Stop the OpenSSH server process
#
stopSSHD() {
    realPIDFile=""
    if [ -r "/etc/$sshdPIDFile" ] ; then
      realPIDFile=/etc/$sshdPIDFile
    elif [ -r "/var/run/$sshdPIDFile" ] ; then
      realPIDFile=/var/run/$sshdPIDFile
    else
        echo "OpenSSH server process ID (PID) file
 cannot be located."
    fi

    [ -n "$realPIDFile" ] && kill -TERM 'cat
 $realPIDFile'
}

#
# Stop the PRNGD process
#
stopPRNGD() {
    # PRNGD has its own built method to shutdown
 and save its seed
    $PRNGDCmd --kill $PRNGDEntropyPool > /dev/null
 2>&1
}

#
# Parse command argument
#
case "$1" in
    'start')
      # start the PRNGD process first to gather
 entropy
      startPRNGD
      startSSHD
      ;;

    'stop')
      stopSSHD
      stopPRNGD
      ;;


 

 

 


 

 

 

 
[View full width]
'restart')
      stopSSHD
      stopPRNGD

      startPRNGD
      startSSHD
      ;;

    'keygen')
      # start PRNGD because key generation requires it
      stopSSHD
      startPRNGD

      generateKeys
      stopPRNGD
      ;;

    'seedgen')
      generateSeed
      ;;

    *)
      echo "Usage: $0 { start | stop | restart |
 keygen | seedgen }"
      ;;

esac

exit 0


 

 

Code Example for Packaging Script

The packaging script in this section creates an OpenSSH Solaris package. After OpenSSH is compiled, use this script to create a Solaris package stream. This script has been updated to support OpenSSH 3.5p1. For further information, refer to the Sun BluePrints OnLine articles titled "Building and Deploying OpenSSH on the Solaris Operating Environment" and "Building OpenSSH—Tools and Tradeoffs".

The latest version of this script is available at the Sun BluePrints OnLine tools area:

http://www.sun.com/blueprints/tools/

Usage

Execute this script in the top-level OpenSSH source directory. If needed, copy the script to the OpenSSH source directory. After OpenSSH has been compiled, check the script variables listed in the script to verify the configuration for the environment in which OpenSSH is to be installed.

Note

This script borrows heavily from the Sun Enterprise™ Network Security Service (SENSS) makepackage script. This script uses the openssh.server init script, which is copied over and some of its contents are changed based on the variables set in this script.


 

Contact

For inquiries or feedback, contact openssh_tools@sun.com.

Packaging Script Sample

 

 

 
[View full width]
#!/usr/bin/ksh
#

#
 --------------------------------------------------------------------

# User configuration variables
#
 --------------------------------------------------------------------


#
# Installation directory.
#
# This should be a local directory on the systems
 that will install it.
# If /opt is specified, the package name will be
 appended to the
# install directory name (ie. /opt/OBSDssh).
#
# The default value, if no argument is supplied on
 the command line, is
# /opt. Otherwise, the argument specified will be
 used.
#
# The location for the config files ie sshd_config
 is pulled from
# OpenSSH's config.status.
installDir=/opt
#installDir=/usr/local

#
# OpenSSH Solaris package name.
#
packageName=OBSDssh

#  Check for OpenSSH's config.status as
 configuration is read from there.
if [[ ! -f config.status ]]; then
    print "Unable to read OpenSSH's config.status."
    exit 1
fi
#
# Include the PRNGD tool and associate files.  
(yes/no)
# Check OpenSSH's config.status for
 --with-prngd-socket
#
if grep "with-prngd-socket" config.status > /dev
/null 2>&1; then
   includePRNGD=yes
else
   includePRNGD=no
fi

#
# PRNGD package location.  (PRNGD must already be
 compiled.)
#


 

 

 


 

 

 

 
[View full width]
PRNGDDir=../prngd-0.9.26

#
# Solaris system init script location.
#
initScript=../openssh.server

#
# Install ssh set-user-ID (SUID).   (yes/no)
#
if grep "disable-suid-ssh" config.status > /dev
/null 2>&1; then
    installSSHSUID=no
else
    installSSHSUID=yes
fi

#
 --------------------------------------------------------------------

# No further user configuration should be required
 past this point.
#
 --------------------------------------------------------------------


PATH=/usr/bin:/usr/ccs/bin

# source/current directory
srcDir=$ (pwd)

# build directory
buildDir=/tmp/$packageName/build

# package build directory
packageDir=/tmp/$packageName/package

# OpenSSH files final location
if [[ $installDir == "/opt" ]]; then
    openSSHDir=$installDir/$packageName
else
    openSSHDir=$installDir
fi

# Determine config file location based on config
.status of OpenSSH.
# The returned value needs to be a path not a
 shell variable.
configDir=$( grep @sysconfdir@ config.status  cut
 -f3 -d, )

# determine which ssh permissions to use
if [[ $installSSHSUID == "yes" ]]; then
    sshMode=4755
else
    sshMode=0755
fi


 

 

 


 

 

 

 
[View full width]
# cleanup and process
print "Cleaning up any old build files..."
rm -rf $buildDir $packageDir
mkdir -p $buildDir $packageDir

# create build subdirectories
print "Creating build subdirectories..."
mkdir -p $buildDir/$openSSHDir/bin
mkdir -p $buildDir/$openSSHDir/docs/OpenSSH
mkdir -p $buildDir/$openSSHDir/libexec
mkdir -p $buildDir/$openSSHDir/man/cat1
mkdir -p $buildDir/$openSSHDir/man/cat8
mkdir -p $buildDir/$openSSHDir/sbin
mkdir -p $buildDir/$configDir
mkdir -p $buildDir/etc/init.d
mkdir -p $buildDir/etc/rc0.d
mkdir -p $buildDir/etc/rc1.d
mkdir -p $buildDir/etc/rc2.d
mkdir -p $buildDir/etc/rc3.d
mkdir -p $buildDir/etc/rcS.d
[[ $includePRNGD == "yes" ]] && {
    mkdir -p $buildDir/$openSSHDir/docs/PRNGD
    mkdir -p $buildDir/var/run
}

# copy OpenSSH executables
print "Copying OpenSSH client executables:\c"
dir=$buildDir/$openSSHDir/bin
for file in ssh scp sftp ssh-add ssh-agent
 ssh-keygen ssh-keyscan \
    ssh-keysign; do
    cp $file $dir
    strip $dir/$file
    chmod 755 $dir/$file
    print " $file\c"
done 
print "."

# copy OpenSSH server executable
print "Copying OpenSSH server executable: \c"
file=sshd
dir=$buildDir/$openSSHDir/sbin
cp $file $dir
strip $dir/$file
chmod 755 $dir/$file
print " $file."

# copy OpenSSH sftp server executable
print "Copying OpenSSH libexec executables:\c"


 

 

 


 

 

 

 
[View full width]
dir=$buildDir/$openSSHDir/libexec
for file in ssh-rand-helper sftp-server; do
    cp $file $dir
    strip $dir/$file
    chmod 755 $dir/$file
    print " $file\c"
done
print "."

# install only the preformatted man pages since
 Solaris nroff does not
# understand the BSD formatted ones
print "Copying OpenSSH user preformatted man pages:\c"
dir=$buildDir/$openSSHDir/man/cat1
for file in ssh.0 scp.0 sftp.0 ssh-add.0
 ssh-keygen.0 ssh-agent.0 \
    ssh-keyscan.0 ssh-rand-helper.0 ssh-keysign.0; do
    cp $file $dir
    chmod 644 $dir/$file
    print " $file\c"
done
print "."

print "Copying OpenSSH admin preformatted man
 pages:\c"
dir=$buildDir/$openSSHDir/man/cat8
for file in sftp-server.0 sshd.0; do
    cp $file $dir
    chmod 644 $dir/$file
    print " $file\c"
done
print "."

# create symbolic links to slogin and associated
 man page
print "Creating symbolic links to slogin and
 slogin.0..."
( cd $buildDir/$openSSHDir/bin; ln -s ./ssh slogin )
( cd $buildDir/$openSSHDir/man/cat1; ln -s ./ssh.0
 slogin.0 )

# copy over auxilary config files
#  (Note: The ssh_prng_cmds file is only necessary
 if PRNGD is not used
#   but it is included anyways.)
print "Copying OpenSSH config files:\c"
dir=$buildDir/$configDir
for file in ssh_prng_cmds; do
    cp $file $dir
    chmod 644 $dir/$file
    print "$file\c"
done
cp ssh_config.out $dir/ssh_config
cp sshd_config.out $dir/sshd_config
chmod 644 $dir/ssh_config $dir/sshd_config
print " ssh_config sshd_config."


 

 

 


 

 

 

 
[View full width]
# copy over, fix permissions and ownerships, and
 link up the system
# init script
print "Copying and linking the OpenSSH system init
 script..."
cat $initScript |  \
    sed  -e "s#%%configDir%%#$configDir#g"        
       \
         -e "s#%%openSSHDir%%#$openSSHDir#g  "      \
         -e "s#%%includePRNGD%%#$includePRNGD#g  "\
      > $buildDir/etc/init.d/openssh.server

chmod 744 $buildDir/etc/init.d/openssh.server
ln $buildDir/etc/init.d/openssh.server \
    $buildDir/etc/rc3.d/S25openssh.server
ln $buildDir/etc/init.d/openssh.server \
    $buildDir/etc/rcS.d/K30openssh.server
ln $buildDir/etc/init.d/openssh.server \
    $buildDir/etc/rc0.d/K30openssh.server
ln $buildDir/etc/init.d/openssh.server \
    $buildDir/etc/rc1.d/K30openssh.server
ln $buildDir/etc/init.d/openssh.server \
    $buildDir/etc/rc2.d/K40openssh.server

# if PRNGD is used, copy over the exectuable and
 config files
[[ $includePRNGD == "yes" ]] && {
    print "Copying PRNGD Solaris specific config
 files..."
    cp $PRNGDDir/prngd $buildDir/$openSSHDir/sbin
    cp $PRNGDDir/contrib/Solaris-2.6/prngd.conf
.solaris-26 \
       $buildDir/$configDir/prngd.conf-solaris-2.6
    cp $PRNGDDir/contrib/Solaris-7/prngd.conf
.solaris-7 \
       $buildDir/$configDir/prngd.conf-solaris-2.7
}

# copy over documentation files for OpenSSH and PRNGD
print "Copying OpenSSH and PRNGD documentation
 files:\c"
dir=$buildDir/$openSSHDir/docs/OpenSSH
for file in CREDITS README LICENCE; do
    cp $file $dir
    chmod 644 $dir/$file
    print " $file\c"
done

[[ $includePRNGD == "yes" ]] && {
     cp $PRNGDDir/00README \
        $buildDir/$openSSHDir/docs/PRNGD/README
    chmod 644 $buildDir/$openSSHDir/docs/PRNGD/README
    print " README (PRNGD)\c"
}
print "."


 

 

 


 

 

 

 
[View full width]
# create a Solaris package prototype file
 print "Creating the Solaris package prototype
 file..."
 (
      cd $buildDir
      find . ! -name prototype  sort  pkgproto  \
        awk '
            { $5="root"; $6="other"; }
            $3 == "etc"{ $4="?"; $5="?"; $6="?"; }
            $3 == "etc/rc0.d"    { $4="?"; $5="?";
 $6="?"; }
            $3 == "etc/rc1.d"    { $4="?"; $5="?";
 $6="?": }
            $3 == "etc/rc2.d"    { $4="?"; $5="?";
 $6="?"; }
            $3 == "etc/rc3.d"    { $4="?"; $5="?";
 $6="?"; }
            $3 == "etc/rcS.d"    { $4="?"; $5="?";
 $6="?"; }
          $3 == "etc/init. d"    { $4="?"; $5="?";
 $6="?"; }
          $3 == "etc/init.d/openssh.server  "    {
 $6="sys"; }
          $3 == "etc/prngd.conf-solaris-2.6  "  {
 $6="sys"; }
          $3 == "etc/prngd.conf-solaris-2.7  "  {
 $6="sys"; }
          $3 == "etc/ssh_config  "      { $6="sys"; }
          $3 == "etc/ssh_prng_cmds  "    { $6="sys"; }
          $3 == "etc/sshd_config  "      { $6="sys"; }
          $3 == "var "          { $4="?"; $5="?";
 $6="?"; }
          $3 == "var/run "      { $4="?"; $5="?";
 $6="?"; }
          $3 == "opt "          { $4="?"; $5="?";
 $6="?"; }
          { print; }
          END { print "i pkginfo=info" }' >
 prototype.temp

     sed -e "s/bin\/ssh 0755/bin\/ssh $sshMode/" <
 prototype.temp \
       | grep -v prototype.temp > prototype
    rm -f prototype.temp
)

# create an info file
print "Creating the Solaris package pkginfo file..."
cat > $buildDir/info << __EOF__
PKG=$packageName
NAME=OpenSSH for Solaris
ARCH=$ (uname -p)
VERSION="$(grep SSH_VERSION $srcDir/version.h  sed
 -e 's/.*_\([0-9]\)/\1/g')
CATEGORY=application
BASEDIR=/
CLASSES="none"
__EOF__

# make a package, using the prototype/info files,
 writing to the scratchdir
print "Creating the Solaris package directory..."
pkgmk -d $packageDir -f $buildDir/prototype -r
 $buildDir -o

# store it as Solaris package stream format
print "Creating the Solaris package stream."


 

 

 


 

 

 

 
[View full width]
pkgtrans -os $packageDir $srcDir/$packageName.pkg all

# messages
print
print "package stream file is: $srcDir
/$packageName.pkg"
print "To install: pkgadd -d $packageName.pkg
 $packageName"

# done
exit 0


 

 

 


 

 

 # Example config file - two comments and one
 # keyword-value pair
 Port 22


 

 

Recommendations

During configuration, you will need to make trade-offs between security, ease-of-use, and legacy compatibility. A wide variety of options covering network and protocol support, authentication, and user environment, obscure the individual option's impact on the whole. This section includes some configuration recommendations and discusses the consequences of their usage.

Note

Only the Solaris Secure Shell software and OpenSSH versions that are current at the time of this writing are used. Not all of the options are covered. Consult the vendor documentation for information on the other options and on the options presented here.


 

Server Recommendations

Server configuration specifies how the daemon presents itself on the network, what protocols are offered, and what authentication methods are allowed. Specific recommendations are given for each topic. Recommendations specific to a particular Secure Shell implementation have also been noted.

Protocol Support

Two major versions of the Secure Shell protocol exist. Protocol 1 has been deprecated because of vulnerabilities, such as packet insertion and password-length determination. Whenever possible, use Protocol 2. Unfortunately, many legacy clients support only Protocol 1. If this protocol must be enabled, consult the Legacy Support recommendations later in this chapter. Consider migrating to clients that support Protocol 2 as soon as reasonably possible.

Network Access

By default, the sshd(1M) daemon listens on all network interfaces on its bound ports. For workstations or other systems on which accessibility is desired for all interfaces, this behavior is not a problem. For architectures such as the Service Delivery Network, in which management traffic is limited to a particular interface, this behavior is a problem. Limit network access with the ListenAddress keyword. Access is limited by a particular IP address, not by a network interface.

 

 

 # Listen only to the management network.
 ListenAddress 192.168.0.10


 

 

 


 

To further narrow down what the daemon will listen to, use either a host-based firewall, such as the SunScreen™ software, or TCP Wrappers.

For information about traffic-limited architectures, consult the Sun BluePrints OnLine article "Building Secure N-Tier Environments" (October 2000).

Keep-Alives

Occasionally, connections are temporarily suspended when a route is downed, a machine crashes, a connection is hijacked, or a man-in-the-middle attack is attempted. TCP keep-alives should be sent to detect any of these cases. If TCP keep-alives fail, the server will disconnect the connection and return allocated resources. Regular disconnects can aggravate users on faulty networks.

 

 

 KeepAlive yes


 

 

 


 

Data Compression

Optionally, compression can be used on the encrypted data streams. This use results in bandwidth savings for compressible data, such as interactive logins or log files, at the expense of more CPU resources. For uncompressible data such as encrypted or compressed files, the extra CPU time is wasted and decreases performance. For a single Secure Shell session, these losses are inconsequential. For a file server, the extra load could impact performance. In this case, turn compression off to prevent misconfigured clients from driving up the system load.

 

 

 
[View full width]
# Transferring ASCII data such as interactive
 logins or log files
 Compression yes


 

 

 


 

 

 

 
[View full width]
# Transferring random data such as compressed or
 encrypted files
 # Prevents performance issues and reduces CPU load
 Compression no


 

 

 


 

Privilege Separation

Privilege separation is an OpenSSH-only feature. The sshd(1M) daemon is split into two parts: a privileged process to deal with authentication and process creation and an unprivileged process to deal with incoming network connections. After successful authentication, the privileged process spawns a new process with the privileges of the authenticated user. The goal is to prevent compromise from an error in the network facing process. Unfortunately, privilege separation is not really compatible with pluggable authentication modules or SunSHIELD Basic Security Module (BSM) auditing. Some OpenSSH features are also disabled. If privilege separation is desired, consult the vendor documentation.

Note

The compilation options presented in Chapter 2 disable privilege separation.


 

 

 

 # OpenSSH only
 UsePrivilegeSeparation no


 

 

 


 

Login Grace Time

The default login grace time is the time a connection is allowed to exist before being successfully authenticated. The default of 600 seconds for the Solaris Secure Shell software and 120 seconds for later OpenSSH versions is too long. Reduce the time to 60 seconds.

 

 

 LoginGraceTime 60


 

 

 


 

Password and Public Key Authentication

Passwords are not always appropriate. A stronger means may be required, such as public-key cryptographic two-factor authentication. Secure Shell refers to the key pair as an identity. See "Managing Keys and Identities" on page 71 for more details. When passwords are deemed sufficient, do not allow empty passwords. They are too easy to guess.

 

 

 PasswordAuthentication yes
 PermitEmptyPasswords no
 PubKeyAuthentication yes
 DSAAuthentication yes


 

 

 


 

Superuser (root) Logins

Neither the Solaris Secure Shell software nor OpenSSH honors the values set in the /etc/default/login file. To prevent network superuser (root) logins, they must be explicitly denied. The Solaris Secure Shell software and OpenSSH default to yes. However, the default sshd_config(4) file in the Solaris Secure Shell software disables this feature. This forces a system administrator to log in as an unprivileged user, then change users (su) to the superuser. Enable superuser logins only if the system has no user accounts and the appropriate host protection is in place.

 

 

 PermitRootLogin no


 

 

 


 

Banners, Mail, and Message-of-the-Day

Some sites require that a banner be displayed after a user connects to a system, but before logging in. You can accomplished this with the Banner keyword. Set Banner to /etc/issue so that only one banner file exists for the entire system.

 

 

 Banner /etc/issue


 

 

 


 

In the Solaris OE, the interactive login shell is expected to display the message-of-the-day (MOTD) and to check for new mail. With some versions of OpenSSH, this feature causes the MOTD display and mail check to be done twice. Set these keywords to no to eliminate the duplication.

 

 

 CheckMail no
 PrintMotd no


 

 

 


 

Connection and X11 Forwarding

Secure Shell can tunnel TCP and X protocol connections through encrypted connections established between the client and server. Tunneling the traffic is referred to as forwarding. The forwarding occurs at the application level and is not completely transparent to the applications being forwarded. The applications need some configuration to use the tunnel.

Note

Data is protected only while it is in the tunnel between the client and server. After that, it is normal network traffic in the clear.


 

Tunneled traffic bypasses firewalls and intrusion detection systems. Allowing connection (TCP port) forwarding allows remote users safer access to email or the corporate web server. X forwarding allows system administrators to run GUI applications remotely, such as the Solaris™ Management Console software. This may not be functionality you want your users setting up. You can inconvenience users by turning off the functionality, but as long as they have shell access, they can run their own forwarders. Use role-based access control to explicitly limit what you want your users to do in this case.

If port forwarding is enabled, disable GatewayPorts and notify your users. GatewayPorts allows machines, other than the client, to access the forwarded ports in the tunnel. This access effectively bypasses any firewall usage. Again, users could run their own private forwarders on their client machines to defeat the server restrictions. Consider placing an intrusion detection sensor on the private network side of a Secure Shell bastion host to detect problem traffic.

 

 

 AllowTCPForwarding yes
 GatewayPorts no
 X11DisplayOffset 10
 X11Forwarding yes
 XAuthLocation /usr/X/bin/xauth


 

 

 


 

User Access Control Lists

User access control lists (ACLs) can be specified in the server configuration file. No other part of the Solaris OE honors this ACL. You can either specifically allow or deny individual users or groups. The default is to allow access to anyone with a valid account. You can use ACLs to limit access to particular users in NIS environments, without resorting to custom pluggable authentication modules. Use only one of the following four ACL keywords in the server configuration file: AllowGroups, AllowUsers, DenyGroups or DenyUsers.

 

 

 # Allow only the sysadmin staff
 AllowGroups staff


 

 

 


 

 

 

 # Prevent unauthorized users.
 DenyUsers cheng atkinson


 

 

 


 

User File Permissions

If a user has left their home directory or .ssh files world writable either by accident or by trickery, an intruder could insert identities allowing password-free access or alter the known_hosts file to allow man-in-the-middle attacks. With StrictModes enabled, the sshd(1M) daemon will not allow a login. But, users can be easily confused because they will not know why they cannot log in. No different error message is presented to them.

 

 

 StrictModes yes


 

 

 


 

If you decide to disable StrictModes, consider eliminating public-key-based authentication to prevent user account compromise. The consequence is the elimination of password-free logins for users or automated jobs.

UseLogin Keyword

For OpenSSH only, UseLogin specifies that the OpenSSH sshd(1M) call login(1) instead of performing the initial login tasks itself for interactive sessions. login(1) must be called for BSM auditing. Unless UseLogin is set to yes, cron(1M) will partially break if SunSHIELD BSM auditing is enabled. See "Auditing" on page 81 for details on the consequences of UseLogin and on getting BSM auditing to work successfully. UseLogin will not work if UsePrivilegeSeparation is enabled. Enabling UseLogin disables X11 and port forwarding.

 

 

 UseLogin no


 

 

 


 

Legacy Support

If legacy clients must be supported, strengthen the default configuration as much as possible. Default to Protocol 2 for the clients that support it. Disable all of the rhosts-style authentication methods. Increase the server key size and decrease the ephemeral key regeneration interval to minimize offline factoring attacks against the keys.

 

 

 # Enable protocol 1 but default to protocol 2.
 Protocol 2,1
 # Legacy support options - protocol 1 only
 HostKey /etc/ssh/ssh_host_key
 IgnoreRhosts yes
 IgnoreUserKnownHosts yes
 KeyRegenerationInterval 1800
 RhostsAuthentication no
 RhostsRSAAuthentication no
 RSAAuthentication yes
 ServerKeyBits 1024


 

 

 


 

Client Recommendations

Client configuration specifies host option assignment, data compression, keep-alives, protocol support, and identity management. Specific recommendations are given for each topic.

Host Option Assignment

Configuration options can be assigned to a specific host or to all hosts by using the Host keyword. The value is matched to what the user types on the command line, not to the actual host name of the server. An asterisk (*) is used to set global default options. Options assigned to a specific host have precedence over the global defaults.

 

 

 # Only for a specific host
 Host legacy
 Protocol 1

 # For all hosts
 Host *
 Protocol 2


 

 

 


 

Data Compression

Data compression can be used on the encrypted data stream to save bandwidth. Set to off by default, you should enable it for interactive sessions or for transferring easily compressible data. The compression cost is asymmetric in that compressing the data is more computationally expensive than decompression. Client-side CPU cycles are generally cheaper than server-side CPU cycles. Avoid attempting to compress already compressed or encrypted data to avoid needlessly raising the CPU load on the server.

 

 

 
[View full width]
# For interactive sessions, low bandwidth links,
 or easily
 # compressable files
 Compression yes


 

 

 


 

Keep-Alives

Enable TCP keep-alives to detect downed connections. See "Keep-Alives" on page 44 for the server recommendations.

 

 

 KeepAlive yes


 

 

 


 

Protocol Support

Always use Protocol 2 when possible. See "Protocol Support" on page 43 for the server recommendation.

 

 

 Protocol 2


 

 

 


 

rlogin and rsh

The rlogin and rsh protocols should not be used. Prevent the client from attempting to execute rsh if a Secure Shell connection is refused.

 

 

 FallBackToRsh no
 UseRsh no


 

 

 


 

Server Identity

Verify server identity both by its host key and IP address. For higher levels of identity assurance, set StrictHostKeyChecking to yes and distribute host keys out-of-band. This is impractical when users frequently encounter new hosts. Set StrictHostKeyChecking to ask, and train the users to verify the offered host key with the stored host key on the server. See "Managing Keys and Identities" on page 71 for more information.

 

 

 CheckHostIP yes
 # only access one host
 StrictHostKeyChecking yes


 

 

 


 

 

 

 CheckHostIP yes
 # access a variety of hosts
 StrictHostKeyChecking ask


 

 

 


 

User Identity

User identities are stronger and provide more flexibility than does password authentication. When user identities are combined with agents, password-free logins can safely be obtained if the server permits it. See "Integrating Secure Shell" on page 59 and "Managing Keys and Identities" on page 71 for details.

 

 

 DSAAuthentication yes
 PubkeyAuthentication yes


 

 

Custom Configuration File Distribution

Site-specific configuration files can be automatically installed by using the JumpStart software finish scripts. For more information, refer to JumpStart Technology Effective Use in the Solaris Operating Environment, Sun Microsystems Press, Palo Alto, 2002, by John Howard and Alex Noordergraaf.

The following code box contains an example of the finish script:

 

 

 
[View full width]
#!/bin/sh
 # Example Secure Shell Finish script
 #
 echo "Copying local secure shell configuration..."
 # Preserve original configuration
 mv /a/etc/ssh/sshd_config /a/etc/ssh/sshd_config.orig
 # Install local configuration
 cp ${SI_CONFIG_DIR}/Files/sshd_config /a/etc/ssh
/sshd_config


 

 

 


 

Solaris Fingerprint Database

The MD5 signatures for the Solaris Secure Shell software components have been integrated into the Solaris Fingerprint Database. Refer to the Sun BluePrints article "The Solaris Fingerprint Database – A Security Tool for Solaris Operating Environment Files" at:

http://www.sun.com/blueprints/0501/Fingerprint.pdf

For more information on the Solaris Fingerprint Database, go to:

http://sunsolve.sun.com/pub-cgi/fileFingerprints.pl

Secure Shell Scripts

Automating actions with the Secure Shell client,ssh(1), is mostly a straightforward replacement of either the rsh(1) or rlogin(1) commands. There are, however, some key differences in how ssh(1) performs compared to its counterparts. Additionally, alternate authentication credentials and host keys must be addressed.

rsh(1) Versus ssh(1)

In basic usage, the ssh(1) command is a direct replacement for the rsh(1) command. The major difference between them is authentication. If an ssh(1) command is issued and a password or passphrase is needed, it will be prompted for, then the command will be executed. In this case, the rsh(1) command will fail with a permission denied error.

 

 

 
[View full width]
$ rsh host -1 user cat /etc/passwd
 permission denied
 $ ssh host -1 user cat /etc/passwd
 user@host's password: password
 root:x:0:1:Super-User:/:/sbin/sh
 daemon:x:1:1::/:
 bin:x:2:2::/usr/bin:
 sys:x:3:3::/:
 adm:x:4:4:Admin:/var/adm:
 lp:x:71:8:Line Printer Admin:/usr/spool/lp:
 uucp:x:5:5:uucp Admin:/usr/lib/uucp:
 nuucp:x:9:9:uucp Admin:/var/spool/uucppublic:/usr
/lib/uucp/uucico
 smmsp:x:25:25:SendMail Message Submission Program:/:
 listen:x:37:4:Network Admin:/usr/net/nls:
 nobody:x:60001:60001:Nobody:/:
 noaccess:x:60002:60002:No Access User:/:
 nobody4:x:65534:65534:SunOS 4.x Nobody:/:


 

 

 


 

For background jobs, ssh(1) also supports the -n option to set standard input to /dev/null. Alternatively,-f sets standard input to /dev/null after password or passphrase requests, but before command execution. If no remote execution is required and only port forwarding requested, the -N option can be used (Protocol 2 only).

rcp(1) Versus scp(1)

The rcp(1) command has the same authentication problem as the rsh(1) command. As with ssh(1), the scp(1) command will prompt for passphrases and passwords as needed. Unlike the rcp(1) command, scp(1) displays a progress meter as it copies the file. This behavior can be disabled with the -q option. The scp(1) command can also optionally compress the data stream using the-C option.

The following example shows the rcp authentication problem and thescp command's progress meter.

 

 

 
[View full width]
$ rcp user@host:/etc/passwd /tmp
 permission denied
 $ scp user@host:/etc/passwd /tmp
 user@host's password: password
 passwd 100% |*****************************| 1044 
    00:00


 

 

 


 

telnet(1) Versus ssh(1)

The telnet(1) command is occasionally used to automate connections to systems in situations in which the rlogin(1) and rsh(1) commands cannot be used. Automating a telnet(1) connection requires the script to pass the login, password, and command to the telnet(1) command to execute. The following is a Korn shell script fragment that automates the telnet(1) session:

 

 

 (
  sleep 2
  echo login^M
  sleep 2
  echo password^M
  sleep 2
  echo command^M
  sleep 2
 ) | telnet hostname


 

 

 


 

Unlike telnet(1), this will not work with ssh(1). The Secure Shell client was programmed to ignore passwords that are passed in this manner, as shown in the following example.

 

 

 
[View full width]
$ ( sleep 2 ; echo "password^M"; sleep 2; ls;
 sleep 2 ) | ssh host -1 user
 Pseudo-terminal will not be allocated because
 stdin  is not a terminal.

 user@host's password: password
 Permission denied, please try again.
 Unable to find an authentication method


 

 

 


 

The ssh(1) command can be tricked around this limitation by using Expect. For more information on Expect, refer to the Expect FAQ at: http://expect.nist.gov/FAQ.html

The following is an example of a short Expect script to automate logins with passwords when using the Secure Shell:

 

 

 #!/usr/local/bin/expect
 #
 #
 spawn /usr/bin/ssh host -1 user
 expect {*password:}
 send "password\r"
 #
 expect {*home*} exit
 send "command\r"
 sleep 2
 #
 expect {*home*} exit


 

 

 


 

Automated Logins

Automating logins to a system requires the script to either possess or have access to the needed authentication credentials. The problem is protecting the destination host from compromised credentials. This requires safeguarding the credentials. A balance must be struck between security and cost in terms of scalability and maintenance. There is no perfect solution.

Secure Shell provides several choices of credentials:

  • Embedded passwords

  • Unencrypted identities (discussed in Chapter 6)

  • Embedded passphrases for encrypted user identities (discussed in Chapter 6)

  • Agents

Each choice has a drawback (see TABLE 5-1). The first three choices can be defeated with read access to the secret. The fourth, agents, can be defeated with access to the machine's memory.

 

Table 5-1. Automated Login Issues

Method

Problem

Embedded passwords

Compromised by reading the script source code

Unencrypted user identities

Compromised by copying the private identity key

Embedded passphrases for encrypted user identities

Compromised by reading the script source code

Agents

Requires loading of the agent

 


 

The most resistant solution is to use agents with manually loaded keys. The problem here is twofold: maintenance and scalability. Humans are neither completely reliable nor completely dependable. The operator must be present to reload keys into the agent in the case of a failure (for example, a system crash or power loss). The operator does not scale well either. This solution requires a central machine or small cluster of machines from which remote jobs are started. A potential single-point-of-failure exists.

There is no easy, secure solution to the problem of automated remote access. A compromise solution is to use encrypted user identities in conjunction with RBAC. Secure Shell secures the network connection. The user identity limits the authorization points (the private key and passphrase must be copied first). RBAC also limits the privileges of the account.

Host Keys

The major difference in Secure Shell being a drop-in replacement for the Berkeley r-commands is host key management. Before the user can be authenticated, the destination host's Secure Shell daemon must be authenticated to the client. This is done by matching a locally stored host key copy to the host key offered by the Secure Shell daemon.

When there is no locally-stored copy, both the Solaris Secure Shell software and OpenSSH default to asking whether or not to accept the newly encountered key. This adds complexity to a script, as shown in the following example.

 

 

 $ ssh host
 The authenticity of host 'host' can't be established.
 RSA key fingerprint in md5 is:
 7a:71:ff:d9:6d:19:d6:d9:ef:f9:4d:3f:92:7a:77:7b
 Are you sure you want to continue connecting(yes/no)?


 

 

 


 

The least secure method to remove this complexity is to turn off host key checking by setting StrictHostKeyChecking to no in ~/.ssh/config. The most secure solution is to acquire all of the host keys ahead of time and place them in ~./ssh/known_hosts. See "Managing Keys and Identities" on page 71 for more information on the difficulties of key management.

Proxies

Proxies allow application-layer connections without allowing direct network connectivity. This allows applications to bridge otherwise inaccessible networks. Proxy support can be implemented in either of two ways: using alternative networking shared libraries (for instance, the runsocks command) or using the internal proxy support (ProxyCommand keyword).

The ProxyCommand interface is an external command executed with /bin/sh. The command should read from standard input and write to standard output. See ssh_config(4) and the OpenSSH source code for more details on the interface. The Solaris Secure Shell software provides support for SOCKS 5 servers through the ssh-socks5-proxy-connect(1) command and HTTP proxy servers through the ssh-http-proxy-connect(1) command. Both commands use the ProxyCommand interface and are located in the /usr/lib/ssh directory.

Note

General-usage protocols, such as HTTP and SSH, can be used to allow almost anything across the proxy, including enscapulated IP traffic. Monitor the proxy for suspicious behavior. The encrypted Secure Shell traffic hides the network content but not the endpoints or the amount of bandwidth consumed.


 

The following code example shows the proxy access by using therunsocks command. Some sites require SOCKS_SERVER and LD_LIBRARY_PATH to be explicitly set.

 

 

 
[View full width]
$ /usr/bin/env SOCKS_SERVER=sockserver:1080 \
 LD_LIBRARY_PATH=/usr/local/socks/lib /usr/local
/socks/bin/runsocks \
 /opt/OBSDssh/bin/ssh remote.host.com


 

 

 


 

The following code example shows the proxy access by using the ProxyCommand interface:

 

 

 
[View full width]
$ ssh -o'ProxyCommand=/usr/lib/ssh
/ssh-socks5-proxy-connect \
          -h socks-gw -p 1080 dmz.foo.com 22' dmz
.foo.com
 user@dmz's password: password
 Last login: Thu Dec 10 23:03:04 2002 from foo.bar.com
 Sun Microsystems Inc.   SunOS 5.8     Generic May
 2001
 $


 

 

 


 

The proxy method to access a remote host can be specified on a per-host basis with the ProxyCommand and Host keywords. The shared library method cannot be used in this manner. Note that the entire command string must be on one line.

 

 

 
[View full width]
Host Teach
        ProxyCommand /usr/lib/ssh
/ssh-socks5-proxy-connect -h sockserver -p 1080
 teach.foo.com 22


 

 

 

Role-Based Access Control

First appearing in the Solaris 8 OE release, role-based access control (RBAC) is an alternative to the all-or-nothing superuser privilege model. In the superuser (root) model, the power to do anything to the system—be it deleting files, adding users, starting or stopping daemons—is granted after the superuser privilege level is obtained. RBAC provides the least privilege model.

The least privilege model breaks up the capabilities of the superuser into roles. A role is a special type of user account from which privileged applications might be run. A user assumes a role with the su(1M) command. For example, operators might have the backup role assigned to them that allows them to run ufsdump(1M) with privilege. In addition, users might have one or more roles. Even root can be made into a role to prevent anonymous root logins.

In the Solaris 8 and 9 OE releases, RBAC is optional. It is not on by default because no default roles are created. For sites with earlier Solaris OE releases, an alternative to RBAC is sudo, maintained by Todd Miller.sudo provides the capabilities ofsu(1M) on a per-command, per-user assignment basis.

 

Table 5-2. Pros and Cons of Using RBAC, sudo, and root Shell

Name

Pro

Con

RBAC

Limits privilege by either granting limited root-level privileges or restricting what a user account can do. It is an integral feature of the Solaris OE.

Requires a change in the mindset away from the superuser model. Is not available in the Solaris 2.6 or 7 OE.

sudo

Works on non-RBAC-capable Solaris OE releases.

Must be downloaded, built, and tested. Is not Sun supported software. Grants only limited access to root-level privilege.

root Shell

Most power in using a system.

Any direct root login can do anything to the system. Console logins defeat auditing.

 


 

To Use RBAC to Restrict a User to Only Copying Files

  1. Become the superuser.

  2. Add the execution attributes of the role.

     

     

     # cat <<_EOM_ >> /etc/security/exec_attr
 > Restricted Secure Shell:suser:cmd:::/usr/bin/scp:
 > _EOM_


     

     

     


     

  3. Add the name of the role.

     

     

     # cat <<_EOM_ >> /etc/security/prof_attr
 > Restricted Secure Shell:::scp access only:
 > _EOM_


     

     

     


     

  4. Comment out PROFS_GRANTED=Basic Solaris Users in the /etc/security/policy.conf file.

  5. Assign the user the role.

     

     

     # cat <<_EOM_ >> /etc/user_attr
 > user::::profiles=Restricted Secure Shell
 > _EOM_


     

     

     


     

  6. Change the user's shell to a profile shell.

     

     

     # usermod -s /usr/bin/pfksh user


     

     

     


     

  7. Restart the nscd daemon.

 

 

 # /etc/init.d/nscd stop
 # /etc/init.d/nscd start


 

 

 


 

The user will only be able to execute built-in shell commands and scp(1), as in the following example.

 

 

 
[View full width]
localhost$ ssh remotehost -| user
 user@remotehost's password: password
 Last Login: Thu Dec 12 21:51:44 2002 from someplace
 remotehost$ pwd
 /home/user
 remotehost$ cd /
 remotehost$ ls
 pfksh: ls:  not found
 remotehost$ pwd
 /
 remotehost$ cat /etc/passwd
 pfksh: cat: not found
 remotehost$ exit
 localhost$ ssh remotehost -| user cat /etc/passwd
 Last Login: Thu Dec 12 21:51:44 2002 from someplace
 pfksh: cat: not found
 localhost$ scp index.html user@remotehost:index.html
 user@remotehost's password: password
 index.html       100% |
 ***************************** | 526 00:00
 localhost$


 

 

 


 

For more information on RBAC, refer to the following documents:

For information on sudo, refer to: http://www.courtesan.com/sudo/

Port Forwarding

Secure Shell can enscapsulate TCP-based application data streams and then tunnel them across its secure connection to and from the client and server. This is referred to as port forwarding. Port forwarding is useful for securing communications with legacy platforms or internal systems such as the internal web site, internal Internet relay chat (IRC) network, or email access.

Port forwarding is not transparent to the application. The application requires some configuration to use the forwarded ports. For situations requiring transparency, a network-level solution such as IPsec or VPNs must be used. Port forwarding will not work for UDP-based protocols or for protocols, such as IRC DCC channels, that dynamically allocate a second data stream on a separate port.

Ports to be forwarded can either be specified on the command line or in the client configuration file (recommended for a system with multiple forwarded port). Forwarded ports can also be local (from client to server) or remote (server to the client). Port forwarding and RBAC can provide secure access to an IMAP mail server while preventing the users from having access to the server itself.

The following two examples show the local forwarding of port 8080 on the client to port 80 on the server.

This example shows forwarding using the ssh(1) command:

 

 

 $ ssh -L8080:server:80 server


 

 

 


 

This example shows forwarding using the client's configuration file:

 

 

 Host server
 LocalForward 8080 server:80


 

 

 


 

Note

The Solaris Secure Shell software disables port forwarding by default. See "Connection and X11 Forwarding" on page 46 for more details.


 

To Secure WebNFS Mounts With Port Forwarding

  1. Choose an unused local port and forward it to the WebNFS port on the server.

    A different local port will be needed for each server. This connection must be maintained for the life of the mount.

     

     

     $ ssh -f -N -L3030:server:2049 server


     

     

     


     

  2. Become the superuser.

  3. Mount the file system using the forwarded port.

     

     

     # mount nfs://localhost:3030/export/home /mnt


     

     

     


     

Note

This procedure provides transport-level protection only for the WebNFS traffic. Using Secure Shell in this manner does not provide additional WebNFS authentication.


 

Insecure Service Disablement

Insecure services can be disabled by commenting them out of inetd.conf. The comment character is a hash (#). Consider making a backup copy of inetd.conf before editing. For information on inetd(1M) and inetd.conf(4), consult their respective man pages.

Remove any service not needed for your environment. In particular, remove ftp, telnet, shell, login, and exec. Consider removing echo, discard, daytime, chargen, comsat, and talk services as well. These are normally not needed.

To Disable Insecure Services

  1. Become the superuser.

  2. Edit /etc/inetd.conf and comment out insecure services.

  3. Use the kill(2) command to send the HANGUP signal to inetd(1M).

     

     

     
    [View full width]
    # ps -ef | grep inetd | grep -v grep
     root   153     1  0   Dec 09 ?       0:02 
/usr/sbin/inetd -s
 # kill -HUP 153


     

     

     


     

  4. Ensure that the services have been disabled.

     

     

     
    [View full width]
    $ telnet localhost
 Trying 127.0.0.1...
 telnet: Unable to connect to remote host:
 Connection refused
 $ rsh localhost
 localhost: Connection refused


     

     

     


     

Chapter 6. Managing Keys and Identities

Secure Shell uses public key cryptography to verify servers (host keys) and, optionally, users (identities) on a network that is assumed to be insecure. Challenges are made using the public key, and only the private key owner can answer the challenge correctly. The price of this security is maintaining a set of secrets (private keys) and identifiers (public keys).

The key pairs come in three forms: RSA pairs labeled RSA1 (Protocol 1 only), RSA pairs labeled RSA (Protocol 2 only), and DSA pairs labeled DSA (Protocol 2 only). The key pairs can range in size from 512 to 8192 bits. The ssh-keygen(1) command generates the key pairs.

While host and user identity key pairs are given different treatment in this book, they are essentially the same. Host keys are unencrypted user identity keys stored at a different location

Host Keys

A host key is the public and private key pair used to authenticate the Secure Shell server to the client. The host key provides assurance that the client is communicating only with the correct host by preventing name service spoofing and man-in-the-middle attacks (that is, impersonation of the host). The Secure Shell init script generates a host key pair using the ssh-keygen(1) command if the pair is not present at startup. When the term host key is used by itself, it refers to the public key component of the pair.

At the beginning of a Secure Shell session, the server sends the public host key to the client. The client compares the key to the copy it has in its $HOME/. ssh/known_hosts file. If the key differs, the following warning message is displayed:

 

 

 
[View full width]
$ ssh verney
 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

 @    WARNING: REMOTE HOST IDENTIFICATION HAS
 CHANGED!        @
 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

 Someone could be eavesdropping on you right now 
(man-in-the-middle attack) It is also 
 possible that the RSA host key has been changed.
 The fingerprint for the RSA key sent 
 by the remote host is md5 88:0e:85:4c:69:e2:9d:19
:c1:39:a7:b6:f8:4b:bc:d3. 
 Please contact your system administrator. 
 Add correct host key in /home/melissa/.ssh
/known_hosts 
 Offending key is entry 7 in /home/melissa/.ssh
/known_hosts 
 RSA host key for verney has changed and you have
 requested strict checking.


 

 

 


 

The problem is how to get the public host key securely to the client initially. The ideal solution is to use a name service for host key lookups, as in the case for IP addresses or login UIDs. This approach would eliminate the need for the client to maintain its own database of host keys. Unfortunately, Secure Shell was designed as a point-to-point solution without an integrated public key infrastructure. There has been an IETF proposal to add host key lookups to the domain name service (DNS), but neither the Solaris Secure Shell software or OpenSSH support this functionality at this time.

The simplest, but riskiest, solution is for the client to just accept a new host key when encountered. This places the client at the risk of a man-in-the-middle attack. Advise users who do this to check the host key offered by the Secure Shell server with the host key stored on the server. The two keys must match. The intermediate solution is to compare existing keys and display an error if the keys differ. If a key is newly encountered, prompt the user to accept it or abort the connection. The hardest, but safest, solution is to distribute a known_hosts file to the client with all of the host keys in it. Keys can be gathered out-of-band through the console.

In a small environment, gathering host keys out-of-band and distributing them is not a problem. For large environments, this is not the case. A program would constantly have to search for new machines and update keys as hardware is replaced or operating systems reinstalled. Then, the updated key collection would have to be distributed to every Secure Shell client. Automation can only partially alleviate this issue.

At the Solaris OE install time with the JumpStart software, the machine can be given either the current host key collection or a single server host key. Using the key provided, the system can poll for updated key collections. This approach allows the Secure Shell clients to safely acquire host key information. It does not allow Secure Shell servers to safely register newly generated host keys. The problem is distinguishing between a host key generated from a fresh Solaris OE installation and an imposter on the network.

The obvious solution is to use ssh-keyscan(1) to audit the network for host keys. You will gather a list of host keys for all of the Secure Shell daemons to which your client can connect. It is a nice solution and, at face value, solves the problem of largescale host key gathering. The catch is that you cannot trust the data because you do not know to whom you are communicating. The client could already be impersonated. You do not know if the machine actually exists. The ssh-keyscan(1) command can be used to audit host key changes on the network, but you will not immediately know if it is a legitimate change or an impersonation

User Identities

A user identity is a public and private key pair used to authenticate a user to the system. Secure Shell identities provide an alternative to the standard user name and password authentication scheme. The standard scheme is by far the most popular method for authentication. However, it suffers from a number of well-documented problems. Users tend to write down their passwords, and the scheme allows dictionary attacks, social engineering, and sniffing in unsecured transmission channels. Additionally, there is nothing unique that a user can possess to distinguish that user from an imposter.

A user identity is a two-factor authentication system with three components. An identity does not suffer the majority of problems that password-based systems have. Each component must be in its proper place before the identity can be used. The first component, the public key, must be registered to the Secure Shell server. The second component, the encrypted private key (the first factor), must be possessed by the user. The third component, the passphrase to decrypt the private key (the second factor), must be known to the user.

The drawbacks of identities are increased maintenance costs and lack of scalability. If users forget their passphrases, the private keys cannot be recovered. A new identity will need to be generated and registered. On systems that allow only key-based authentication, the system administration staff will have to register identities on the users' behalf. The public key must be safely registered in a manner that cannot be tampered with in transit (for example, verifying a MD5 key fingerprint over the phone).

The identity system in OpenSSH and the Solaris Secure Shell software does not scale. The server must have file access to the public key to authenticate the identity. Every server must have its own copy of the public key, or NFS home directories must be used. Currently, there is no support to request public identity keys from some other server (for example, an LDAP server).

Caution

 

With NFS home directories for which the NFS clients have write privileges, any single client can compromise the entire key-based authentication system by creating and registering identities in a user's home directory. You can reduce this risk in the Secure Shell server configurations by allowing only password authentication.

 


 

Revoking an identity can also be problematic because the work required is asymmetrical. On the user's side, the passphrase can be forgotten, and the private key can be deleted. On the server's side, the public key entry must be removed from every $HOME/ .ssh/authorized_keys file. In cases in which the account is a group account and the employee is terminated, finding every entry across an enterprise can be difficult.

Identities do have their uses. They can be combined with agents (refer to "Agents" on page 75) to provide secure passphrase-free logins. They also provide a higher assurance of security than passwords.

To Create an Identity

1.
Decide on the type and size of identity to create.

 
2.
Create the identity and enter a passphrase.

The following is an example of creating a 1024-bit RSA identity:

 

 

 

 
[View full width]
$ ssh-keygen -t rsa
 Enter file in which to save the key (/home/user/
.ssh/id_rsa):
 Generating public/private rsa key pair.
 Enter passphrase (empty for no passphrase):
 passphrase
 Enter same passphrase again: passphrase
 Your identification has been saved in /home/user/
.ssh/id_rsa.
 Your public key has been saved in /home/user/.ssh
/id_rsa.pub.
 The key fingerprint is:
 md5 1024 f9:42:d4:0a:af:23:26:22:14:23:4a:8c:22
:14:6f:f7 user@host


 

 

 


 

To Register an Identity

1.
Copy the public key, file .pub, to the remote Secure Shell server.

 
2.
Create the $HOME/.ssh directory with mode go-w if it does not exist.

 
3.
Create the $HOME/.ssh/authorized_keys file with mode go-w if it does not exist.

 
4.
Add the public key to $HOME/.ssh/authorized_keys.

 

To Revoke an Identity

1.
On the Secure Shell server, remove the public key entry from the $HOME/.ssh/authorized_keys file.

 
2.
On the client, remove the private key.
 

Agents

A Secure Shell agent performs identity cryptographic operations on behalf of a client. Whenever a client needs to perform an operation involving a private identity key, the request is passed to the agent. The agent computes the result and passes it back to the client. The client never sees the actual key. This process requires that the agent have the key loaded. Agents allow for passphrase-free logins without the risk of unencrypted identities, as in the following example.

 

 

 
[View full width]
$ ssh morgan
 Last login: Fri Jan 17 14:52:44 2003 from drake
 Sun Microsystems Inc.   SunOS 5.9       Generic
 May 2002
 morgan $


 

 

 


 

Agents work by communicating over a private UNIX socket. This socket is stored in a user-owned, mode 700 directory in the /tmp directory. The naming scheme for the socket is agent. PID_of_the_ssh-agent. A Secure Shell client determines agent usage by the presence of the SSH_AUTH_SOCK and SSH_AGENT_PID environment variables. If the variables are present, an attempt is made to communicate with the specified agent. If the agent does not respond or have a valid identity, the client prompts the user for authentication.

When an agent is started with the ssh-agent(1) command, Bourne shell commands are output that enable Secure Shell clients to communicate with the agent. Using the -c option, C shell commands can alternatively be output. Using the eval(1) built-in shell function, the output can be executed within the current shell by setting the needed environment variables, immediately enabling agent support to the shell and its future children.

The following is an example of starting an agent:

 

 

 
[View full width]
$ ssh-agent
 SSH_AUTH_SOCK=/tmp/ssh-kxo27123/agent.27123;
 export SSH_AUTH_SOCK;
 SSH_AGENT_PID=27124; export SSH_AGENT_PID;
 echo Agent pid 27124;


 

 

 


 

The following is an example of starting an agent within the shell:

 

 

 $ eval 'ssh-agent'
 Agent pid 16867


 

 

 


 

A newly invoked agent has no identities loaded. A separate command, ssh-add(1), controls the listing, loading, and deleting of identities. The default is to load all of the various identity types (identity for Protocol 1 only, id_dsa, and id_rsa) serially if they are present. A specific identity can be loaded by specifying it on the command line.

The following is an example of listing an empty agent:

 

 

 $ ssh-add -1
 The agent has no identities.


 

 

 


 

The following is an example of listing an agent with one RSA key:

 

 

 
[View full width]
$ ssh-add -1
 md5 1024 13:cd:f7:19:87:4c:8e:5d:6c:c2:cc:51:07
:af:d2:21
 /home/user/.ssh/id_rsa(RSA)


 

 

 


 

The following is an example of adding all identities in the $HOME/.ssh file:

 

 

 
[View full width]
$ ssh-add
 Enter passphrase for /home/user/.ssh/id_rsa:
 passphrase
 Identity added: /home/user/.ssh/id_rsa (/home
/user/.ssh/id_rsa)
 Enter passphrase for /home/user/.ssh/id_dsa:
 passphrase
 Identity added: /home/user/.ssh/id_dsa(/home/user
/.ssh/id_dsa)


 

 

 


 

The following is an example of adding a specific identity:

 

 

 
[View full width]
$ ssh-add .ssh/remote
 Enter passphrase for .ssh/remote: passphrase
 Identity added: .ssh/remote(.ssh/remote)


 

 

 


 

Common Desktop Environment Support

The Common Desktop Environment (CDE) can have integrated agent support. A single agent can be started that will serve all of the child, dtterm(1) and xterm(1), terminal windows. Only one agent needs to be started for each user on the system. Agent support is added by customizing the $HOME/.dtprofile file. The changes take effect on the next session.

The ssh-add(1) command by itself cannot prompt for passphrases at the beginning of a CDE session. An X-based passphrase requestor is needed. The ssh-add(1) command can use an external passphrase requestor if the SSH_ASKPASS and DISPLAY environment variables are set. The SSH_ASKPASS variable must be set to the proper requestor $PATH. Jim Knoble has written x11-ssh-askpass, which works well for this purpose. It is available at:

http://www.jmknoble.net/software/x11-ssh-askpass/

An X-based passphrase requestor is not required to use agents with CDE. Using both the agent and the requestor, a limited form of single sign-on can be constructed. After a user is authenticated to the system for his or her CDE session and the passphrase is authenticated, that user can access any system that honors that identity without needing an additional user-visible authentication (that is, a separate password). (This is for Secure Shell logins and file transfers only.)

The following is an example of agent support for CDE in the $HOME/.dtprofile file:

 

 

 
[View full width]
# Start an agent for the session.
 # Use Solaris Secure Shell if available;
 otherwise, use OpenSSH.
 if [ -x /usr/bin/ssh-agent ]; then
      eval '/usr/bin/ssh-agent'
      solarisoe=1;
 elif [ -x /opt/OBSDssh/bin/ssh-agent ]; then
      eval '/opt/OBSDssh/bin/ssh-agent'
      solarisoe=0;
 fi
 # Only add keys if x11-ssh-askpass is available.
 if [ -x /usr/local/libexec/x11-ssh-askpass ]; then
      SSH_ASKPASS=/usr/local/libexec
/x11-ssh-askpass ; export SSH_ASKPASS
 elif [ -x /opt/OBSDssh/libexec/x11-ssh-askpass ];
 then
      SSH_ASKPASS=/opt/OBSD/ssh/libexec
/x11-ssh-askpass ; export SSH_ASKPASS
 fi
 if [ ! -z "$SSH_ASKPASS" ]; then
      if [ $solarisoe -eq 1 ]; then
           /usr/bin/ssh-add
      else
           /opt/OBSD/ssh/bin/ssh-add
      fi
fi


 

 

 


 

Removing Agents

When an agent is no longer needed, it should either be terminated, or the identities should be deleted from memory. If you are going to be away from the keyboard for a while, you should delete the identities. An agent is terminated by calling the ssh-agent(1) command with the -k option. Simply logging out will not terminate an agent. If a user automatically starts an agent with each login, the agents will accumulate until they are terminated with the -k option, the kill(1) command, or a system reboot.

The following is an example of unloading identities:

 

 

 $ ssh-add -D
 All identities removed.


 

 

 


 

The following example shows how to unset the two environment variables. Use eval(1) to cause this code to be executed within your current shell:

 

 

 $ ssh-agent -k
 unset SSH_AUTH_SOCK;
 unset SSH_AGENT_PID;
 echo Agent pid 16867 killed;


 

 

 


 

If agents were started automatically at the beginning of a CDE session, they must be terminated to prevent agent processes from building up on the system. Place the needed code in the $HOME/.dt/sessions/sessionexit file to terminate an agent at logout. See dtsession(1X) for more details.

The following is an example of the $HOME/.dt/sessions/sessionexit file:

 

 

 
[View full width]
#!/usr/bin/ksh
 # Eliminate the agent for the session
 if [ -x /usr/bin/ssh-agent ]; then
 if  /usr/bin/ssh-add -D >/dev/null 2>&1; then
        eval '/usr/bin/ssh-agent -k'
 fi
 else if [ -x /opt/OBSDssh/bin/ssh-agent ]; then
 if /opt/OBSDssh/bin/ssh-agent -D >/dev/null 2>&1;
 then
                 eval '/opt/OBSDssh/bin/ssh-agent -k'
 fi
         fi
 fi


 

 

 


 

Agent Risks

Agents are not without their risks. The only access control to the agent socket is the private user-owned directory in the /tmp directory. Another user instance or the superuser could easily communicate with the agent and gain access to remote hosts. Additionally, the private identity keys are held in memory by the agent. Access to the memory by the superuser, a system debugger, or another instance of the same user could result in an identity compromise by reading the unencrypted private key.

The following is an example of a user agent compromise by the superuser:

 

 

 
[View full width]
# ls -l /tmp/ssh-gsN27129
 total 0
 srwxr-xr-x l user staff             0 Jan 25 16
:19 agent.27129
 # SSH_AUTH_SOCK=/tmp/ssh-gsN27129/agent.27129;
 export SSH_AUTH_SOCK 
 # SSH_AGENT_PID=27130; export SSH_AGENT_PID 
 # ssh-add -l
 md5 1024 bd:bc:2b:4f:5c:ee:14:b3:cd:28:e2:8b:dc
:af:13:4f
 /home/user/.ssh/id_rsa(RSA)


 

 

 


 

Agent forwarding mitigates some of the risks. With agent forwarding, the agent runs on a trusted machine, such as a personal laptop. The information needed to access the agent is passed through the Secure Shell tunnel throughout the connection chain. The intermediary Secure Shell daemons act as proxy agents. This limits the existence of the private identity key to the trusted machine. The intermediary machines need only a copy of the public identity key.

The following is an example of a simple agent forwarding session:

 

 

 
[View full width]
hook $ eval '/usr/bin/ssh-agent'
 Agent pid 602
 hook $ ssh-add
 Enter passphrase for /home/user/.ssh/id_rsa:
 passphrase
 Identity added: /home/user/.ssh/id_rsa(/home/user
/.ssh/id_rsa)
 hook $ cat $HOME/.ssh/config
 Host *
         ForwardAgent yes
 hook $ ssh blood
 Last login: Mon Jan 27 21:29:10 2003 from hook
 Sun Microsystems Inc.   SunOS 5.9       Generic
 May 2002
 blood $ ssh calicojack
 Last login: Mon Jan 27 21:29:41 2003 from blood
 Sun Microsystems Inc.   SunOS 5.9       Generic
 May 2002
 calicojack $ ^D


 

 

 


 

In this example, the user starts on hook. An agent is started, and one key is loaded. The user then logs in to blood, then to calicojack. Notice that calicojack did not prompt for authentication. The user's private key never left hook because blood was not trusted with the private identity (key)

Problems

This section contains descriptions of and solutions to the problems most frequently encountered when using Secure Shell.

Server Does Not Produce Log File Output

By default, sshd produces auth.info-level messages. The default configuration of syslogd(1M) ignores these. syslog.conf(4) must have an entry added for these messages. Then, the log file needs to be created, and syslogd needs a HUP signal, as in the following example.

 

 

 # grep auth.info /etc/syslog.conf
 auth.info     /var/adm/sshd.log
 # touch /var/adm/sshd.log
 # pkill -HUP syslogd


 

 

 


 

Note

A tab must separate the two fields.


 

If debugging information is needed, add an entry for auth.debug.

Public Key Authentication Is Not Working

Verify that the public key is in the remote ~/.ssh/authorized_keys file and that the file is neither group nor world writable. See "Debugging a Secure Shell Connection" on page 110 for more information.

Trusted Host Authentication Is Not Working

Verify that this feature has not been disabled in the sshd_config file and that ssh(1) is installed as setuid root.

X Forwarding Is Not Working

Verify the following:

Wildcards and Shell Variables Fail on the scp(1) Command Line

Wildcards and shell variables must be escaped, or the local shell will expand them, as in the following example:

 

 

 
[View full width]
$ scp panther@mainwaring:${HOME}/public_html/ssh
.html /tmp/toast
 panther@mainwaring's password: password scp: 
/home/panther/public_html/ssh.html: No such file or
 directory
 $ scp panther@mainwaring:\$\{HOME\}/public_html
/ssh.html /tmp/toast
 panther@mainwaring's password: password ssh.html 
            100% |*****************************| 
 3529        00:00


 

 

 


 

Superuser (root) Is Unable to Log In

To permit superuser logins, the PermitRootLogin keyword must be set to yes in the sshd_config file.

Note

If root is a role in the role-based access control model, then the value of PermitRootLogin is overridden by pam_roles(5).


 

Startup Performance Is Slow

Verify that ssh(1) is using /dev/urandom by using TRuss to check that /dev/urandom is opened successfully, as in the following example.

 

 

 
[View full width]
$ truss -t open -o /tmp/ssh.trace ssh localhost
 <either login then logout or let the connection
 timeout>
 $ grep random /tmp/ssh.trace
 open64("/dev/urandom", O_RDONLY)                 
  = 5
 open("/dev/urandom", O_RDONLY)                   
  = 6


 

 

 


 

Protocol 1 Clients Are Unable to Connect to Solaris Secure Shell Systems

By default, the Solaris Secure Shell software disables Protocol 1. Comment out the Protocol 2 line with a hash (#) symbol. Uncomment the Protocol 2,1 line. Restart the sshd(1M) daemon by sending the HUP signal.

The following example shows the Solaris Shell defaults:

 

 

 # Only v2 (recommended)
 Protocol 2


 

 

 


 

The following example shows how to enable Protocol 1:

 

 

 # Only v2 (recommended)
 # Protocol 2
 #
 # Both v1 and v2 (not recommended)
 Protocol 2,1


 

 

 


 

Privilege Separation Does Not Work in the Solaris Secure Shell Software

This functionality does not currently exist.

cron(1M) Is Broken

OpenSSH lacks integration into BSM by not correctly assigning an audit ID. This causes both BSM and cron(1M) to fail when a crontab entry is edited. A workaround for crontab editing is to use Telnet to connect to the local host through the loopback interface. Telnet will invoke login(1), which sets the audit ID correctly. The Solaris Secure Shell software does not have this problem.

Message-of-the-Day Is Displayed Twice

By default, PrintMotd is set to yes in the sshd_config file. In the Solaris OE, the login shell is expected to display the message-of-the-day. The Secure Shell daemon should not display it. Set PrintMotd to no to stop this behavior.

Solutions

This section contains solutions for commonly asked questions about Secure Shell.

Debugging a Secure Shell Connection

When sessions are encrypted, debugging tools such as tcpdump(1M) and truss(1) provide less assistance. On the client, debug information is generated with the -v flag. Up to three -v flags can be used to increase the debugging information verbosity. The flag for the server is -d. Alternatively, the level of debugging information can be set using the LogLevel keyword in the configuration file (~/.ssh/config for the client and sshd_config for the server).

The following example shows debugging on the command line:

 

 

 $ ssh -v -v -v bonnet


 

 

 


 

The following example shows how to set up debugging by using the ~/.ssh/config or sshd_config file:

 

 

 LogLevel DEBUG


 

 

 


 

Understanding Differences in OpenSSH and Solaris Secure Shell Software

The Solaris Secure Shell software has BSM support, proxy commands (ssh-socks5-proxy-connect and ssh-http-proxy-connect), localization and internationalization support, and configurable login attempts (MaxAuthTries and MaxAuthTriesLog). OpenSSH does not support these features. OpenSSH supports privilege separation and additional ciphers that Solaris Secure Shell software does not support.

Integrating Solaris Secure Shell and SEAM (Kerberos)

Presently, there is no integration between the Solaris Secure Shell software and SEAM.

Forcing Remote X11 Users to Use Secure Shell Sessions

For Solaris 9 OE systems, add -nolisten tcp to Xsun in /usr/dt/config/Xservers, then restart the X daemon. Make sure to preserve a copy of Xservers to maintain changes in case of patches or OS upgrades.

Determining the Server Version String

When clients connect, the server identifies itself with a version string. Connecting by Telnet to the server and sending a carriage return will return the version string and close the connection, as in the following example.

 

 

 $ (sleep 1; print "\n") |telnet localhost 22
 Trying 127.0.0.1...
 Connected to localhost.
 Escape character is '^]'.
 SSH-2.0-Sun_SSH_1.0
 Connection to localhost closed by foreign host.


 

 

 


 

Altering the Server Version String

In OpenSSH, the version string can be altered by editing the value of SSH_VERSION in version.h before compilation. Changing the version string to obscure the specific OpenSSH release risks breaking clients that use the version string to work around server bugs. The version string cannot be changed in the Solaris Secure Shell software.

CERT Advisory CA-2002-18

The default configuration of the Solaris Secure Shell software is not believed to be vulnerable. To be vulnerable, sshd_config must be updated to contain the following:

 

 

 PAMAuthenticationViaKBDInt yes
 KbdInteractiveAuthentication yes


 

 

 


 

The default for KbdInteractiveAuthentication is no. Patch ID 113273 fixes this problem.

Appendix A. Secure Shell Usage

This appendix is a basic guide to Secure Shell usage. For more information, refer to the Solaris 9 System Administration Guide: Security Services book at docs.sun.com and the following man pages:

Client Usage

This section covers the client-side usage of Secure Shell. The basics of remote host connections and job executions, along with file transfers, are covered. The more advanced client usage of identities, agents, port and X forwarding, and proxies are also covered. Examples are used to demonstrate the various features. This is meant to be a brief introduction, not an in-depth guide.

Connecting to a Host

The following example shows the basic syntax of the ssh(1) command:

 

 

 
[View full width]
$ ssh remote
 user@remote's password: password
 Last login: Wed Dec 18 00:12:38 2002 from someplace
 Sun Microsystems Inc.    SunOS 5.9       Generic
 May 2002
 remote $


 

 

 

 


 

Executing a Command on a Remote Host

The ssh(1) command's remote job form is ssh remote_host job, as shown in the following example:

Note

Shell variables are expanded on the local side, unless they are escaped.


 

 

 

 $ ssh remote cat /var/sadm/system/admin/CLUSTER
 user@remote's password: password
 CLUSTER=SUNWCXall


 

 

 


 

Copying a File

The scp(1) command's form is scp source destination. The following example demonstrates how to copy a local file to a remote host:

 

 

 
[View full width]
$ scp 816-5241.pdf remote:/tmp
 user@remote's password: password
 816-5241.pdf         100%
 |*****************************| 87388      00:00


 

 

 


 

The following example demonstrates how to copy a file from a remote host to a local host:

 

 

 
[View full width]
$ scp remote:/tmp/816-5241.pdf /tmp
 user@remote's password: password
 816-5241.pdf         100%
 |*****************************| 87388      00:00


 

 

 


 

Using Identity Keys

This section contains examples of generating, registering, and using user identities. Agents for passphrase-free logins are also covered.

Generating an Identity

Note

OpenSSH has no default key type. The key type must be specified. The Solaris Secure Shell software defaults to Protocol 2 RSA keys.


 

The following example shows how to generate Protocol 2 RSA keys:

 

 

 
[View full width]
$ ssh-keygen -t rsa
 Enter file in which to save the key(/home/user/
.ssh/id_rsa):
 Generating public/private rsa key pair.
 Enter passphrase(empty for no passphrase): passphrase
 Enter same passphrase again: passphrase
 Your identification has been saved in /home/user/
.ssh/id_rsa.
 Your public key has been saved in /home/user/.ssh
/id_rsa.pub.
 The key fingerprint is:
 md5 1024 f9:42:d4:0a:af:23:26:22:14:23:4a:8c:22
:14:6f:f7 user@host


 

 

 


 

The following example shows how to generate a 2048-bit DSA key:

 

 

 
[View full width]
$ ssh-keygen -t dsa -b 2048
 Enter file in which to save the key(/home/user/
.ssh/id_dsa):
 Generating public/private dsa key pair.
 Enter passphrase(empty for no passphrase): passphrase
 Enter same passphrase again: passphrase
 Your identification has been saved in /home/user/
.ssh/id_dsa.
 Your public key has been saved in /home/user/.ssh
/id_dsa.pub.
 The key fingerprint is:
 md5 2048 3c:dd:5a:8a:37:60:89:ff:ef:4a:bb:b5:bf
:37:d5:78 user@host


 

 

 


 

The following example shows how to generate a Secure Shell Protocol 1 RSA key:

 

 

 
[View full width]
$ ssh-keygen -t rsa1
 Enter file in which to save the key(/home/user/
.ssh/identity):
 Generating public/private rsa1 key pair.
 Enter passphrase(empty for no passphrase): passphrase
 Enter same passphrase again: passphrase
 Your identification has been saved in /home/user/
.ssh/identity.
 Your public key has been saved in /home/user/.ssh
/identity.pub.
 The key fingerprint is:
 md5 1024 de:30:33:84:45:1d:5d:f5:e7:84:30:58:be
:b5:28:44 user@host


 

 

 


 

Registering an Identity

Install the generated public key into the authorized_keys file on the destination host, as in the following example. The private key is installed on the originating host of the connection.

 

 

 $ cd ~/.ssh
 $ touch authorized_keys
 $ chmod 744 authorized_keys
 $ cat id_rsa.pub >> authorized_keys


 

 

 


 

Using the Identity

The following example shows how to use the key:

 

 

 
[View full width]
$ ssh remote
 Enter passphrase for key '/home/user/.ssh/id_rsa'
: passphrase
 Last login: Thu Dec 19 16:48:43 2002 from server
 Sun Microsystems Inc.   SunOS 5.9       Generic
 May 2002
 remote $


 

 

 


 

Using Agents

This section contains examples of how to set up agents, use agent keys, and stop the agent. The following commands are used:

Setting Up Agents

The following example shows how to set up an agent within the parent shell:

 

 

 $ eval `ssh-agent`
 Agent pid 16867
 $


 

 

 


 

Loading Agents

The following example shows the default behavior when loading all of the identities that are present in the $HOME/.ssh directory:

 

 

 
[View full width]
$ ssh-add
 Enter passphrase for /home/user/.ssh/id_rsa:
 passphrase
 Identity added: /home/user/.ssh/id_rsa(/home/user
/.ssh/id_rsa)
 Enter passphrase for /home/user/.ssh/id_dsa:
 passphrase
 Identity added: /home/user/.ssh/id_dsa(/home/user
/.ssh/id_dsa)


 

 

 


 

The following example shows how to add a specific identity:

 

 

 $ ssh-add .ssh/remote
 Enter passphrase for .ssh/remote: passphrase
 Identity added: .ssh/remote(.ssh/remote)


 

 

 


 

Listing Agent Identities

The command for listing agent identities is the same, no matter how many identities have been loaded—only the output changes.

The following example shows the output for listing an empty agent:

 

 

 $ ssh-add -l
 The agent has no identities.


 

 

 


 

The following example shows the output for listing an agent with one identity loaded:

 

 

 
[View full width]
$ ssh-add -l
 md5 1024 13:cd:f7:19:87:4c:8e:5d:6c:c2:cc:51:07
:af:d2:21
 /home/user/.ssh/id_rsa(RSA)


 

 

 


 

Removing Agent Identities

The following example shows how to unload a specific identity:

 

 

 $ ssh-add -d id_rsa
 Identity removed: id_rsa(id_rsa.pub)


 

 

 


 

The following example shows how to unload all of the identities in an agent:

 

 

 $ ssh-add -D
 All identities removed.


 

 

 


 

Stopping the Agent

The following example shows how to stop an agent. Use eval(1) to unset the two shell variables.

 

 

 $ ssh-agent -k
 unset SSH_AUTH_SOCK;
 unset SSH_AGENT_PID;
 echo Agent pid 16867 killed;


 

 

 


 

Forwarding Ports

Note

The Solaris Secure Shell software defaults to having port forwarding disabled on the server.


 

The following example shows a local forward failing because port forwarding is disabled on the server:

 

 

 $ telnet localhost 2020
 Trying 127.0.0.1...
 Connected to localhost.
 Escape character is '^]'.
 Connection to localhost closed by foreign host.


 

 

 


 

Setting Up Local Forwarding

The form for local forwarding is ssh -L local_port:destination_host:destination_port host. The destination host for the forwarded port does not need to be the same as port on the Secure Shell server. The following example shows the forwarding of the local host port, 2020, to the remote host's port, 23 (Telnet):

 

 

 
[View full width]
$ ssh -L 2020:remote:23 remote
 Enter passphrase for key '/home/beth/.ssh/id_rsa'
: passphrase
 Last login: Thu Dec 19 20:12:14 2002 from server
 Sun Microsystems Inc.  SunOS 5.9       Generic
 May 2002
 remote $


 

 

 


 

The following example shows how to test the forwarded port:

 

 

 
[View full width]
$ telnet localhost 2020
 Trying 127.0.0.1...
 Connected to localhost.
 Escape character is '^]'. 


 SunOS 5.9
 login: name Password: password
 Last login: Thu Dec 19 20:14:05 from server
 Sun Microsystems Inc.   SunOS 5.9       Generic
 May 2002
 remote $


 

 

 


 

Setting Up Remote Forwarding

The form for remote forwarding ssh -R server_port:destination_host:destination_port server. The destination host does not have to be the Secure Shell server. It is often the originating host. The following example shows the forwarding of the server's port, 2020, to port 23 (Telnet):

 

 

 
[View full width]
$ ssh -R 2020:remote:23 remote
 Enter passphrase for key '/home/user/.ssh/id_rsa'
: passphrase
 Last login: Thu Dec 19 20:34:25 2002 from server
 Sun Microsystems Inc.  SunOS 5.9       Generic
 May 2002
 remote /home/user $ telnet localhost 2020
 Trying 127.0.0.1...
 Connected to localhost.
 Escape character is '^]'.
 login: user
 Password: password
 Last login: Tue Dec 17 21:16:25 from remote
 Sun Microsystems Inc.  SunOS 5.9       Generic
 May 2002
 server $


 

 

 


 

Enabling X Forwarding

Note

The Solaris Secure Shell software defaults to having X forwarding disabled on the server.


 

The following example shows how to enable X forwarding by adding the following lines to the ~/.ssh/config file:

 

 

 ForwardX11 yes
 XAuthLocation /usr/X/bin/xauth


 

 

 


 

The following example shows how to enable X forwarding by using the -X option:

 

 

 $ ssh -X host


 

 

 


 

Checking the $DISPLAY Variable

The following example shows how to check the $DISPLAY variable:

 

 

 
[View full width]
$ echo $DISPLAY
 :0.0
 $ ssh remote
 Enter passphrase for key '/home/user/.ssh/id_rsa'
: passphrase
 Last login: Thu Dec 19 19:42:30 2002 from server
 Sun Microsystems Inc.  SunOS 5.9       Generic
 May 2002
 remote $ echo $DISPLAY
 remote:10.0


 

 

 


 

Using Proxies

Note

The ssh-http-proxy-connect(1) command and the ssh-socks5-proxy-connect(1) command are available only in the Solaris Secure Shell software.


 

The following example shows how to use a proxy:

 

 

 
[View full width]
$ ssh -o'ProxyCommand=/usr/lib/ssh
/ssh-socks5-proxy-connect \


 -h socks-gw -p 1080 dmz.foo.com 22' dmz.foo.com
 user@dmz's password: password
 Last login: Thu Dec 10 23:03:04 2002 from foo.bar.com
 Sun Microsystems Inc.  SunOS 5.8       Generic
 May 2001
 $


 

 

 


 

Locating Client Configuration Files

The individual client configuration file and keys are kept in the .ssh directory in the user's home directory. The global client configuration file, ssh_config, resides with the other server configuration files and keys.

The following example shows the contents of the ~/.ssh directory:

 

 

 
[View full width]
/home/user/.ssh $ ls -al
 total 48
 drwxr-xr-x   2 user staff        512 Dec 10 10:27 .
 drwxr-xr-x  26 user other       2560 Dec 18 10:32 ..
 -rw-r--r--   1 user staff       225 Dec 10 10:27
 authorized_keys
 -rw-r--r--   1 user staff        995 Dec 14 17:06
 config
 -rw-------   1 user staff        951 Dec 10 10:26
 id_rsa
 -rw-r--r--   1 user staff        225 Dec 10 10:26
 id_rsa.pub
 -rw-r--r--   1 user staff       2325 Dec 18 12:51
 known_hosts


 

 

 


Server Usage

This section covers the server-side usage of Secure Shell. The basics of starting and stopping the daemon, regenerating host keys, and using TCP Wrappers support are covered. Examples are used to demonstrate the various features. This is meant to be a brief introduction, not an in-depth guide.

Starting the Server

The following example shows how to start the Solaris Secure Shell daemon:

 

 

 # /etc/init.d/sshd start


 

 

 


 

The following example shows how to start OpenSSH:

 

 

 # /etc/init.d/openssh.server start


 

 

 


 

Stopping the Server

The following example shows how to stop the Solaris Secure Shell daemon:

 

 

# /etc/init.d/sshd stop


 

 

 


 

The following example shows how to stop OpenSSH:

 

 

 # /etc/init.d/openssh.server stop


 

 

 


 

Locating Server Configuration Files

For the Solaris Secure Shell software, the server configuration files and keys are stored in the /etc/ssh directory.

 

 

 
[View full width]
$ ls -al /etc/ssh
 total 30
 drwxr-xr-x   2 root     sys          512 Nov 26
 15:35 .
 drwxr-xr-x  53 root     sys         3584 Dec  9
 13:26 ..
 -rw-r--r--   1 root     sys          861 Nov 26
 15:02 ssh_config
 -rw-------   1 root     root         668 Nov 26
 15:35 ssh_host_dsa_key
 -rw-r--r--   1 root     root         602 Nov 26
 15:35 ssh_host_dsa_key.pub
 -rw-------   1 root     root         883 Nov 26
 15:35 ssh_host_rsa_key
 -rw-r--r--   1 root     root         222 Nov 26
 15:35 ssh_host_rsa_key.pub
 -rw-r--r--   1 root     sys         5119 Nov 26
 15:02 sshd_config


 

 

 


 

For OpenSSH, the server configuration files and keys are placed in various locations, determined by the configuration of OpenSSH at buildtime. The usual locations are the /etc, /etc/openssh, or /usr/local/etc directory. The configuration file for PRNGD could also be present.

The following example shows the contents of the /etc/openssh directory:

 

 

 
[View full width]
$ ls -al /etc/openssh
 total 46
 drwxr-xr-x   2 root     other         512 Dec 13
 21:34 .
 drwxr-xr-x  28 root     sys          3072 Dec 13
 21:33 ..
 lrwxrwxrwx   1 root     other          35 Dec 13
 21:33 prngd.conf ->
 /etc/openssh/prngd.conf-solaris-2.7
 -rw-------   1 root     other         946 Dec 13
 18:16 prngd.conf-solaris-2.6
 -rw-------   1 root     other        2141 Dec 13
 18:16 prngd.conf-solaris-2.7
 -rw-r--r--   1 root     other        1144 Dec 13
 18:16 ssh_config
 -rw-------   1 root     other         668 Dec 13
 21:34 ssh_host_dsa_key
 -rw-r--r--   1 root     other         602 Dec 13
 21:34 ssh_host_dsa_key.pub
 -rw-------   1 root     other         527 Dec 13
 21:34 ssh_host_key
 -rw-r--r--   1 root     other         331 Dec 13
 21:34 ssh_host_key.pub
 -rw-------   1 root     other         883 Dec 13
 21:34 ssh_host_rsa_key
 -rw-r--r--   1 root     other         222 Dec 13
 21:34 ssh_host_rsa_key.pub
 -rw-r--r--   1 root     other        2330 Dec 13
 18:16 ssh_prng_cmds
 -rw-r--r--   1 root     other        2464 Dec 13
 21:35 sshd_config


 

 

 


 

Generating New Server Host Keys

Generating new server host keys is a three-step process. First, the Secure Shell server must be stopped. Second, the existing keys must be deleted. Third, the Secure Shell server must be restarted, as in the following example:

 

 

 # /etc/init.d/sshd stop
 # cd config_directory
 # rm ssh_host*
 # /etc/init.d/sshd start


 

 

 


 

Note

Generating new server host keys will cause clients with the existing hosts key to display an error message when connecting to the host. The message will persist until the clients are updated with the new host key.


 

Supporting TCP Wrappers

See hosts_access(4) for details on the format for the /etc/hosts.allow and /etc/hosts.deny files.

Note

TCP Wrappers support is optional in OpenSSH. See "TCP Wrappers" on page 33 for instructions on its inclusion.


 

The following example shows how to allow only local network hosts access by setting up the hosts.deny and hosts.allow files:

 

 

 # echo "sshd: ALL" >> /etc/hosts.deny
 # echo "sshd: LOCAL" >> /etc/hosts.allow


 

 

 


 

This example shows how to test local access:

 

 

 
[View full width]
$ ssh server
 user@server's password: password
 Last login: Tue Dec 17 21:15:07 2002 from some.place
 Sun Microsystems Inc.     SunOS 5.8       Generic
 Patch   October 2001
 server /home/user $ ^D
 Connection to server closed.


 

 

 

This example shows how to test remote access by attempting a connection from a remote host outside of the server's local domain:

 

 
[View full width]
$ ssh server.remote
 ssh_exchange_identification: Connection closed by
 remote host


 

 

Reference

SSHD_CONFIG(5)            OpenBSD Programmer's Manual           SSHD_CONFIG(5)

NAME
     sshd_config - OpenSSH SSH daemon configuration file

SYNOPSIS
     /etc/ssh/sshd_config

DESCRIPTION
     sshd(8) reads configuration data from /etc/ssh/sshd_config (or the file
     specified with -f on the command line).  The file contains keyword-argu-
     ment pairs, one per line.  Lines starting with `#' and empty lines are
     interpreted as comments.  Arguments may optionally be enclosed in double
     quotes (") in order to represent arguments containing spaces.

     The possible keywords and their meanings are as follows (note that key-
     words are case-insensitive and arguments are case-sensitive):

     AcceptEnv
             Specifies what environment variables sent by the client will be
             copied into the session's environ(7).  See SendEnv in
             ssh_config(5) for how to configure the client.  Note that envi-
             ronment passing is only supported for protocol 2.  Variables are
             specified by name, which may contain the wildcard characters `*'
             and `?'.  Multiple environment variables may be separated by
             whitespace or spread across multiple AcceptEnv directives.  Be
             warned that some environment variables could be used to bypass
             restricted user environments.  For this reason, care should be
             taken in the use of this directive.  The default is not to accept
             any environment variables.

     AddressFamily
             Specifies which address family should be used by sshd(8).  Valid
             arguments are ``any'', ``inet'' (use IPv4 only), or ``inet6''
             (use IPv6 only).  The default is ``any''.

     AllowGroups
             This keyword can be followed by a list of group name patterns,
             separated by spaces.  If specified, login is allowed only for
             users whose primary group or supplementary group list matches one
             of the patterns.  Only group names are valid; a numerical group
             ID is not recognized.  By default, login is allowed for all
             groups.  The allow/deny directives are processed in the following
             order: DenyUsers, AllowUsers, DenyGroups, and finally
             AllowGroups.

             See PATTERNS in ssh_config(5) for more information on patterns.

     AllowTcpForwarding
             Specifies whether TCP forwarding is permitted.  The default is
             ``yes''.  Note that disabling TCP forwarding does not improve se-
             curity unless users are also denied shell access, as they can al-
             ways install their own forwarders.

     AllowUsers
             This keyword can be followed by a list of user name patterns,
             separated by spaces.  If specified, login is allowed only for us-
             er names that match one of the patterns.  Only user names are
             valid; a numerical user ID is not recognized.  By default, login
             is allowed for all users.  If the pattern takes the form US-
             ER@HOST then USER and HOST are separately checked, restricting
             logins to particular users from particular hosts.  The allow/deny
             directives are processed in the following order: DenyUsers,
             AllowUsers, DenyGroups, and finally AllowGroups.

             See PATTERNS in ssh_config(5) for more information on patterns.

     AuthorizedKeysFile
             Specifies the file that contains the public keys that can be used
             for user authentication.  AuthorizedKeysFile may contain tokens
             of the form %T which are substituted during connection setup.
             The following tokens are defined: %% is replaced by a literal
             '%', %h is replaced by the home directory of the user being au-
             thenticated, and %u is replaced by the username of that user.
             After expansion, AuthorizedKeysFile is taken to be an absolute
             path or one relative to the user's home directory.  The default
             is ``.ssh/authorized_keys''.

     Banner  The contents of the specified file are sent to the remote user
             before authentication is allowed.  If the argument is ``none''
             then no banner is displayed.  This option is only available for
             protocol version 2.  By default, no banner is displayed.

     ChallengeResponseAuthentication
             Specifies whether challenge-response authentication is allowed.
             All authentication styles from login.conf(5) are supported.  The
             default is ``yes''.

     Ciphers
             Specifies the ciphers allowed for protocol version 2.  Multiple
             ciphers must be comma-separated.  The supported ciphers are
             ``3des-cbc'', ``aes128-cbc'', ``aes192-cbc'', ``aes256-cbc'',
             ``aes128-ctr'', ``aes192-ctr'', ``aes256-ctr'', ``arcfour128'',
             ``arcfour256'', ``arcfour'', ``blowfish-cbc'', and
             ``cast128-cbc''.  The default is:

                aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,
                arcfour256,arcfour,aes192-cbc,aes256-cbc,aes128-ctr,
                aes192-ctr,aes256-ctr

     ClientAliveCountMax
             Sets the number of client alive messages (see below) which may be
             sent without sshd(8) receiving any messages back from the client.
             If this threshold is reached while client alive messages are be-
             ing sent, sshd will disconnect the client, terminating the ses-
             sion.  It is important to note that the use of client alive mes-
             sages is very different from TCPKeepAlive (below).  The client
             alive messages are sent through the encrypted channel and there-
             fore will not be spoofable.  The TCP keepalive option enabled by
             TCPKeepAlive is spoofable.  The client alive mechanism is valu-
             able when the client or server depend on knowing when a connec-
             tion has become inactive.

             The default value is 3.  If ClientAliveInterval (see below) is
             set to 15, and ClientAliveCountMax is left at the default, unre-
             sponsive SSH clients will be disconnected after approximately 45
             seconds.  This option applies to protocol version 2 only.

     ClientAliveInterval
             Sets a timeout interval in seconds after which if no data has
             been received from the client, sshd(8) will send a message
             through the encrypted channel to request a response from the
             client.  The default is 0, indicating that these messages will
             not be sent to the client.  This option applies to protocol ver-
             sion 2 only.

     Compression
             Specifies whether compression is allowed, or delayed until the
             user has authenticated successfully.  The argument must be
             ``yes'', ``delayed'', or ``no''.  The default is ``delayed''.

     DenyGroups
             This keyword can be followed by a list of group name patterns,
             separated by spaces.  Login is disallowed for users whose primary
             group or supplementary group list matches one of the patterns.
             Only group names are valid; a numerical group ID is not recog-
             nized.  By default, login is allowed for all groups.  The al-
             low/deny directives are processed in the following order:
             DenyUsers, AllowUsers, DenyGroups, and finally AllowGroups.

             See PATTERNS in ssh_config(5) for more information on patterns.

     DenyUsers
             This keyword can be followed by a list of user name patterns,
             separated by spaces.  Login is disallowed for user names that
             match one of the patterns.  Only user names are valid; a numeri-
             cal user ID is not recognized.  By default, login is allowed for
             all users.  If the pattern takes the form USER@HOST then USER and
             HOST are separately checked, restricting logins to particular
             users from particular hosts.  The allow/deny directives are pro-
             cessed in the following order: DenyUsers, AllowUsers, DenyGroups,
             and finally AllowGroups.

             See PATTERNS in ssh_config(5) for more information on patterns.

     ForceCommand
             Forces the execution of the command specified by ForceCommand,
             ignoring any command supplied by the client.  The command is in-
             voked by using the user's login shell with the -c option.  This
             applies to shell, command, or subsystem execution.  It is most
             useful inside a Match block.  The command originally supplied by
             the client is available in the SSH_ORIGINAL_COMMAND environment
             variable.

     GatewayPorts
             Specifies whether remote hosts are allowed to connect to ports
             forwarded for the client.  By default, sshd(8) binds remote port
             forwardings to the loopback address.  This prevents other remote
             hosts from connecting to forwarded ports.  GatewayPorts can be
             used to specify that sshd should allow remote port forwardings to
             bind to non-loopback addresses, thus allowing other hosts to con-
             nect.  The argument may be ``no'' to force remote port forward-
             ings to be available to the local host only, ``yes'' to force re-
             mote port forwardings to bind to the wildcard address, or
             ``clientspecified'' to allow the client to select the address to
             which the forwarding is bound.  The default is ``no''.

     GSSAPIAuthentication
             Specifies whether user authentication based on GSSAPI is allowed.
             The default is ``no''.  Note that this option applies to protocol
             version 2 only.

     GSSAPICleanupCredentials
             Specifies whether to automatically destroy the user's credentials
             cache on logout.  The default is ``yes''.  Note that this option
             applies to protocol version 2 only.

     HostbasedAuthentication
             Specifies whether rhosts or /etc/hosts.equiv authentication to-
             gether with successful public key client host authentication is
             allowed (host-based authentication).  This option is similar to
             RhostsRSAAuthentication and applies to protocol version 2 only.
             The default is ``no''.

     HostbasedUsesNameFromPacketOnly
             Specifies whether or not the server will attempt to perform a re-
             verse name lookup when matching the name in the ~/.shosts,
             ~/.rhosts, and /etc/hosts.equiv files during
             HostbasedAuthentication.  A setting of ``yes'' means that sshd(8)
             uses the name supplied by the client rather than attempting to
             resolve the name from the TCP connection itself.  The default is
             ``no''.

     HostKey
             Specifies a file containing a private host key used by SSH.  The
             default is /etc/ssh/ssh_host_key for protocol version 1, and
             /etc/ssh/ssh_host_rsa_key and /etc/ssh/ssh_host_dsa_key for pro-
             tocol version 2.  Note that sshd(8) will refuse to use a file if
             it is group/world-accessible.  It is possible to have multiple
             host key files.  ``rsa1'' keys are used for version 1 and ``dsa''
             or ``rsa'' are used for version 2 of the SSH protocol.

     IgnoreRhosts
             Specifies that .rhosts and .shosts files will not be used in
             RhostsRSAAuthentication or HostbasedAuthentication.

             /etc/hosts.equiv and /etc/shosts.equiv are still used.  The de-
             fault is ``yes''.

     IgnoreUserKnownHosts
             Specifies whether sshd(8) should ignore the user's
             ~/.ssh/known_hosts during RhostsRSAAuthentication or
             HostbasedAuthentication.  The default is ``no''.

     KerberosAuthentication
             Specifies whether the password provided by the user for
             PasswordAuthentication will be validated through the Kerberos
             KDC.  To use this option, the server needs a Kerberos servtab
             which allows the verification of the KDC's identity.  The default
             is ``no''.

     KerberosGetAFSToken
             If AFS is active and the user has a Kerberos 5 TGT, attempt to
             acquire an AFS token before accessing the user's home directory.
             The default is ``no''.

     KerberosOrLocalPasswd
             If password authentication through Kerberos fails then the pass-
             word will be validated via any additional local mechanism such as
             /etc/passwd.  The default is ``yes''.

     KerberosTicketCleanup
             Specifies whether to automatically destroy the user's ticket
             cache file on logout.  The default is ``yes''.

     KeyRegenerationInterval
             In protocol version 1, the ephemeral server key is automatically
             regenerated after this many seconds (if it has been used).  The
             purpose of regeneration is to prevent decrypting captured ses-
             sions by later breaking into the machine and stealing the keys.
             The key is never stored anywhere.  If the value is 0, the key is
             never regenerated.  The default is 3600 (seconds).

     ListenAddress
             Specifies the local addresses sshd(8) should listen on.  The fol-
             lowing forms may be used:

                   ListenAddress host|IPv4_addr|IPv6_addr
                   ListenAddress host|IPv4_addr:port
                   ListenAddress [host|IPv6_addr]:port

             If port is not specified, sshd will listen on the address and all
             prior Port options specified.  The default is to listen on all
             local addresses.  Multiple ListenAddress options are permitted.
             Additionally, any Port options must precede this option for non-
             port qualified addresses.

     LoginGraceTime
             The server disconnects after this time if the user has not suc-
             cessfully logged in.  If the value is 0, there is no time limit.
             The default is 120 seconds.

     LogLevel
             Gives the verbosity level that is used when logging messages from
             sshd(8).  The possible values are: QUIET, FATAL, ERROR, INFO,
             VERBOSE, DEBUG, DEBUG1, DEBUG2, and DEBUG3.  The default is INFO.
             DEBUG and DEBUG1 are equivalent.  DEBUG2 and DEBUG3 each specify
             higher levels of debugging output.  Logging with a DEBUG level
             violates the privacy of users and is not recommended.

     MACs    Specifies the available MAC (message authentication code) algo-
             rithms.  The MAC algorithm is used in protocol version 2 for data
             integrity protection.  Multiple algorithms must be comma-separat-
             ed.  The default is:

                   hmac-md5,hmac-sha1,umac-64@openssh.com,
                   hmac-ripemd160,hmac-sha1-96,hmac-md5-96

     Match   Introduces a conditional block.  If all of the criteria on the
             Match line are satisfied, the keywords on the following lines
             override those set in the global section of the config file, un-
             til either another Match line or the end of the file.  The argu-
             ments to Match are one or more criteria-pattern pairs.  The
             available criteria are User, Group, Host, and Address.  Only a
             subset of keywords may be used on the lines following a Match
             keyword.  Available keywords are AllowTcpForwarding, Banner,
             ForceCommand, GatewayPorts, GSSApiAuthentication,
             KbdInteractiveAuthentication, KerberosAuthentication,
             PasswordAuthentication, PermitOpen, RhostsRSAAuthentication,
             RSAAuthentication, X11DisplayOffset, X11Forwarding, and
             X11UseLocalHost.

     MaxAuthTries
             Specifies the maximum number of authentication attempts permitted
             per connection.  Once the number of failures reaches half this
             value, additional failures are logged.  The default is 6.

     MaxStartups
             Specifies the maximum number of concurrent unauthenticated con-
             nections to the SSH daemon.  Additional connections will be
             dropped until authentication succeeds or the LoginGraceTime ex-
             pires for a connection.  The default is 10.

             Alternatively, random early drop can be enabled by specifying the
             three colon separated values ``start:rate:full'' (e.g.
             "10:30:60").  sshd(8) will refuse connection attempts with a
             probability of ``rate/100'' (30%) if there are currently
             ``start'' (10) unauthenticated connections.  The probability in-
             creases linearly and all connection attempts are refused if the
             number of unauthenticated connections reaches ``full'' (60).

     PasswordAuthentication
             Specifies whether password authentication is allowed.  The de-
             fault is ``yes''.

     PermitEmptyPasswords
             When password authentication is allowed, it specifies whether the
             server allows login to accounts with empty password strings.  The
             default is ``no''.

     PermitOpen
             Specifies the destinations to which TCP port forwarding is per-
             mitted.  The forwarding specification must be one of the follow-
             ing forms:

                   PermitOpen host:port
                   PermitOpen IPv4_addr:port
                   PermitOpen [IPv6_addr]:port

             Multiple forwards may be specified by separating them with
             whitespace.  An argument of ``any'' can be used to remove all re-
             strictions and permit any forwarding requests.  By default all
             port forwarding requests are permitted.

     PermitRootLogin
             Specifies whether root can log in 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 authenti-
             cation 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 log in.

     PermitTunnel
             Specifies whether tun(4) device forwarding is allowed.  The argu-
             ment must be ``yes'', ``point-to-point'' (layer 3), ``ethernet''
             (layer 2), or ``no''.  Specifying ``yes'' permits both ``point-
             to-point'' and ``ethernet''.  The default is ``no''.

     PermitUserEnvironment
             Specifies whether ~/.ssh/environment and environment= options in
             ~/.ssh/authorized_keys are processed by sshd(8).  The default is
             ``no''.  Enabling environment processing may enable users to by-
             pass access restrictions in some configurations using mechanisms
             such as LD_PRELOAD.

     PidFile
             Specifies the file that contains the process ID of the SSH dae-
             mon.  The default is /var/run/sshd.pid.

     Port    Specifies the port number that sshd(8) listens on.  The default
             is 22.  Multiple options of this type are permitted.  See also
             ListenAddress.

     PrintLastLog
             Specifies whether sshd(8) should print the date and time of the
             last user login when a user logs in interactively.  The default
             is ``yes''.

     PrintMotd
             Specifies whether sshd(8) should print /etc/motd when a user logs
             in interactively.  (On some systems it is also printed by the
             shell, /etc/profile, or equivalent.)  The default is ``yes''.

     Protocol
             Specifies the protocol versions sshd(8) supports.  The possible
             values are `1' and `2'.  Multiple versions must be comma-separat-
             ed.  The default is ``2,1''.  Note that the order of the protocol
             list does not indicate preference, because the client selects
             among multiple protocol versions offered by the server.  Specify-
             ing ``2,1'' is identical to ``1,2''.

     PubkeyAuthentication
             Specifies whether public key authentication is allowed.  The de-
             fault is ``yes''.  Note that this option applies to protocol ver-
             sion 2 only.

     RhostsRSAAuthentication
             Specifies whether rhosts or /etc/hosts.equiv authentication to-
             gether with successful RSA host authentication is allowed.  The
             default is ``no''.  This option applies to protocol version 1 on-
             ly.

     RSAAuthentication
             Specifies whether pure RSA authentication is allowed.  The de-
             fault is ``yes''.  This option applies to protocol version 1 on-
             ly.

     ServerKeyBits
             Defines the number of bits in the ephemeral protocol version 1
             server key.  The minimum value is 512, and the default is 768.

     StrictModes
             Specifies whether sshd(8) 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 (with optional
             arguments) to execute upon subsystem request.  The command
             sftp-server(8) implements the ``sftp'' file transfer subsystem.
             By default no subsystems are defined.  Note that this option ap-
             plies to protocol version 2 only.

     SyslogFacility
             Gives the facility code that is used when logging messages from
             sshd(8).  The possible values are: DAEMON, USER, AUTH, LOCAL0,
             LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6, LOCAL7.  The de-
             fault is AUTH.

     TCPKeepAlive
             Specifies whether the system should send TCP keepalive messages
             to the other side.  If they are sent, death of the connection or
             crash of one of the machines will be properly noticed.  However,
             this means that connections will die if the route is down tem-
             porarily, and some people find it annoying.  On the other hand,
             if TCP keepalives are not sent, sessions may hang indefinitely on
             the server, leaving ``ghost'' users and consuming server re-
             sources.

             The default is ``yes'' (to send TCP keepalive messages), and the
             server will notice if the network goes down or the client host
             crashes.  This avoids infinitely hanging sessions.

             To disable TCP keepalive messages, the value should be set to
             ``no''.

     UseDNS  Specifies whether sshd(8) should look up the remote host name and
             check that the resolved host name for the remote IP address maps
             back to the very same IP address.  The default is ``yes''.

     UseLogin
             Specifies whether login(1) is used for interactive login ses-
             sions.  The default is ``no''.  Note that login(1) is never used
             for remote command execution.  Note also, that if this is en-
             abled, X11Forwarding will be disabled because login(1) does not
             know how to handle xauth(1) cookies.  If UsePrivilegeSeparation
             is specified, it will be disabled after authentication.

     UsePrivilegeSeparation
             Specifies whether sshd(8) separates privileges by creating an un-
             privileged child process to deal with incoming network traffic.
             After successful authentication, another process will be created
             that has the privilege of the authenticated user.  The goal of
             privilege separation is to prevent privilege escalation by con-
             taining any corruption within the unprivileged processes.  The
             default is ``yes''.

     X11DisplayOffset
             Specifies the first display number available for sshd(8)'s X11
             forwarding.  This prevents sshd from interfering with real X11
             servers.  The default is 10.

     X11Forwarding
             Specifies whether X11 forwarding is permitted.  The argument must
             be ``yes'' or ``no''.  The default is ``no''.

             When X11 forwarding is enabled, there may be additional exposure
             to the server and to client displays if the sshd(8) proxy display
             is configured to listen on the wildcard address (see
             X11UseLocalhost below), though this is not the default.  Addi-
             tionally, the authentication spoofing and authentication data
             verification and substitution occur on the client side.  The se-
             curity risk of using X11 forwarding is that the client's X11 dis-
             play server may be exposed to attack when the SSH client requests
             forwarding (see the warnings for ForwardX11 in ssh_config(5)).  A
             system administrator may have a stance in which they want to pro-
             tect clients that may expose themselves to attack by unwittingly
             requesting X11 forwarding, which can warrant a ``no'' setting.

             Note that disabling X11 forwarding does not prevent users from
             forwarding X11 traffic, as users can always install their own
             forwarders.  X11 forwarding is automatically disabled if UseLogin
             is enabled.

     X11UseLocalhost
             Specifies whether sshd(8) should bind the X11 forwarding server
             to the loopback address or to the wildcard address.  By default,
             sshd binds the forwarding server to the loopback address and sets
             the hostname part of the DISPLAY environment variable to
             ``localhost''.  This prevents remote hosts from connecting to the
             proxy display.  However, some older X11 clients may not function
             with this configuration.  X11UseLocalhost may be set to ``no'' to
             specify that the forwarding server should be bound to the wild-
             card address.  The argument must be ``yes'' or ``no''.  The de-
             fault is ``yes''.

     XAuthLocation
             Specifies the full pathname of the xauth(1) program.  The default
             is /usr/X11R6/bin/xauth.

TIME FORMATS
     sshd(8) command-line arguments and configuration file options that speci-
     fy time may be expressed using a sequence of the form: time[qualifier],
     where time is a positive integer value and qualifier is one of the fol-
     lowing:

           <none>  seconds
           s | S   seconds
           m | M   minutes
           h | H   hours
           d | D   days
           w | W   weeks

     Each member of the sequence is added together to calculate the total time
     value.

     Time format examples:

           600     600 seconds (10 minutes)
           10m     10 minutes
           1h30m   1 hour 30 minutes (90 minutes)

FILES
     /etc/ssh/sshd_config
             Contains configuration data for sshd(8).  This file should be
             writable by root only, but it is recommended (though not neces-
             sary) that it be world-readable.

SEE ALSO
     sshd(8)

AUTHORS
     OpenSSH is a derivative of the original and free ssh 1.2.12 release by
     Tatu Ylonen.  Aaron Campbell, Bob Beck, Markus Friedl, Niels Provos, Theo
     de Raadt and Dug Song removed many bugs, re-added newer features and cre-
     ated OpenSSH.  Markus Friedl contributed the support for SSH protocol
     versions 1.5 and 2.0.  Niels Provos and Markus Friedl contributed support
     for privilege separation.
 

Copyright © 1996-2009 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. Submit comments This document is an industrial compilation designed and created exclusively for educational use and is placed under the copyright of the Open Content License(OPL). Site uses AdSense so you need to be aware of Google privacy policy. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

Disclaimer:

Last modified: August 12, 2009