HP-UX Secure Shell: Part 3: The configuration files                       

by Chris Wong

 

 

There are several configuration files used by HP-SSH.  Some are used by the daemon and others by the client.  We will first look at the host based configuration file followed by the client configuration file.

 

 

The sshd_config file

 

/etc/opt/ssh: (or) /opt/ssh/etc:

-r--r--r--   1 bin        bin           2805 Sep  9 20:32 sshd_config

 

The sshd_config file is the one read and used by the SSH daemon.  The "#" sign is a comment in this file. A " grep -v "# " sshd_config  " command will produce the following output:

 

#Port 22

Protocol 2

#ListenAddress 0.0.0.0

#ListenAddress ::

#HostKey /opt/ssh/etc/ssh_host_key

#HostKey /opt/ssh/etc/ssh_host_rsa_key

#HostKey /opt/ssh/etc/ssh_host_dsa_key

#KeyRegenerationInterval 3600

#ServerKeyBits 768

#obsoletes QuietMode and FascistLogging

#SyslogFacility AUTH

#LogLevel INFO

#LoginGraceTime 600

#PermitRootLogin yes

#StrictModes yes

#RSAAuthentication yes

#PubkeyAuthentication yes

#AuthorizedKeysFile     .ssh/authorized_keys

#RhostsAuthentication no

#IgnoreRhosts yes

#RhostsRSAAuthentication no

#HostbasedAuthentication no

#IgnoreUserKnownHosts no

#PasswordAuthentication yes

#PermitEmptyPasswords no

#ChallengeResponseAuthentication yes

#KerberosAuthentication yes

#KerberosOrLocalPasswd yes

#KerberosTicketCleanup yes

#AFSTokenPassing yes

#KerberosTgtPassing no

#PAMAuthenticationViaKbdInt yes

#X11Forwarding no

#X11DisplayOffset 10

#X11UseLocalhost yes

#PrintMotd yes

#PrintLastLog yes

#KeepAlive yes

#UseLogin no

#MaxStartups 10

#Banner /some/path

#VerifyReverseMapping no

Subsystem       sftp    /opt/ssh/libexec/sftp-server

 

From initially looking at this file, you might assume that the only settings are those that do not start with the "#" symbol.  However, the lines that do start with a "#" symbol represent the default setting for that parameter. These settings were made during compile time.  For example, the default setting for PrintLastLog is:  #PrintLastLog yes . This settings displays the last login time for the user:

 

$ ssh ctg701

Enter passphrase for key '/home/vking/.ssh/id_dsa':

Last login: Wed Sep 11 20:30:01 2002 from client

 

If we change the sshd_config file to:

 

#PrintLastLog yes

PrintLastLog no

 

and force the SSH daemon to re-read its configuration file:

 

ctg701: kill -HUP `cat /var/run/sshd.pid`

 

The next time the user runs ssh to this host, they are no longer displayed this information:

 

$ ssh ctg701

Enter passphrase for key '/home/vking/.ssh/id_dsa':

 

Should you keep the commented keyword?  I would recommend keeping it. After all, if you remove your entry, the default value will be used.  You can also make configuration changes to the SSH daemon when you start the daemon at the command line:

 

ctg701: /opt/ssh/sbin/sshd -o "PrintLastLog no"

 

Optionally, these could also be placed in the startup configuration file for secsh:

 

/etc/rc.config.d/sshd:

 

SSHD_START=1

SSHD_ARGS="-o PrintLastLog=no"

 

root 18629  1  0 0:00 /opt/ssh/sbin/sshd -o PrintLastLog=no

 

However, if you use command line arguments (either directly from the command line or via the startup script),  change the configuration file, and force the SSH daemon to re-read the configuration file, the command line options will still be used, not the newer option in the configuration file.  To change a configuration option that is set at the command line, the daemon must be stopped and restarted. Note: As of Sept. 2002, HP-SSH currently will kill the SSH daemon if you force it to re-read the configuration file if the daemon was started with command line options. (Received SIGHUP; restarting. command-line line 0: missing yes/no argument.)

 

 

The SSH daemon is also using options that were specified at compile time.  A complete list of options available to use with the SSH daemon can be found by using:

 

grep "\", s" /opt/ssh/src/ssh/servconf.c | cut -f2 -d, | cut -f2 -d" " | cut -c2-60 | sort

 

