SSH Run Pipe only supports bash

[Developer]

This pipe would be great, except that it injects "bash" in front of compiled SSH command. This means that this pipe can ONLY be used between linux machines and if someone wants to SSH to a Windows machine, it won't work. 

Resulting error: "bash: The term bash is not recognized as the name of a cmdlet..."

This could be fixed by letting pipe users set which type of remote environment they are connecting to.

Example output: 

"ssh -A -tt -i /root/.ssh/pipelines_id -o StrictHostKeyChecking=no -p 22 someUser@123.123.123.123 bash -c 'powershell.exe -ExecutionPolicy Bypass -File C:\Deployment\postInstallScript.ps1'"

The inclusion of "bash" prevents this command from working against the target Windows machine

Suggested workarounds have included configuring WSL on the target machine to enable support for bash.... but let's be serious that is not a great workaround when the SSH command could be easily modified instead

[Syahrul]

G'day, @Developer 

Welcome to the community!

Thanks for raising the suggestions. I will pass it over to our developer who owns the pipe.

Have you considered using Git Bash for Windows as an alternative without installing WSL? If not, then you can directly run the SSH commands instead of using the pipe, for example:

image: atlassian/default-image:2

pipelines:
  default:
    - step:
        script:
          - apt-get update && apt-get install -y openssh-client
          - ssh -o StrictHostKeyChecking=no -i /root/.ssh/pipelines_id -p 22 someUser@123.123.123.123 powershell.exe -ExecutionPolicy Bypass -File C:\Deployment\postInstallScript.ps1

Regards,
Syahrul

[Developer]

Thanks, I appreciate you passing it along!

Git Bash is an interesting idea and much more approachable than WSL (especially considering legacy target environments), but I still think it makes sense to let people interact with whichever remote execution environment they have access to. Not everyone is able to easily install new software on their remote servers. 

The suggestion to simply use SSH directly instead of using the SSH-run pipe is what I ultimately decided to do. It took significant monkeying around to properly initialize SSH on the pipeline container (key files etc.) (possibly due to personal lack of experience with SSH), but it is working now. I don't believe your particular SSH example would have worked and there was very little documentation supporting what I was trying to do, but I definitely appreciate the help