views:

70

answers:

2

I have a Powershell script that is going to be run through an automation tool against multiple servers. It works fine on Windows machines, as the remote calls use the tool's service account without any need for prompting or exposing any credentials in code. This script also runs against Linux machines via SSH using the SharpSSH package. SharpSSH does not automatically use the Powershell user's credentials but requires either a username and password, an RSA key file, or a PSCredential object. I can't prompt for credentials using Get-Credential because it's being run through the automation tool. I don't want to expose the username and password in code or have an RSA key sitting out there. I would like to construct a PSCredential object from the current Powershell user (the service account). Trying [System.Net.CredentialCache]::DefaultNetworkCredentials shows a blank, and [System.Security.Principal.WindowsIdentity]::GetCurrent() doesn't provide the object or information I need.

Does anyone have a method for creating a PSCredential object from the current user? Or maybe a completely different alternative for this problem?

Many thanks!

A: 

Since you can get the password in plaintext from a credential object, I doubt you can get this without prompting.

Mike Shepard
+3  A: 

The Windows API will not expose the information you need, which is why Powershell can't get to them. Its an intentional feature of the security subsystem. The only way for this to work is for the Linux machines to trust the calling machine, such as joining them to an Active Directory (or any kerberos setup really).

Aside from that, you'd need to store and pass this information somehow.

You could store the RSA key in the user's keystore and extract it at runtime (using the .NET Crypto/Keystore libs), so you aren't storing the key around with the code. That way the key itself would be protected by the OS and available only when the calling user was authenticated. You'd have one more thing to install, but may be the only way to achieve what you are aiming for.

Taylor
Ahh, that's unfortunate. After some discussions and research, we're going to go with the RSA key. It'll end up enabling more in the future anyway. Thanks, Taylor!
Beege