Getting the Error "No credential found for types [SSH Password,SSH Private Key] with credential tag [TEST

[krishna26]

Hello Everyone,

We are going to work on a ServiceNow integration where we are supposed to connect to a Linux Server & Execute a command. For this, i have created a vey basic, sample custom WF activity , connecting a particular hostname.

Upon Execution i am getting the below error

{
"output": null,
"errorMessages": "No credential found for types [SSH Password,SSH Private Key] with credential tag [TEST_SSH_AMAVAR_SNOW]\n",
"debugMessages": "{\"debug_info\":[{\"10.220.995.632\":{\"credentials_attempted\":[],\"connection_parameters\":{\"credential_types\":[\"SSH Password\",\"SSH Private Key\"],\"required_tag\":\"TEST_SSH_AMAVAR_SNOW\",\"target\":\"10.220.995.632\"}}}]}",
"eccSysId": "6e74860a1b1018142fdb8444cc4bcb4f",
"tags": null
}

Can anyone kindly inform what is the cause of happening of the issue ... 

[krishna26]

Yes Tim ... You are correct, It's somehow failing to match that Tag & not taking the credential. if i delete credential_tag parameter/or Even if I given some stupid tag name which is not there at all , Still it's showing the same error. 

If you had encountered this kind of issue earlier, Please help me on how to rectify this

[tim_broberg]

Ok, so, I have a credential alias:
Name: foobar
ID: foobar
Type: Credential

I have a credential:
Name: rba
User name: rba_user
Tag: foobar

In my ecc_queue record's payload I see:
<parameter name="credential_tag" value="foobar"/>

That works for me.

Does this align with what you're doing?
    - Tim.

[krishna26]

Yes In the very same way but i am not sure why it's not working.. 

In the payload Is the credential_id filled for you ? i am seeing an empty value for this case

<parameter name="credential_id" value=""/></parameters>

[tim_broberg]

credential_id contains the "credential affinity." This credential gets pulled to the head of the list, but the set of credentials tried is unaffected, assuming the server doesn't simply disconnect you for failing too many times.

You did mention that it worked if you deleted the tag from the ecc_queue. I would expect an affinity to be created when it worked in dscy_credentials_affinity table, which would then get fed into credential_id on subsequent attempts.

So, credential and ecc_queue have tag TEST_SSH_PVK.

The ecc_queue input clearly shows he didn't try any credentials at all.

You say it works without the credential tag / alias, which says that the mid does have credentials. (The lack of credential_id suggests that this did not actually happen for the IP of the one you mentioned, but perhaps that was a different IP.)

I can only think that the mid somehow has stale credential content. This should not happen, especially pre-Orlando, but I have seen rare occasions where the mid had network disruptions and failed to load the credentials. (I have been faithfully logging problems when this happens, and they have been getting fixed, but it would take some work to figure out what may have gotten fixed where.

Try restarting the mid?

Failing that, it may be time to sacrifice a chicken and/or file an incident with support.
    - Tim.

[krishna26 · Accepted solution]

Hi Tim,

Tried all the things but no luck hence raised a Hi-Ticket.

Response from Hi-Support team is if the instance is NewYork version then if we have outh2.0 credentials in the Credentials table then we will get the errors 

SEVERE *** ERROR *** An error occurred while decrypting credentials from instance
com.snc.automation_common.integration.exceptions.AutomationIOException: Unable to retrieve data from instance. This MID may not be validated.

This is fixed in Orland it seems.

Inactivated the outh 2.0 credentials we have & checked then it worked perfectly fine

Thanks for your suggestions & help