Solved: Interacting with Linux Hosts via SSH

SeanLuce · ‎2013-03-27

Is it possible to change the PowerShell execution policy that WFA executes at?

It seems to default to RemoteSigned no matter what I do.

I have found a method to utilize SSH within PowerShell and I am trying to create workflows that interact with Linux hosts.

Thank you,

Sean

goodrum · ‎2013-03-28

Hey Sean,

I know that we covered most of this in another thread (https://communities.netapp.com/message/103920#103920). Are you good at this point? I had suggested using the native Invoke-NaSSH with the credential type of Other. I had also given a suggestion of how you can modify the Execution Policy. I wanted to document both here:

============================================

I hope you enjoyed the Podcast. We had fun doing it.

Technically, the Invoke-NaSSH is suppose to be for connections to NetApp Array but it is a regular SSH client. I have used it for several direct operations to switches and to hosts. So far no issues.

Regarding the remote execution issue: Remember that by default, WFA runs as a Local System account. If you need to change the execution policy for the Powershell modules to execute then there are a couple of options.

1) There is a tool called PsExec (http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx) that would allow you to trigger an execution as the Local System account. You could use this to test out the issues that you are having and possible change the execution policy.

2) The other option would be to 'change' the execution on the fly. If you put into the WFA command the cmdlet to 'backup' the execution policy and then set it to unrestricted. After the execution was finished then the policy would be set back to the original state. I have used this little 'trick' many times when I need to run a script:

--------------------------------------------

$curPolicy=Get-ExecutionPolicy

Set-ExecutionPolicy Unrestricted

.....

Set-ExecutionPolicy $curPolicy

--------------------------------------------

I think that we settled on the following based on your last post in that thread:

============================================

I can't believe how easy this turned out to be...

It seems like any modification at all to the included PoSH toolkit causes issues even with the bundled workflows. It must do some kind of validation to make sure they haven't been tampered with.

Passing down the WFA credential of 'Other' was what did the trick.

This is now working without any prompting:

$credentials = Get-NaCredentials -Host 192.168.24.131

Invoke-NaSsh -Name 192.168.24.131 -Command 'mkdir /mnt/now' -Credential $credentials

Thank you!

============================================

View solution in original post

goodrum · ‎2013-03-28

Hey Sean,

I know that we covered most of this in another thread (https://communities.netapp.com/message/103920#103920). Are you good at this point? I had suggested using the native Invoke-NaSSH with the credential type of Other. I had also given a suggestion of how you can modify the Execution Policy. I wanted to document both here:

============================================

I hope you enjoyed the Podcast. We had fun doing it.

Technically, the Invoke-NaSSH is suppose to be for connections to NetApp Array but it is a regular SSH client. I have used it for several direct operations to switches and to hosts. So far no issues.

Regarding the remote execution issue: Remember that by default, WFA runs as a Local System account. If you need to change the execution policy for the Powershell modules to execute then there are a couple of options.

1) There is a tool called PsExec (http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx) that would allow you to trigger an execution as the Local System account. You could use this to test out the issues that you are having and possible change the execution policy.

2) The other option would be to 'change' the execution on the fly. If you put into the WFA command the cmdlet to 'backup' the execution policy and then set it to unrestricted. After the execution was finished then the policy would be set back to the original state. I have used this little 'trick' many times when I need to run a script:

--------------------------------------------

$curPolicy=Get-ExecutionPolicy

Set-ExecutionPolicy Unrestricted

.....

Set-ExecutionPolicy $curPolicy

--------------------------------------------

I think that we settled on the following based on your last post in that thread:

============================================

I can't believe how easy this turned out to be...

It seems like any modification at all to the included PoSH toolkit causes issues even with the bundled workflows. It must do some kind of validation to make sure they haven't been tampered with.

Passing down the WFA credential of 'Other' was what did the trick.

This is now working without any prompting:

$credentials = Get-NaCredentials -Host 192.168.24.131

Invoke-NaSsh -Name 192.168.24.131 -Command 'mkdir /mnt/now' -Credential $credentials

Thank you!

============================================

SeanLuce · ‎2013-04-01

Yes, I am good for now. Thank you again!