![]() In hindsight, this, of course, made perfect sense when I thought about it. It took me a bit to realize that the PowerShell creators were smarter than me and that the ConvertTo-SecureString and ConvertFrom-SecureString cmdlets based their encryption key on the identity of the user logged in. For those who haven’t quite figured it out, I will say my debugging showed that the script ran fine up to that point but failed on that particular line. Now at this point, an astute reader is probably guessing what the problem is. Even though I was using a service account, the password needed for the SFTP service is the same no matter which account is running the script. The goal was to use the same file I had created when I ran the script manually. $password = get-content $LocalFilePath \ sftp_password. The next step is to use that now encrypted password in the connection. no one looking over your shoulder will see the actual password they will just see the dots in the dialog box prompting for it.) This is a huge step because it means that you only need to enter the password once, in a secure fashion (i.e. If you try to read that file, you will see it contains the encrypted string created above.įinally, you have the encrypted password stored in a file. If you run the above, and look in the directory you set in the $LocalFilePath (which above is set to C:\temp), you will see a file name similar to cred_gregmoore.txt. This is important for reasons I will explain in a moment. You will note that the filename is based on my environment variable UserName. Don’t mistake secure for encrypted.įinally, the script takes the output from ConvertFrom-SecureString and pipes it to Out-File $LocalFilePath\cred_$env:UserName.txt Note that a secure string is simply a string that is masked so it can’t be read on the screen. It will take a secure string and convert it to an encrypted string. If you run just those two parts read-host -AsSecureString | ConvertFrom-SecureString you will get output similar to the following:ĬonvertFrom-SecureString does the opposite of what ConvertTo-SecureString does. Once the cmdlet gets the string you’ve entered, it will pipe the output to ConvertFrom-SecureString. When you use the AsSecureString it will give you a dialog box which will use dots to mask what you type in. In actuality, it will merely wait until you type some text and press enter. Note, if you run it without the AsSecureString it may appear to hang. The read-host cmdlet waits for the user to input text. The second line, however, is a bit more interesting. Where you chose to store the resulting file will depend on your specific needs. In production, I obviously would not use a temporary location. The setting of the $LocalFilePath is pretty simple. Read-host -AsSecureString | ConvertFrom-SecureString | Out-File $LocalFilePath \ cred_ $env : UserName. To do this, I will assume that it’s ok to interactively enter the plain text password once. The obvious next step then is to somehow create an encrypted password and to use that. ![]() This means anyone with access to that script now has access to the password which is far from ideal. However, as you’re probably worried about, the secure password is now embedded as plaintext in your script. You have a script you can save and run as needed. Normally this cmdlet expects an encrypted string, which is not what you are passing to it, but it can be forced to take a plaintext string and convert it to a secure string. It can also convert plain text to secure strings. As the synopsis states, Converts encrypted standard strings to secure strings. The key here is the second example in the syntax where it shows the parameters of –AsPlainText and –Force. This command will pop up the following window Get-help -ShowWindow ConvertTo-SecureString The easiest way to do this, of course, is via the command To understand what this does, it is worth checking out the help on this cmdlet. This is why you see the cmdlet ConvertTo-SecureString as the second line in the above script. The trick is, PSCredential requires a secure string for the password. Fortunately, the authors of PowerShell had security in mind and essentially force you to be secure. However, if you try passing in a normal string as the password, you’ll get an error. My first inclination was to pass in a normal string to both the username and password, and indeed, a standard string for the username actually works. This credential object then can be used by the New-SFTPSession cmdlet. This cmdlet takes the username and password and creates a credential object. If you run the above script with the provided username, password and SFTP server, you’ll see it automatically creates the session without prompting you for any information. PowerShell and Secure Strings - Simple Talk Skip to content
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |