Authentication failed ?

[Mikael Rönnbäck]

We had a server breakdown this weekend and had to do some restore of OS and SIM, now everything seems to work properly, except for one of the scheduled tasks. It invokes a custom command, and whenever it tries to run it failes with this message :

EXCEPTION CLASS: com.hp.mx.exceptions.MxFailedAuthenticationException
EXCEPTION: Authentication failed.

I have tried deleting the task, command and query associated with this job, and set them up again as I did the last time, but I still get the same error every time. Does anyone have any idea what the fault is ?

[Rob Buxton]

Custom commands use SSH to login.
You may need to redo some of the OpenSSH set ups. You can manually check the passwd file to see if it looks as though anything is missing.

Check that the Custom command is running under the same user that is initiating the command. You'll see a couple of events generated as the Event Notification and then the custom command fire. I've seen issues if they're different.

[Mikael Rönnbäck]

Thanks, I did some searching in the forum and came up with the same thing. However I'm still not getting SSH to work properly, I have tried to follow the steps in the installation/troubleshooting manual but SSH does not want to cooperate with me... :)

I'm going to try completely uninstalling and reinstalling it, since it does not whatever I do allow me to login to SSH in the cmd prompt (one of the tests mentioned in the manual)

Thanks anyway!

[Mikael Rönnbäck]

Btw, forgot to mention, the service runs under a user account, the service starts up properly, the account is working properly, (but I'm not allowed login in SSH)

[Mikael Rönnbäck]

Hm, after some further looking into SSH commands I'm now allowed login, but the tasks will still not work, so I guess I have to attempt a reinstallation of OpenSSH.

[Rob Buxton]

Mikael,
Just to restate it, check the notification and custom task are both running under the same account. I got more success when these all ran under the account I installed HPSIM and OpenSSH in. I never did get to the bottom of why it seemed to fail if they were run under different accounts.

[Mikael Rönnbäck]

Yes, well they are, I'm using one account for running all services in Windows, and for auth'ing SSH, as well as that account being administrator on this particular server (but still a domain user account). In addition the account owns the task too.

I've now stepped through the documentation a few times, and have tried all I can find in it, from deleting the known_hosts in %profilepath%/.ssh, re-creating it viamxagentconfig, also deleting the entries in the HP SIM binary folder and attempting to have SIM re-create that (doesn't work so far, but the docs says something about that happening automatically so it could be triggered later), I've also deleted the passwd file and re-created it, and I have tried logging in to the server itself via SSH command-line using the above account, login works every time but SIM will not run the commands, only "auth failed".

Why oh why did HP ever switch to SSH... :-P
(or why of why does my backup not contain the files in the users profile... :-/ )

You wouldn't happen to know if upgrading to SIM 4.2 will possibly run some checks on this similar to the CIM7->SIM4.2 wizard did and automatically kind of "fix everything" and I'm wasting my time when an upgrade would do the trick ?

[Rob Buxton]

Mikael,
For the Usernames to run under I wasn't referring to the Services.
Within HPSIM, the scheduled task has an associated user to run under. I found that it was quite critical what account that ran under.
I made that the same as the account I did all the installs under.
I also logged into HPSIM using that account and created the custom task using that user.
SSH caused me quite a bit of grief. I probably did it the hard way as I removed and reinstalled OpenSSH.

[Mikael Rönnbäck]

Yes, that was one of the things I meant, i.e. that the owner of the scheduled task is the account which is used to install and run the entire server/service/application. Call it the central user for lack of a better word on my part. Thanks anyway.

[Tyronne Milton]

Check in /etc/opt/ssh/sshd_config that Permitrootlogin=yes
or the line is commented.

I have discovered this solution the hard way, as I was trying to make it easier to administer the system with SIM but make the system more secure with SSH via forcing an su to root.

[Mikael Rönnbäck]

Thanks, I will take a look just to check what it says, however we have already decided it more "easy" to scratch the entire installation and reinstall, even if it is a bit more initial work at least we will then get everything working, as we do not really need the historical data, we just want all functions to work reliably :)