Is there a way to log onto vsphere clients without seeing clear text password?

[cmjellis]

When logging to vsphere PowerCLI to connect to several vpshere client can we modify the script below so clear text password is not revealed?

example connect-viserver <server1>,<server2>, <server3> -user <MyUserName> -password <ClearTextPassword>

If I run the command the password typed on keyboard displays on screen and also in history. Is there a way to type the password where only ************* will show up on screen and in history

[LucD]

You can use the Get-Credential cmdlet, and use the returned credential object on the Credential parameter of the Connect-VIServer cmdlet

[DZ1]

I like using the VICredentialStoreItem.  Here is a sample of how I use it.  I also found out that you can use this to connect to other items.  HP has PowerShell support, and I've it to save passwords and connect to HP enclosures. 

New-VICredentialStoreItem -Host 'vCenter' -User 'Domain\user' -Password 'password' -File c:\dir\name.xml

$cred =  Get-VICredentialStoreItem -File c:\dir\name.xml

Connect-VIServer  -Server $cred.host  -User $cred.user -Password $cred.password

If you're running this as a scheduled script with a different user name, I would log onto the box with that user, and create the CredentialStoreItem under that account.  If you try and move the xml file, it won't work, you have to create a new one.

[FMON · Accepted solution]

Like DZ1 was saying, you can use the credential store.  An alternative way to store your credentials to the credential store is by using the -SaveCredentials switch when calling the Connect-VIServer cmdlet.

Connect-VIServer -Server "server1","server2","server3" -Credential $(Get-Credential) -SaveCredentials

Keep in mind that any method that uses the credential store is not very secure as the credentials in the credential store are stored on disk using reversible encryption!  Somebody who knows what they're doing can extract the credentials if they gain access to the credential store on disk.

LucD's method of storing your creds in a variable is more secure since most of the time that will stay in memory.  Keep in mind that even with Get-Credential, your password is stored in memory with reversible encryption.  Still can be compromised but it's more difficult.

Bottom line:  if this is a scheduled thing that needs to run, the credential store is probably (unfortunately) the way to do this.  if this is for an interactive session, then storing in a variable is more secure.

Would be nice if this Connect-VIServer could use the session user as previous PowerCLI versions did.  If someone know how please share!

EDIT: final thought: if you use the -SaveCredentials switch with Connect-VIServer as shown above, the next time you can connect without specifying -Credential.  For example you can just do this the next time:

Connect-VIServer -Server "server1","server2","server3"

If your password changes then you'll need to use -SaveCredentials again.

[LucD]

Besides the arguments already mentioned against the use of the CredentialStore, there is one important argument that seems to be missing.

To decrypt a password stored in there, you will need to compromise the user's logon.

That encrypted password can only be used, and decrypted, by the same account that created it, and on the same machine.

This is due to the default behaviour of the DPAPI this method uses under the covers.

But... there is a better, more portable way of storing and securing your passwords.

The use of an AES key is possible on the ConvertTo-SecureString cmdlet.

This way you can encrypt/decrypt passwords with any user on any machine, as long as you have the AES key.

The AES key is stored in a file, and needs to be protected by way of the access rights (NTFS ACLs).

There is a nice explanation of this in Using saved credentials securely in PowerShell scripts

Also have a look at the comments in that post, where the use of certificate's private key as the "key" is discussed.

And if you are on PowerShell 5.x, you can have a look at the Protect-CmsMessage/Unprotect-CmsMessage cmdlets.

They also use a certificate's private key for the encryption/decryption.

In summary, there are soso, good and better ways of protecting passwords.

Ultimately every method can be compromised, but there are gradations in "secure"!

A compromised admin account being your worst nightmare, but you knew that of course :smileygrin: