Use AWS Get-EC2PasswordData from embedded credentials custom script
I'm trying to dynamically obtain the password for an AWS EC2 instance using the Get-EC2PasswordData powershell cmdlet. I have $Result.Username = "administrator"$Result.Domain = ""$Result.Password = Get-EC2PasswordData -InstanceId i-0123456789 -PemFile $env:USERPROFILE\.aws\MyKey.pem
Running this via powershell session works fine, however, when I even try to save this entry, I get:Could not load type 'Amazon.Runtime.CredentialManagement.CredentialProfileStoreChain' from assembly 'AWSSDK.Core, Version=3.3.0.0, Culture=neutral, PublicKeyToken=885c28607f98e604'.At line:13 char:20+ ... .Password = Get-EC2PasswordData -InstanceId i-0123456789 -PemFile $en ...+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ CategoryInfo: NotSpecified: (:) [Get-EC2PasswordData], TypeLoadException
I have AWS PowerShell 3.3.428.0 installed. I added GET-AWSPowerShellVersion to my credentials script (the output from it is included in the error dialog) and it shows the same.
I also noticed that when RemoteDesktopManager.exe starts up, there are many assembly binding errors for AWSSDK items (via fuslogvw):
These all look the same:*** Assembly Binder Log Entry (2/6/2019 @ 9:01:15 PM) ***The operation failed.Bind result: hr = 0x80070002. The system cannot find the file specified.Assembly manager loaded from: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dllRunning under executable C:\Program Files (x86)\Devolutions\Remote Desktop Manager\RemoteDesktopManager.exe--- A detailed error log follows. === Pre-bind state information ===LOG: DisplayName = AWSSDK.SecretsManager (Partial)WRN: Partial binding information was supplied for an assembly:WRN: Assembly Name: AWSSDK.SecretsManager | Domain ID: 1WRN: A partial bind occurs when only part of the assembly display name is provided.WRN: This might result in the binder loading an incorrect assembly.WRN: It is recommended to provide a fully specified textual identity for the assembly,WRN: that consists of the simple name, version, culture, and public key token.WRN: See whitepaper http://go.microsoft.com/fwlink/?LinkId=109270 for more information and common solutions to this issue.LOG: Appbase = file:///C:/Program Files (x86)/Devolutions/Remote Desktop Manager/LOG: Initial PrivatePath = NULLLOG: Dynamic Base = NULLLOG: Cache Base = NULLLOG: AppName = RemoteDesktopManager.exeCalling assembly : System.Management.Automation, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35.===LOG: This bind starts in default load context.LOG: Using application configuration file: C:\Program Files (x86)\Devolutions\Remote Desktop Manager\RemoteDesktopManager.exe.ConfigLOG: Using host configuration file: LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config.LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind).LOG: Attempting download of new URL file:///C:/Program Files (x86)/Devolutions/Remote Desktop Manager/AWSSDK.SecretsManager.DLL.LOG: Attempting download of new URL file:///C:/Program Files (x86)/Devolutions/Remote Desktop Manager/AWSSDK.SecretsManager/AWSSDK.SecretsManager.DLL.LOG: Attempting download of new URL file:///C:/Program Files (x86)/Devolutions/Remote Desktop Manager/AWSSDK.SecretsManager.EXE.LOG: Attempting download of new URL file:///C:/Program Files (x86)/Devolutions/Remote Desktop Manager/AWSSDK.SecretsManager/AWSSDK.SecretsManager.EXE.LOG: All probing URLs attempted and failed.
I also noticed Remote DesktopManager ships with AWSSDK 3.3.8.0 dlls (Core, EC2 and S3), and I suspect this is probably related.
Is there a way I can run Get-EC2PasswordData for a custom credentials script? Or another workaround that would let me do this?
Actually, I just came up with a usable (though awkward) workaround:
$Result.Password = (powershell.exe -Command "Get-EC2PasswordData -InstanceId i-0123456789 -PemFile $env:USERPROFILE\.aws\MyKey.pem")
Hello,
We need to improve our private key type to support having two payloads: the binary format, as well as the PEM format. We would also need to expose both payloads using a cmdlet.
That being said, it looks like just a scope issue. Either 32 vs 64 bit, as well as the location of the modules.
We will try to cook-up something, but I'm afraid there are only two of us that can fiddle with this. I hope to be able to play around with this in the coming days. Sorry about the delay.
Maurice