1.5 KiB
name, description, metadata
| name | description | metadata | ||
|---|---|---|---|---|
| prefer-ssh-over-rmm | When a machine has SSH available and SSH is easier, prioritize SSH over driving it through the GuruRMM agent |
|
When a target machine has SSH available (e.g. key auth already set up) and the task is easier over SSH, prioritize SSH over the GuruRMM agent. Drive it with the system OpenSSH (C:\Windows\System32\OpenSSH\ssh.exe / scp.exe) — scp the script over, run it via ssh.
Why: SSH runs as a real interactive user, which avoids RMM's pitfalls: RMM commands run as SYSTEM (git "dubious ownership", credential-context gaps) and are bound by the server-side command-timeout reaper (long jobs get killed mid-run — and a killed RMM command can leave an orphaned child process). RMM also forces base64/PowerShell-quoting gymnastics for every script. SSH sidesteps all of it.
How to apply: for a machine with SSH, default to scp script + ssh run (keep SSH commands simple — cmd-native or node absolute-path.js; complex nested PowerShell-over-SSH quoting hangs). Reserve RMM as the fallback when SSH/VPN to the target is down — RMM is agent-out to the GuruRMM cloud, so it stays reachable even when a direct VPN flaps (and is the only option on machines without SSH). Confirm SSH reachability first; fall back to RMM on connect timeout.
Example: Dataforth AD2 — ssh sysadmin@192.168.0.6 (key auth, vault [[reference_unifi_site_manager_api]]-style entry at clients/dataforth/ad2). feedback_windows_quote_stripping