I will be quick to acknowledge that the simplest approach might be to ensure that regular VIOS software maintenance is instated and to regularly perform VIO server updates of the entire system. But in many production environments it is not possible to do this without extensive planning and delay, so the alternative I would like to discuss is an update of just OpenSSH itself.
What follows here is an outline of a reasonably straightforward process for updating just the IBM OpenSSH software without having to update any other software. Please however note that the file set names and versions used do not apply to the portable version of OpenSSH.
1. Determine if you are running a vulnerable or weak level of OpenSSH (or the dependent OpenSSL file set) that requires an update.
There are various sources to identify SSH vulnerabilities, and I based my information on to http://www.openssh.org/security.html. This stipulates that Portable OpenSSH prior to version 5.8p2 is vulnerable to a local host key theft attack described in portable-keysign-rand-helper.adv advisory.
root:# lslpp -lc openssh.base.server
#Fileset:Level:PTF Id:State:Type:Description:EFIX Locked
/usr/lib/objrepos:openssh.base.server:18.104.22.16801::COMMITTED:I:Open Secure Shell Server:
/etc/objrepos:openssh.base.server:22.214.171.12401::COMMITTED:I:Open Secure Shell Server:
2. Decide on a new OpenSSH file set level.
3. Commit all existing file sets on the VIO server.
Commit Applied Software Updates (Remove Saved Files)
4. Copy the required OpenSSH and OpenSSL file sets to a temporary directory.
vio1:/# lslpp -l|egrep -e "openss[hl]"
At which point I was able to identify the following file-sets to update (language specific file sets may vary):
openssl.license (needed for licensing purposes)
openssl.base (includes server and client software)
To identify names of the actual BFF files that contain the updates, I simply had to run a grep command for each of the above in the .toc, for example:
vio1:/mnt/aix6/6100-07-05-1228# grep "openssh.base.server" .toc
At this point, I was able to identify and copy the file sets to a temporary location:
/mnt/aix6/6100-07-05-1228#mkdir /tmp/openssh && cp -p U846944.bff /tmp/openssh
and after repeating the copy for each of the above file sets I could execute
inutoc .from within the temporary directory.
smitty update_all, except for a few additional SSH related precautions.
The thing is, in the worst case scenario it is conceivable that the SSH update fails and that the SSH daemon may abort for an inexplicable reason. In such a case only existing SSH sessions will work, new connections can not be made unless the sshd daemon is active. So it is always a good idea to establish a separate SSH connection as a fall back (and to make sure that the TMOUT setting does not automatically log you out). This session will not be terminated if the sshd itself aborted during the update process.
Secondly, the safest approach would also be to back up the SSH keys, authorized_keys, known_hosts and all other SSH configuration files in ~root/.ssh in case anything gets overwritten, so run:
tar cvf /tmp/root-ssh.tar ~root/.ssh
smitty update_all (select the current directory as the input device)Now, all that is required is a restart of the SSH daemon. It is managed by the SRC, and can be restarted by the following commands:
PREVIEW only? YES OR NO
COMMIT software updates? NO
AUTOMATICALLY install requisite software? YES
ACCEPT new license agreements? YES
stopsrc -s sshd; sleep 3; startsrc -s sshd;
and then testing a new SSH connection to the system. The process associated with this new SSH connection should have a later start time than the actual sshd parent process that we just restarted. Do not forget to restart the SSH daemon, or else you might get a nasty surprise when you reboot the system (if something went wrong).