The options that are underlined are not listed in the sshd_config file:

 

AFSTokenPassing

AllowGroups

AllowTcpForwarding

AllowUsers

AuthorizedKeysFile

AuthorizedKeysFile2

Banner

ChallengeResponseAuthentication

Ciphers

ClientAliveCountMax

ClientAliveInterval

DenyGroups

DenyUsers

Deprecated

EmptyPasswd

GatewayPorts

GssAuthentication

GssCleanupCreds

GssKeyEx

GssUseSessionCredCache

HostKeyFile

HostbasedAuthentication

HostbasedUsesNameFromPacketOnly

IgnoreRhosts

IgnoreUserKnownHosts

KbdInteractiveAuthentication

KeepAlives

KerberosAuthentication

KerberosOrLocalPasswd

KerberosTgtPassing

KerberosTicketCleanup

KeyRegenerationTime

ListenAddress

LogFacility

LogLevel

LoginGraceTime

Macs

MaxStartups

PAMAuthenticationViaKbdInt

PasswordAuthentication

PermitRootLogin

PidFile

Port

PrintLastLog

PrintMotd

Protocol

PubkeyAuthentication

RSAAuthentication

RhostsAuthentication

RhostsRSAAuthentication

ServerKeyBits

StrictModes

Subsystem

UseLogin

VerifyReverseMapping

X11DisplayOffset

X11Forwarding

X11UseLocalhost

XAuthLocation

 

 

Looking at this list, you can determine additional configuration settings to be used in your SSH environment.  We will add the "DenyUsers" option to see how that works and further to see how rules work in the configuration file. When the following line is added and sshd is forced to re-read its configuration file:

 

DenyUsers vking

 

The user vking will no longer be prompted to enter their passphrase and the following message is displayed in syslog on the SSH server:

 

Sep 12  ctg701 sshd[6909]: User vking not allowed because listed in DenyUsers

 

However, the user will be prompted for their UNIX login password.

 

vking@ctg701's password:

Permission denied, please try again.

 

Even when the user enters their correct UNIX login password, they are denied access and the following message is placed in syslog:

 

Sep 12 ctg701 sshd[6909]: Failed password for illegal user vking from 192.168.105.18 port 61400 ssh2

 

What happens if we modify the sshd_config file to include:

 

AllowUsers vking

DenyUsers vking

 

This user will be denied access regardless of the order of these two options.  If a user is restricted by any option, that user will not be granted access.  Using the above configuration what happens when a user named jrice attempts to use ssh?  That user is also denied access because all users (except for vking) are restricted access since they are not listed in the AllowUsers option.  Let's try a different configuration using a wildcard character:

 

AllowUsers j*

DenyUsers vking

 

This configuration results in the following behaviour:

 

jrice:    Allowed access (since part of j* and not vking)

vking:  Denied access because listed in DenyUsers and not part of AllowUsers

jwong: Allowed access (since part of j* and not vking)

fsmith: Denied access because not part of j*

 

The ssh_config File

 

/etc/opt/ssh: (or) /opt/ssh/etc:

-r--r--r--   1 bin        bin           1659 Sep  9 20:32 ssh_config

 

 

The ssh_config file is the default configuration file for the SSH client. The entries in this file are only used if they are not specified in either the user's own configuration file ($HOME/.ssh/config) or at the command line.  The "#" sign is a comment in this file. The following are the default values provided with HP-SSH:

 

# Host *

#   ForwardAgent no

#   ForwardX11 no

#   RhostsAuthentication yes

#   RhostsRSAAuthentication yes

#   RSAAuthentication yes

#   PasswordAuthentication yes

#   FallBackToRsh no

#   UseRsh no

#   BatchMode no

#   CheckHostIP yes

#   StrictHostKeyChecking ask

#   IdentityFile ~/.ssh/identity

#   IdentityFile ~/.ssh/id_rsa

#   IdentityFile ~/.ssh/id_dsa

#   Port 22

#   Cipher 3des

#   Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes2

56-cbc

#   EscapeChar ~

 

The format of this file is the same as the sshd_config file.  The above listing shows the default values and are actually just comments. These default values were defined as part of the compilation of the program. For example to enable batch mode, the line would be changed to:

 

    BatchMode yes

 

