SSH and WinRM Troubleshooting

Troubleshoot common SSH and WinRM deployment failures in Harness Continuous Delivery

This topic outlines troubleshooting methods for Secure Shell (SSH) and Windows Remote Management (WinRM) deployments in Harness. Use it when Shell Script, Command, or WinRM steps fail with access, exit-code, or connectivity errors.

---

What you will learn from this topic

• How to resolve PowerShell "Access is denied" errors on network paths during WinRM sessions

• How to make Shell Script steps fail correctly when PowerShell reports non-terminating errors

• How to clear WinRM authorization-loop and connectivity failures

• How to capture exit codes, output variables, and clean up long-running remote processes

---

Before you begin

Confirm the following before you apply these fixes:

• SSH or WinRM deployment path: You are deploying to virtual machines with SSH or WinRM. Go to VM deployments using SSH or Windows VM deployments using WinRM to review the deployment setup.

• Pipeline access: View and Execute permissions on the pipeline so you can re-run steps after a fix.

• Host access: Credentials and network access to the target host (SSH port or WinRM port 5985/5986 as configured).

---

Troubleshooting

Expand an issue below for the resolution and sample commands.

PowerShell script fails with "Access is denied" during a WinRM session

A PowerShell script that includes commands such as New-Item fails with "Access is denied" when executed during a WinRM session. This typically occurs while writing to a network path due to insufficient permissions or session-related restrictions.

Resolution

Grant the required permissions. Use Access Control List (ACL) commands to grant full control to the user on the shared folder:

$acl = Get-ACL -Path ShareFolderPath
$AccessRule = New-Object System.Security.AccessControl.FileSystemAccessRule("USERNAME", "FullControl", "Allow")
$acl.SetAccessRule($AccessRule)
$acl | Set-Acl -Path ShareFolderPath

Establish a network path connection. Use NET USE to connect to the shared resource:

NET USE "ShareFolderPath" /user:USERNAME PASSWORD

Shell Script step succeeds even though the script reports an error

The Shell Script step in Harness succeeds despite the script encountering an error and returning a non-zero exit code.

Cause

• Non-terminating errors: PowerShell treats some errors as non-terminating by default. These do not trigger failure in the script unless you convert them to terminating errors.

• Exit code handling: Without proper handling, the script may not propagate the correct exit code to Harness, so the step succeeds.

Resolution

Force termination on errors. Add the following line at the beginning of the script to turn non-terminating errors into terminating ones:

$ErrorActionPreference = [System.Management.Automation.ActionPreference]::Stop

Use $LASTEXITCODE. Append the following line to propagate the exit code from subcommands:

exit $LASTEXITCODE

Invoke commands with -ErrorAction Stop. Add -ErrorAction Stop to commands that might generate non-terminating errors so they trigger failure handling:

