AIX SSH Best Practices

Disable insecure services

I always recommend to my customers that any unused services be disabled in /etc/inetd.conf, this includes telnet and ftp. Remember that even if there was a problem with network services, the administrator can still login as root on the system console via HMC. There is little threat of being locked out.

All insecure services can be disabled with one command:

cat /etc/inetd.conf | awk '/^[^#]/ {print "chsubserver -d -v",$1,"-p",$3}'

This will print a series of commands to disable all the (insecure) services that are still enabled. The commands can be copied and pasted into a script to run, or piped to sh -xe. Then be sure to refresh inetd with refresh -s inetd.

Alternatively consider not running inetd at all. A typical AIX system with only secure services will disable everything inetd runs! This can be disabled and the running daemon stopped with a single undocumented command:

chrctcp -S -d inetd

This stops the service and edits /etc/rc.tcpip to comment out the command to launch inetd during startup.

Methods for testing SSH changes

All of the key files for SSH are in /etc/ssh/. These are included in mksysb backups and include sensitive files like your host keys which identify the system to SSH clients. I recommend making copies of the configuration files while making changes, and then testing those changes with a second SSH daemon.

As a reference, the original sshd configuration file is stored in /usr/lpp/openssh.base/inst_root/etc/ssh/sshd_config.

So let's start with a making a copy of the sshd configuration to test with as root:

cp /etc/ssh/sshd_config /etc/ssh/sshd_config.test

Now we can edit /etc/ssh/sshd_config.test without interrupting users who are logged in. After editing the copied configuration file, we can test the changes at the command line:

/usr/sbin/sshd -t -f /etc/ssh/sshd_config.test

That will confirm that the configuration is valid and contains no major errors. With that working updated configuration, we can launch a second sshd on a separate port for testing. I chose 2022, but any open port will do:

/usr/sbin/sshd -D -d -f /etc/ssh/sshd_config.test -p 2022

Here the sshd will launch in the foreground and wait for a single connection. It will log to the screen details of the connection, and will not return to the command prompt until after the connection is closed.

This allows you to test changes made to the ssh configuration. Login with your preferred SSH client and make sure to use the different port. If you need to make multiple attempts to connect, you'll have to restart the second sshd after each one.

Once the changes are confirmed, we should make a backup of the running sshd configuration and copy in the new. Finally we can restart the system sshd with the new configuration:

cp /etc/ssh/sshd_config /etc/ssh/sshd_config.$(date +%Y%m%d_%H%M)

cp /etc/ssh/sshd_config.test /etc/ssh/sshd_config

stopsrc -s sshd ; sleep 5 ; startsrc -s sshd

It's important to note that this can be done without kicking users off. Typically this is a non-disruptive because each user spawns their own process, and we are restarting the main sshd which serves the port. The new configuration will apply to new logins.

There is little chance of being locked out. Keep you existing login open while you test. If there is a problem, login on the system console via the HMC.

Locking down the SSH configuration

The following are a list of options that are important to consider in your SSH configuration on AIX. These options are not disabled by default, and I recommend turning them off. They strongly apply to environments with applications requiring users to login via SSH.

AllowAgentForwarding no

This defaults to yes, and should be disabled by changing to

no. Agent forwarding is used to relay authentication from host to host when performing multiple hops with SSH. Users should not be doing this on an AIX system, though systems administrators might.

AllowTcpForwarding no

This defaults to yes, and should be disabled by changing to

no. TCP forwarding via SSH can allow any SSH user to relay arbitrary ports with the system and is commonly used to bypass firewalls!

PermitRootLogin maybe?

OpenSSH defaults this to no, while IBM sets it to yes. It may be

that root logins must be allowed, and you should carefully consider it in your environment. This can also be set to prohibit-password to allow root login via SSH key only. I recommend setting this to no, and then logging in with an administrator account [1] and becoming root from there.

The following options are enabled by default, and have value in remaining enabled.

PasswordAuthentication yes

Most end users will expect to login with a password. Clearly strong

password policies should be in place. This is the most common way to access the system. If this is disabled, only keys will be used for any login.

PermitEmptyPasswords no

No account should ever allow login without a password. SSH can

enforce that. Even for service accounts, it is insecure to ever allow passwordless authentication into any account.

GatewayPorts no

Do not allow forwarded ports to be opened on any public network

interface. This could be used to bypass firewalls and should be disabled.

X11Forwarding no

This should be disabled unless explicitly needed for X11

applications (ie: Oracle installers). Administrators could have this enabled, but generally it's best left disabled for everyone.

PermitUserEnvironment no

SSH can transmit environment variables to setup during login. This

should not be allowed as it can be a vector for mischief.

PermitTunnel no

Do not enable TUN style packet forwarding. Users should never need

this and it's important to have disabled to prevent bypassing firewalls.

Finally be aware that all Match directives in your SSH configuration must be at the END of the file!

Force SSH users into their application

SSH is a powerful suite of tools, including ssh for login, ssh for running remote commands, scp for copying files, and sftp for FTP style file transfer. If you serve a terminal application for users, you must take extra steps to disable all other features and force the users to login and only use the intended application!

Setting the login profile for the user is not enough. If a user can run a command via ssh, it will bypass their login profile. This is a potential backdoor to allow users a command line instead of being locked into a menu or application!

I recommend locking the users in the main SSH configuration file and in their profile. To do so, in the $HOME/.profile be sure to call exec $APPLICATION. For instance:

# User's .profile, replace this
export DB=Prod
/opt/application/path/appmenu

# With this
export DB=Prod
exec /opt/application/path/appmenu

The exec command causes the shell process to be replaced by the application process, instead of spawning a new process for the application. Spawning a new process could allow the user to potentially return to the shell when the application exits. Often there is additional scripting logic or trap statements to try and prevent returning to the shell prompt. Using exec when the application exits, the user will be immediately disconnected from the system.

Second in the sshd configuration we can specify that the user may only ever run the login shell. This forces them to run the .profile and enter the application. By forcing the command, this prevents remote command execution, scp, and sftp.

The following snippet for /etc/ssh/sshd_config uses the Match directive to match all non-root and non-admin users. The shell syntax is tricky because to make ksh spawn a login shell, you must start it in a process named -ksh. Perl is available on AIX and can accomplish this:

Match User *,!root,!admin
  ForceCommand /usr/bin/perl -e 'exec {"/usr/bin/ksh"} "-ksh"'

Now your users should be able to login to their application, but not exit to a shell prompt, run any remote commands, or transfer files.