HP-UX Secure Shell: Part 5 - The host configuration files
A look at the SSH host configuration files.
There are several configuration files used by HP-SSH. Some are used by the daemon and others by the client. We...
Continue Reading This Article
Enjoy this article as well as all of our content, including E-Guides, news, tips and more.
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.
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*
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
Start the conversation
0 comments