Prime Infrastructure 2.0 "Wrong CLI Credentials" error with known good credentials

[Larry Smith]

In the device work center sometimes devices show up with "wrong CLI credentials". Even when I change to known good SSH credentials and click the update & sync button the error does not go away.

Has anyone else had this issue? Does anyone know a workaround?

It seems absurd that you would not be able to edit the SSH credentials of devices.

[AFROJ AHMAD]

Hi Larry,

the above isue could be because of the following :

some issue with the telnet/SSH login to the device. PI does perform check for CLI login
when you add/edit a device. Go to Lifecycle view and check the credential settings for 
the device under Operate > Device Work Center. Sometimes it could be that the wrong 
protocol is selectedtelnet vs ssh), sometimes it can be due tothe wrong credentials 
entered, and sometimes it could be that the timeout value needs to be set/increased.

If above is ok ,try to increase the timeout for telnet\ssh >> Operate > Device Work Center > Edit

Thanks-

Afroz

[Do rate the useful post]

[skelley5000]

I set up Discovery with all of the different sites, input the correct user name and pw for telnet for all of the devices. Majority of the devices work fine but under device work center I see a lot of device with the wrong CLI credential error. When I edit the device the username and password are not listed...why does this happen?

[michael.taylor]

Hi Guys,

I have had the same problem.  It transpired that the credentials were indeed correct; however Prime was trying to log into a Cisco 6509 running CatOS and did not recognise the fact.  Even changing the prompt to "hostname"> made no difference.

We checked the Prime supported device list and could not find any mention of CatOS devices; therefore, we contented ourselves with managing the MSFC.

Cheers

Michael

[tedmonson-hhsc]

I have the same issue, with 3 of my 5508 controllers; after reading afrahmad post I tried to oppisite since I use Lifecycle view as my default and have this issue.  I changed the view to Classic and went to Configure>Controllers selected the first 5508 that failed, then chose Update Credentials from the drop down and right away saw that there were no credentials in this view, updated the credentials, went back to Configure>Controllers selected the same 5508 and chose Refresh Config from Controller, process completed with no errors, I then switched back to Lifecycle view to verify the status and all 3 of my  5508 controllers are now up to date..   Looks like a bug to me ..

[Michael Kiessling]

Hi all,

the solution described by tedmonson-hhsc worked for me! Just changed view to Classic, entered the user credentials and synchronized the config from the WLCs.

In Lifecycle View all Controllers are now shown as fully managed.

Regads,
Michael

[drakow]

My issue is with switches. PI is sending the username "enable" for telnet/ssh credentials instead of the credentials I specify. I'm only having problems with older 2950 series switches which are on the hardware compatibility list with a supported software version. The funny thing is one 2950T works and the other does not (same version and config). Updating the credentials in classic view did not work. I deleted and re-added the devices that were failing in classic view and they are now working so try this if updating credentials does not work.

[Derek Clothier]

If you have a '#' character in the login or motd banner of the device, then you are most likely hitting bug CSCun25871 - "PI interprets last # sign in banner as a prompt". CSCun25871 is planned to be  fixed in PI 2.2 .

There is a timing factor involved, so it doesn’t affect all devices configured with a banner that includes the ‘#’ character.

Workaround is to remove all '#' characters from login and motd banners .

Hope this helps

[jcockburn]

Hi All,

Ran into the same issue regarding managing switches from PI 2.0...routers are fine, only switches gives this error in my case.

I ended up changing all the '#'s in my banner to '*'s and that did the trick. Nice bug...

Ciao

JC

[sgtmajvimy]

ok, tried all that was said here. Nothing worked ... I do have banners, but no # sign ... removed them anyways ... then thinking about the banners might be causing issues for what PI expects ... (i do have my prompts changed to mask the platform) ... so i defaulted back to regular prompts ... WORKED !!!!

So here is what works for me ... no banners, no custom prompts AND device added through the 'classic theme'.

I presume the expectation is that the device begins with minimal config ... the rest is pushed through the config templates deployment. But have the developers thought of existing devices ? is it IOS version related (target device) or simply a bug.

BTW, PI v2.1

Edit --- needing to clarify, for some models (namely UC520) ... removed banner, custom prompts and i could add it comfortably through the Lifecycle interface.

Others (3550), could be inserted easily with banners and custom prompts ... rather inconsistent, though at least , i have working recipes.

Thanks for the help all :)

[jcockburn]

Hi All,

Just for info,

Seems like PI2.2 is OK...

Of course there are other bugs ;-)

Ciao

JC

[Marvin Rhoads]

I had the same issue with a 5520 WLC. We are running PI 3.1 and AireOS 8.1.131. The credential set was confirmed correct for both ssh and SNMPv3 user.

I had to go into the credential set for that device only and remove the enable credential. Once I did that, credentials verified and synchronization worked fine.

[ajc]

I am running prime lms 3.1 (the latest version) for wired devices and experiencing the same issue. So I found the following:

For some reason Prime CHECKS both options during the discovery process based on the credentials you configured for that specific device. SO, if you DO NOT have transport input all (old ios) or transport input telnet ssh in the line vty of the switch then you will get that error.

2nd, you MUST configure the credentials for TELNET first so they are added by prime automatically to the SSH credentials option. Then run a Credential Verification on the TELNET option to validate it and after that you can run the SYNC with no issues and the LAST INVENTORY COLLECTION STATUS for that device would be on prime = COMPLETED.

[jose cortes]

Hi everyone,

I'm facing the same issue you describe, when I see the logs of my Switches (even a 4500) I can see this:

006007: Dec 19 2014 09:02:48.934 EST: %SSH-5-SSH2_SESSION: SSH2 Session request from 172.17.4.247 (tty = 0) using crypto cipher 'aes128-cbc', hmac 'hmac-md5' Succeeded

006008: Dec 19 2014 09:02:51.963 EST: %SEC_LOGIN-4-LOGIN_FAILED: Login failed [user: sona-prime] [Source: 172.17.4.247] [localport: 22] [Reason: Login Authentication Failed] at 09:02:51 EST Fri Dec 19 2014

I user the very same username and password for the routers and those have been added without a problem, I tried with simpler credentials and telnet but is the same every time. When I use the discovery option the device is found but no information is retrieved from it because of "Partial Connection Failure" and when I try to add the device manually it reports "Wrong CLI Credentials"

Any information about this??

Best Regards

[1977bjorn]

Got the same problem. I believe it´s a bug but I have not found any cisco resources verifying that. We are running ssh on all end devices. When I configure discovery and run the job - the credentials are defaulting to telnet with no password. If I click an individual device - the ssh credentials are not set - if I set them individually it works, but not with the discovery template - which is kind of bad :-)

I found a bug in LMS that was kind of the same, that´s as close as I got.

//Bjorn