HP-UX Secure Shell: Part 5 - The host configuration files

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 next week.

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.

[email protected]'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*

Next week we will look at the ssh configuration on the client side.

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