Remote Admin: WinRM vs. SSH for Elevated Tasks

When you need to run a command as an administrator on a remote Windows machine, you have two primary technologies to choose from: the traditional WinRM (Windows Remote Management) and the modern, cross-platform OpenSSH. Both can get the job done, but they handle elevation and authentication in fundamentally different ways.

This guide will provide a deep dive into both methods, comparing their strengths, weaknesses, and best use cases to help you choose the right tool for your remote administration needs.

Part 1: The Windows Native Way (WinRM)

WinRM is Microsoft’s built-in protocol for remote management, and it’s the foundation of PowerShell Remoting. It’s powerful and deeply integrated into Windows, but it has its own set of rules for elevation.

How WinRM Handles Elevation

WinRM does not have a sudo-like command to elevate in the middle of a session. Instead, elevation is determined at the start of the session. When you connect to a remote machine with Invoke-Command or Enter-PSSession, the entire session runs with the privileges of the user you authenticated as.

To run an elevated process, you must:

1. Authenticate as a user who is a member of the local Administrators group on the remote machine.
2. The remote session will then have a high-integrity (elevated) token, allowing it to perform administrative tasks.

Step-by-Step Example with Invoke-Command

This example runs a command that requires administrative privileges on a remote server.

# 1. Get the credentials of an admin user on the remote machine
$cred = Get-Credential "DOMAIN\adminuser"

# 2. Use Invoke-Command to run a script block with those credentials
Invoke-Command -ComputerName "server1" -Credential $cred -ScriptBlock {
    # This code runs in an elevated context on server1
    New-Item -Path "C:\Windows\Temp\admin_test.txt" -Value "This file requires admin rights" -Force
}

Pros and Cons of WinRM for Elevation

Pros:

• Deeply integrated with Active Directory and Kerberos.
• Returns rich PowerShell objects, not just text.
• Supports Just Enough Administration (JEA) for creating constrained, delegated endpoints.

Cons:

• Can be complex to configure (firewalls, TrustedHosts, CredSSP for “double-hop” scenarios).
• Windows-only.
• No easy way to elevate from a non-admin session.

Part 2: The Cross-Platform Way (SSH)

With OpenSSH now included in modern versions of Windows, using SSH for remote administration has become a popular and flexible alternative.

How SSH Handles Elevation on Windows

Unlike WinRM, an SSH session on Windows starts with a standard user token, even if you log in as an administrator. To perform an administrative task, you must explicitly elevate the process inside the session.

Method A: Logging in as an Administrator

The simplest method is to SSH directly as the built-in Administrator account or another administrative user.

ssh administrator@server1

Method B: Elevating with gsudo (Recommended)

gsudo is a powerful, open-source sudo equivalent for Windows that makes elevation simple and scriptable.

1. Install gsudo on the remote machine (one-time setup):

   winget install gerardog.gsudo

2. Use gsudo in your SSH command: You can now SSH in as a standard user and use gsudo to run a specific command as an administrator.

   ssh user@server1 "gsudo New-Item -Path 'C:\Windows\Temp\admin_test.txt' -Value 'Created with gsudo' -Force"

   gsudo will handle the elevation, often without an interactive prompt if correctly configured.

Part 3: Head-to-Head Comparison

Practical Showdown: Installing Software Remotely

Using WinRM:

Invoke-Command -ComputerName "server1" -Credential (Get-Credential) -ScriptBlock {
    Start-Process "msiexec.exe" -ArgumentList "/i C:\temp\app.msi /quiet" -Wait
}

Using SSH:

ssh admin@server1 "gsudo msiexec /i C:\temp\app.msi /quiet"

Both commands achieve the same result, but the SSH method is more concise and uses a tool (gsudo) that is explicitly designed for elevation.

Conclusion: Which One Should You Choose?

• Use WinRM when: You are in a pure, domain-joined Windows environment where WinRM is already configured and you need to work with rich PowerShell objects.
• Use SSH when: You are in a mixed-OS environment, need to manage machines over the internet, or prefer the simplicity and ubiquity of SSH and key-based authentication.

For modern, cloud-centric, and DevOps-oriented workflows, SSH is often the more flexible and robust choice. Its cross-platform nature and simple, firewall-friendly protocol make it the ideal tool for managing a diverse fleet of servers. However, for deep integration with Active Directory and PowerShell’s object pipeline, WinRM remains a powerful and relevant technology.