davidbramblett

Has there been any update on this one?

Technically no, but I don't see how that has anything to do with the problem? I've turned it on and off now just to be certain, but the setting has no impact.

I can manually run the tool for the each host, and see whether it can be pinged, and whether the scan port comes up. For example, I get this from a host session.

The problem is it doesn't seem to be seeing the port, in the template, associated with the host session to do a scan port check. If I convert the host session from a host type to an SSH Shell type session, then running the Check is Online macro for that session returns like this. Without being able to Scan port, the "connect when available" doesn't work properly.

But this doesn't help as all our sessions are defined as host sessions, with an associated template to control how we connect to that host.

I have created a host session and associated and RDP session template with it.

If I navigate to Macros/Scripts/Tools and select "Check is Online" I will get a dialog that confirms the session can be pinged, but it does not seem to know what port to scan.

What do I need to do to get that working?

This is important primarily when we are rebooting devices as we can auto connect when that port becomes available, Since it's not getting the port from the template, it never scans the port to auto connect.

In the interests of avoiding a hack like this https://forum.devolutions.net/topics/34612/retrieving-private-key-from-a-private-key-credential-session

Can we get a switch added to Get-RDMSessionProperty that will output plaintext of any encrypted field? Similar to the manner in which Get-RDMSessionPassword functions.

This seems more straightforward than trying to create dedicated cmdlets for each property that might need to be converted from encrypted to plaintext. While dedicated cmdlets would be preferred, that would probably take much more development time. This could be a short to mid term solution until better options are available.

Or alternately, just a separate cmdlet for converting RDM encrypted strings to plaintext. My solution in the link above seems to make it clear the that the same encryption is used for "all" of these encrypted string fields.

I have not been able to find an official method for retrieving a private key in plaintext. So I've gotten obscenely stupid solving this problem. I'm curious if anyone has a better way of doing this. If you don't revert everything to original values with this approach then looking at the properties of the buffer session in the GUI will cause RDM to lock up. This is clearly a hack approach, which is ugly and time consuming, but it works.

$SessionBuffer = "Buffer"
$SessionKey    = "PrivateKeySession"

#Get a sacrifical username/password credential session to use as a buffer
  $cred1 = Get-RDMTCredential -name $SessionBuffer
#Get the private key session where your private key is stored
  $cred2 = Get-RDMTCredential -name $SessionKey
#Save the buffer session password for later
  $Revert = $Cred1.Credentials.SafePassword
#Set the buffer session password to the private key session private key
  $Cred1.Credentials.SafePassword = $Cred2.Credentials.SafePrivateKeyData
#refresh the buffer session
  $Cred1  | set-RDMSession -refresh
#reacquire the buffer session with the new values.
  $Cred1 = Get-RDMTCredential -name $SessionBuffer
#Get the "password" from the buffer session
  $PrivateKey = $Cred1 | Get-RDMSessionPassword -asplaintext
#Return the original password value to the buffer session 
  $Cred1.Credentials.SafePassword = $Revert
#Refresh the buffer session one last time
  $Cred1  | set-RDMSession -refresh
#You should have the original plain text private key value now.
  $PrivateKey

I have descriptions on some folders with usage instructions on what sorts of sessions belong in the folder. I notice today when I started looked at the description pane, that only actual sessions show descriptions, If I click on the folder and navigate to Overview. I can see the description, but nothing in the description pane in the side bar.

Have there been any discoveries on what's causing this?

This solution does not appear to work anymore.

It persists with chrome but doesn't seem to have a problem with IE. Except that it initially refused to load the console page due to security issues. Just refreshing it work.

Thank you much. It's a weird one.

Done! Should see it uploaded now.

When I have both an SSHShell session and an iDrac virtual console (HTML5) open in RDM, any attempt to type on any SSHShell session bounces me back to the iDrac console session. The keyboard input registers on the iDrac console instead of the SSHShell as well..

RDM Enterprise: 2020.1.19.0

.NET Runtime v4.0.30319

.NET Version Version 4.7.2. or better

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.

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.

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.

And now that I'm reviewing it again myself, I realize the outline actually describes two seemingly distinct problems.

1. The subconnection will not inherit Credentials from the parent, if those credentials are from a Credential Repository.

2. The subconnection ignores Credentials when set t Credential Repository on the subocnnection itself (I.E. not inherited)

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.

Yes, which i outlined in the original post. Have you had your coffee yet? ;-)

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.