Smart Console open shell - saving fingerprint failed! How correct it? - solved

[DH]

Version R81.10 JHF take 79
Console R81.10 build 410

I have a change fingerprint of a reinstalled gateway.

SSH from SmartManagement Server CLI to gateway worked.

SSH by SmartConsole =>Open Shell shows a potential security break (that's known because of the reinstallation),
but the option 'Ok'/'Yes'(?) to save the fingerprint do failed with message. - I think 'No' should be 'Cancel'...😉

"saving fingerprint failed for <IP>.
fingerprint won't be saved. "

after that message the connection to the gateway is still possible.

Other new/unknown fingerprints will be saved that way...

My questions:
Where will this fingerprints be saved?
How can they safely be edit?

[the_rock]

Just to make sure I understand this, the screenshot you attached is what you see when trying to open gateway shell from the object in dashboard?

[DH]

Yes in

Smart Console=>Gateways and Servers=>Gateway Object=>Action=>Open Shell..after input the login Credentials. - The gateway was before reinstalled and the trust restablished, so it is correct, that the fingerprint was changed, but I'm unable to save the new fingerprint inside the GUI.

[PhoneBoy]

You might try accessing the host from the management server via SSH and save the fingerprint there…using the admin user.

[the_rock]

I was going to suggest same thing @PhoneBoy mentioned...so say from your mgmt ssh session expert mode, you can type ssh admin@10.10.10.50 (or whatever fw IP is), accept whetever is prompted on the screen and once connected, close the session and then try same method that was failing originally.

Andy

[DH]

I tried that already before...SSH to Mgmt => ssh from Mgmt to gateway => store the key (it was stored then unter ~/.ssh/known_hosts as usual under linux.) this worked inside the expert mode.
But this did not resolve the problem inside the SmartConsole GUI.

So the question is still were did the console store the fingerprints?

[PhoneBoy]

The only other place I can think of is the same place in the root user (i.e. under /root).
Otherwise, I suggest a TAC case.

[the_rock]

And it did prompt you to accept the "key" when you did this?

[DH · Accepted solution]

I found the major part of the solution by myself.

It seems a other AdminUser got this message before, accept (yes) it, but  he didn't publish it.

I found a "edited ssh settings entry" in the changes of his session! - it was the only change in this session, so I discard that session and now I didn't got an error message anymore, after I accept the new key!
The root problem is solved and it seems the fingerprint are stored inside the database.

@cp : Why did the GUI not clear inform, that this setting is locked by a other user - that should be the correct message!