Subconnections do not inherit Parent Credentials when parent is set to Credential Repository
Remote Desktop Manager Enterprise Edition Version 2020.1.13.0
.NETRuntime: v4.0.30319
.NET Version: Version 4.7.2 or better.
Data Source: Local SQL Lite
I have created a session of connection type host, specified the host IP and name.
I have created a subconnection under it of type SSHShell, which has credentials set to inherit from parent, and uses $PARENT_HOST$ for the host IP.
I have the following problem.
When the parent credentials are set to Credential Repository, and I attempt to connect with the SSHShell subconnection; I am prompted for both Username and Password.
When the parent credentials are set to default and manually entered, and I attempt to connect with the SSHShell subconnection; I login seamlessly.
If I change the sub connection to use Credential Repository, it also prompts me for both Username and password when I connect.
I can't seem to find any one else encountering this error so I assume its a bug.
Hello,
When the parent session is set with Credential Repository, have you tried to set the SSH subconnection Credentials to Inherited - Parent like the following screen shot?
Best regards,
Érica Poirier
Yes, which i outlined in the original post. Have you had your coffee yet? ;-)
And now that I'm reviewing it again myself, I realize the outline actually describes two seemingly distinct problems.
It could be it's the same problem. Whether it's set to inherit it or not, the subconnection only works if the credentials are manually specified under username and password fields on either the parent or the subconnection itself.
Hello,
Sorry about that (facepalm)! You are right that I didn't have my coffee this morning :P
I cannot reproduce that behaviour within RDM version 2020.1.13 or 2020.1.17.
Do you have any special character for the username?
Best regards,
Érica Poirier
Hello,
Could you please send me a screen capture of the error you have in your SSH entry?
Best regards,
Érica Poirier
Its not producing an error, it works. I just have to enter the credentials manually because it won't use defined credentials from a Credential Repository.
The user name in the credential repository contains a hyphen, but other than that it's lower case letters.
And it's worth mentioning that the repository creds work fine so long as the session is not a subconnection.
Hello,
Thank you for the information.
Is your SSH subconnection configured with any specific configuration like a Private key, a passphrase, etc?
Best regards,
Érica Poirier
I've copied the parent session to clip board and redacted out all IDs/IPs/Password, etc info. Should provide you the necessary info about settings.
See attached.
The FTP session has the creds embedded while the SSH session inherits.
redacted session data.txt
Hello,
Thank you for the file.
I cannot reproduce that behaviour with your entries. The only thing I could see is that your SSH entry has been created from a Template.
Could you please try to create a SSH subconnection entry without any template and try to connect using the Credential Repository on the parent or the subconnection?
Best regards,
Érica Poirier
Hello,
Could you please send us the logs of the SSH subconnection?
I will send you a link in a private message to upload your logs on our safe cloud space.
To enable the logs of your SSH entry, please enable it in the Advanced tab of the SSH entry properties.
Best regards,
Érica Poirier
Actually, there's nothing wrong with the session or subconnections. All of my credential repository creds appear to be corrupted somehow. I tested that they worked, but I've relaunched the software since then. And now it doesn't work for any session. I'm guessing the credentials were cached somehow for the initial tests, which got cleared when I relaunched the software.
What seems to "work" is duplicating the credentials and then referencing the new credentials in the parent session. Once that's done, the sub connections inherit as expected.
I suspect what caused the corruption was the accidental creation of a duplicate folder (via powershell) which overlaps with the folder in which the credentials are stored. Which isn't displayed correctly in the GUI, showing up as a single folder, both in the Gui and via Get-RDMSession. I've only discovered that problem when I try to delete such a folder, which never seems to go away because you only delete the top most or first one in the stack. I ended up looping through several removes before the original example went away.
I'm going to duplicate all the creds and rename them, but I guess if you can reproduce that behavior the bug then is either that Credentials don't survive that OR that New-RDMSession lets you do it in the first place.
Hello,
Thank you for your feedback and glad that you have found the root cause of your corrupted Credential entries.
For your information, when you create an entry using New-RDMSession cmdlet, be sure that all folders already exist in the path you will set for the newly created entry.
I think it would be hard to reproduce this as we do not have such history in a data source like the one you are using.
Best regards,
Érica Poirier