SSH commands fail on csh hosts? Wrap them in /bin/sh -c

One SSH command works while the next fails on the same host, using identical credentials. The culprit isn’t the connection or the user—it’s the login shell on the server.

The invisible shell mismatch

On Sakura Internet’s default setup, user accounts log in with csh or tcsh instead of bash. This matters because SSH libraries like Python’s Paramiko hand off commands to the user’s login shell. When code sends POSIX sh syntax such as 2>/dev/null or [ -f path ], csh reads the characters literally and throws errors like “unknown primary or operator.” The same command wrapped in /bin/sh -c runs cleanly, because POSIX sh interprets the syntax correctly.

Fixing one endpoint revealed the bigger pattern

A previous patch had already wrapped the SSH-connection test in /bin/sh -c, but the change lived only in test_ssh_profile. A later bug report showed that “auto-detect WordPress install path” failed while the WP-CLI test button succeeded. Tracing the codebase uncovered several SSH call sites still sending raw shell commands: path discovery, WP-CLI auto-detection, plugin list fetches, and more. Every call that relied on POSIX sh syntax was silently broken on csh hosts.

Rolling out a single helper

Instead of editing each call site by hand, the team consolidated every SSH command into a _safe_run helper. Every SSH-related API now routes through this function, which automatically wraps the command in /bin/sh -c. The helper also standardizes error handling and quoting, reducing future shell-related surprises. Static-analysis tests were added to flag any direct SSH command invocations that bypass _safe_run, keeping the fix in place long term.

---

Source: DEV Community. AI-assisted editorial synthesis — TechnoExpress.