Server Automation Practitioners Forum
Showing results for 
Search instead for 
Do you mean 

SSH keys with Global Shell

Go to Solution

SSH keys with Global Shell

Is there any way for global shell to accept SSH keys for authentication instead of a password?

Respected Contributor

Re: SSH keys with Global Shell

Short answer:


There doesn't appear to be, no.


Long answer:


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[29132]: debug1: PAM: establishing credentials
Mar 6 21:53:13 dc1SAapp010 opswsshd[29132]: debug3: PAM: opening session
Mar 6 21:53:13 dc1SAapp010 opswsshd[29132]: opsware_pam: ERROR username missing
Mar 6 21:53:13 dc1SAapp010 opswsshd[29132]: 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.

Re: SSH keys with Global Shell

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. 



Respected Contributor

Re: SSH keys with Global Shell

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.



Re: SSH keys with Global Shell

Hey, another good idea. Thanks!


I'll give that a shot when I have a little time.

Senior Member

Re: SSH keys with Global Shell

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.




Re: SSH keys with Global Shell

[ Edited ]

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.



Occasional Advisor

Re: SSH keys with Global Shell

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.