Invoke-Command -ScriptBlock { # Your command } -ErrorAction Stop

WinRM setup fails with an "Authorization loop detected" error

A WinRM connection to a remote machine fails with an error similar to:

Authorization loop detected on Conduit "{http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd}WinRmPort.http-conduit" on URL "http://<host>:5985/wsman" with realm "WSMAN"

Resolution

Validate Group Policy settings. Perform the following steps:

1. Open the Group Policy Editor (gpedit.msc).

2. Go to Computer Configuration -> Administrative Templates -> Windows Components -> Windows Remote Management -> WinRM Service.

3. Enable Allow remote server management through WinRM.

4. Set the IPv4/IPv6 filter to *.

5. Ensure the Windows Remote Management predefined rule is enabled under Windows Firewall with Advanced Security -> Inbound Rules.

6. Enable Windows Remote Shell.

Test connectivity. Run these commands to verify connectivity:

Test-WsMan <remote_host>
Test-NetConnection -ComputerName <remote_host> -Port 5985

PowerShell command does not capture exit code in Harness

When you run a script in Harness using PowerShell, the script executes and completes successfully both manually and locally on the destination server. In the Harness pipeline, the script finishes execution, but Harness does not recognize the exit and eventually times out.

Resolution

Disable the Gradle Daemon so the script provides a proper exit code, and use $LASTEXITCODE in PowerShell to exit with the correct status. The following example shows the updated pattern:

$ErrorActionPreference = [System.Management.Automation.ActionPreference]::Stop

cd F:\GetPaidPerf\src\gp-qa-performance\jmeter\
gradle createDist -PchecksumIgnore --stacktrace --no-daemon

exit $LASTEXITCODE

• --no-daemon: Prevents Gradle from running in daemon mode, so a proper exit code is returned.

• exit $LASTEXITCODE: Propagates the exit code from the gradle command to Harness.

Output variables are not displayed in PowerShell scripts

Output variables in PowerShell scripts are not displayed properly, particularly when using the WinRM protocol in a Windows environment. This can happen if environment variables are not set correctly in the PowerShell script.

Resolution

Set environment variables explicitly within your PowerShell script using the following syntax:

$env:var_name = "var_value"

Curl command fails because of carriage return characters

The curl command fails in Shell and Bash scripts with errors such as sh: : not found or bash: $'\r': command not found.

This is caused by carriage return (\r) characters in the script, often introduced by the editor used when copying the script content.

Resolution

Perform the following steps:

1. Inspect the script in the pipeline YAML for unwanted carriage return characters (\r).

2. Remove the \r characters from the script.

3. Re-run the pipeline.

Long-running step on a remote host stays stuck after the script finishes

A pipeline step may stay stuck and fail to progress even after the script has completed execution. Ideally, the step finishes once the script completes.

One possible cause is unclosed driver processes during Maven Selenium tests run via WinRM. If those processes are not terminated by the unit tests, the remote session can remain active.

Resolution

Incorporate process-cleanup logic into your Harness Shell Script or Command step PowerShell scripts so leftover browser driver processes are terminated.

Incomplete helper dependency

The sample below references Get-AllDescendantProcesses. That helper is not defined in this topic. Treat the pattern as guidance for monitoring the Maven process and classifying subprocesses; supply or define Get-AllDescendantProcesses in your own script library before you run this in production. Validate the full cleanup script with your engineering team.

# Put Maven arguments here
$mvnArguments = @()
# Example of Maven arguments
# $mvnArguments = @(
# "-B",
# "clean",
# "install",
# "test"
# )
try {
    # Start the Maven process
    $mvnProcess = Start-Process -FilePath "mvn" -ArgumentList $mvnArguments -NoNewWindow -PassThru

    # Add or update browser processes to terminate based on the Selenium drivers in use
    $browserProcessesToTerminate = "chrome|chromedriver|msedge"
    # Initialize process collections
    $javaSubProcesses = @{}
    $nonJavaSubProcesses = @{}

    # Monitor Maven process and classify subprocesses as Java or non-Java
    while ($mvnProcess.HasExited -eq $false) {
        try {
            # Collect current Maven subprocesses
            $currentSubProcesses = Get-AllDescendantProcesses -ParentProcessId $mvnProcess.Id
            foreach ($subProcess in $currentSubProcesses) {
                if ($subProcess.CommandLine -match "java") {
                    if (-not $javaSubProcesses.ContainsKey($subProcess.ProcessId)) {
                        $javaSubProcesses[$subProcess.ProcessId] = $subProcess
                    }
                }
                else {
                    if (-not $nonJavaSubProcesses.ContainsKey($subProcess.ProcessId)) {
                        $nonJavaSubProcesses[$subProcess.ProcessId] = $subProcess
                    }
                }
            }
        } catch {
            Write-Error "An error occurred while monitoring subprocesses: $_"
        }

        Start-Sleep -Seconds 5
    }
} catch {
    Write-Error "An error occurred while running the Maven process: $_"
}

---

Next steps

• VM deployments using SSH: Configure SSH-based traditional deployments.

• Windows VM deployments using WinRM: Configure WinRM-based traditional deployments.

• SSH and WinRM FAQs: Review frequently asked questions for SSH and WinRM.