The opswsshd daemon appears to look for the authorized_keys in /var/opt/opsware/sshd/empty ( in OGFS ). If you set the AuthorizedKeysFile in /etc/opt/opsware/sshd/sshd_config ( outside of OGFS ), it just appends to that. You have to change the settings in the /etc/opt/opsware/sshd/sshd_config file to accept Pubkey auth as well.
You can set the AuthorizedKeysFile to %u/.ssh/authorized_keys in the config and restart opswsshd, then put the proper directories in the the OGFS ( you'd do this by manipulating /var/opt/opsware/ogfs/mnt/var/opt/opsware/sshd/empty outside of OGFS ).
If you restart opswsshd at this point, that directory gets cleaned out, so anytime you restarted a core, you'd have to put all the keys back. But, that doesn't matter because even after you do that, the opswsshd fails ( after it gets past the pubkey auth ), because it wants a username for the PAM module and it's not getting it:
Mar 6 21:53:13 dc1SAapp010 opswsshd: debug1: PAM: establishing credentials Mar 6 21:53:13 dc1SAapp010 opswsshd: debug3: PAM: opening session Mar 6 21:53:13 dc1SAapp010 opswsshd: opsware_pam: ERROR username missing Mar 6 21:53:13 dc1SAapp010 opswsshd: error: PAM: pam_open_session(): Permission denied
So it ends up just closing your connection.
If you disable PAM, it'll accept your pubkey, then fall back to asking for an Opsware username and password, and then just hangs. You could probably manipulate the OGFS pam to make it accept the pubkeys somehow, but in the pam file in OGFS, it explicity states:
# # WARNING! Please do not add other PAM modules to this file. # It is not designed to work with other modules.
So my guess is that HP has gone out of their way to disable the use of authorized_keys and don't want that sort of functionality enabled.
Yeah, in order to do anything automated that starts outside of global shell but uses global shell, we have expect scripts that fire off to do the actual login process.
Note that if you're running something on the core, instead of using the ssh option, you can use the /opt/opsware/ogfs/bin/ogsh utility to login to the OGFS. It accepts a username and password on the commandline, as well as a script to run.
So you can do something like this:
/opt/opsware/ogfs/bin/ogsh -u myuser -p mypass ls -l /tmp
You can also make your OGFS Scripts into an APX and run it from the outside via pytwist, java or webservice APIs. But of course you still have to authenticate - at least you have a clean api to pass the password instead of an except script.
I would like to see kerberos integrated authentication in the whole SA product suite.
For some historical context, disallowing key-based authentication into the global shell was initially to ensure permissions were fully managed by SA, and that only a user who "should" be logging in, is.
Adding password-less access to the OGSH, like adding cron support, has been repeatedly requested going back to at least early 07 - likely longer.