03-06-2013 02:00 PM
There doesn't appear to be, no.
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/emp
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.
03-06-2013 03:33 PM
Hey, thanks for the quick response, and great answer .I suspected as much, as I already tried similar steps as you've suggested, and scoured the documentation without much success.
Too bad, I really would have liked to have used the ssh key authentication for some simple automation and reporting.
03-06-2013 04:04 PM
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
May help with your automation purposes.
03-07-2013 11:40 AM
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.
03-07-2013 02:09 PM - edited 03-07-2013 02:09 PM
My aim was for some quick scriptlets to be used sporadically on a schedule. I was hoping to avoid having to develop an "application" using an API.
I'll look into this route if I need anything more permanent.