The very first line of the file reads "# Host *" and is indented to the left. This is used to create separate sections for different hosts. In this example, all clients connecting to all (*) hosts will use the following configuration options. However, if this was changed to "Host *.cerius.com" all the following options would apply only to clients connecting to a host that fell within that domain. Multiple sections can be created.  What if a host the client was connecting to fell into two sections?  Both sections would be applied but only the first keyword would be used.  For example:

 

  Host *

    ForwardAgent no

    ForwardX11 no

    RhostsAuthentication yes

  Host *.cerius.com

    RhostsAuthentication no

 

would cause a client attempting to connect to ctg700.cerius.com to be able to use RhostsAuthentication.   Alternatively:

 

 Host *.cerius.com

    RhostsAuthentication no

 Host *

    ForwardAgent no

    ForwardX11 no

    RhostsAuthentication yes

 

would disable a client attempting to connect to ctg700.cerius.com to use RhostsAuthentication.

 

The following command will display all the keywords available with the HP SSH client:

 

grep "\", o" /opt/ssh/src/ssh/readconf.c | cut -f2 -d, | cut -f2 -d" " | sort

 

Those underlined are not found in the default ssh.config file:

 

AFSTokenPassing

BatchMode

BindAddress

ChallengeResponseAuthentication

CheckHostIP

Cipher

Ciphers

ClearAllForwardings

Compression

CompressionLevel

ConnectionAttempts

DynamicForward

EscapeChar

FallBackToRsh

ForwardAgent

ForwardX11

GatewayPorts

GlobalKnownHostsFile

GlobalKnownHostsFile2

GssAuthentication

GssDelegateCreds

GssGlobusDelegateLimitedCreds

Host

HostKeyAlgorithms

HostKeyAlias

HostName

HostbasedAuthentication

IdentityFile

KbdInteractiveAuthentication

KbdInteractiveDevices

KeepAlives

KerberosAuthentication

KerberosTgtPassing

LocalForward

LogLevel

Macs

NoHostAuthenticationForLocalhost

NumberOfPasswordPrompts

PasswordAuthentication

Port

PreferredAuthentications

Protocol

ProxyCommand

PubkeyAuthentication

RSAAuthentication

RemoteForward

RhostsAuthentication

RhostsRSAAuthentication

SmartcardDevice

StrictHostKeyChecking

UseCtg701ilegedPort

UseRsh

User

UserKnownHostsFile

UserKnownHostsFile2

XAuthLocation

 

Let's try using the LogLevel keyword to change the amount of information displayed to the user:

 

On the client host the /etc/opt/ssh/ssh_config file is changed to include:

 

LogLevel debug3

 

When the user initiates the SSH session, they are greeted by screens and screens of debugging information (for debug level 1, 2, and 3):

 

$ ssh ctg701     

debug3: Seeing PRNG from /opt/ssh/libexec/ssh-rand-helper

debug1: Rhosts Authentication disabled, originating port will not be trusted.

debug1: restore_uid

<rest removed>

 

 All users will receive this since this is in the system default file (ssh_config). But, what if the user creates an entry in their own configuration file for the same keyword but using a different entry?  The user vking adds the following to their $HOME/.ssh/config file:

 

LogLevel info

 

Now when this user initiates the SSH session, only the regular feedback is displayed to the user. If a different user, jrice, was to initiate a session, they would receive the full debugging information if they did not have their own setting in their own configuration file.  Entries in the user's configuration file take precedent over entries in the ssh_config file.

 

What happens if at the command line the user enters a different value for the keyword?

 

$ ssh -o "LogLevel=debug1" ctg701

debug1: Reading configuration data /home/vking/.ssh/config

debug1: Reading configuration data /opt/ssh/etc/ssh_config

debug1: Rhosts Authentication disabled, originating port will not be trusted.

 

In this example, the user will only see debug information for level 1 (not 2 and 3).

 

In summary, the SSH client uses the following order to determine the value to use with a keyword. The first obtained value is used:

 

Command line

User's configuration file ($HOME/.ssh/config)

System-wide client configuration file (/etc/opt/ssh/ssh_config)

 

The next article will look at using an SSH-enabled terminal emulator from the client PC in an HP-UX environment.

 

Chris Wong is a technical consultant and trainer for Cerius Technology Group, Inc. in Bellevue, WA. She is the author of the HP Press book HP-UX 11i Security.  http://newfdawg.com