Hacker News Reader

Comment by janosdebugs | Hacker News Reader

The root of the problem isn't OpenSSH, it's the SSH protocol itself. When a command execution is desired, the command travels over the wire as a string, not as an array of strings as execve would expect. See RFC 4254 section 6.5. [1]

The SSH server has to figure out how to deal with it, most SSH servers to my knowledge invoke a shell. Parsing the passed command and trying to invoke it without a shell can be unsafe as escaping is shell-specific. (Imagine, for example, SSH'ing into a Windows machine, which the protocol entirely supports.)

[1] https://datatracker.ietf.org/doc/html/rfc4254#section-6.5

View on HN

But you could expect

    ssh localhost sh -c 'cd /tmp && pwd'

to pass "sh -c 'cd /tmp && pwd'" over the network, which would trigger the expected behavior. But the arguments are not quoted so you end up with just: "sh -c cd /tmp && pwd".

It's because SSH sees "localhost" "sh" "-c" "cd /tmp && pwd" and will send "sh -c cd /tmp && pwd", which the remote shell will interpret as executing "sh" "-c" "cd" "/tmp" and executing on success "pwd".

Remembering to write

    ssh localhost sh -c "'cd /tmp && pwd'"

works but (a) ICK (b) I usually only remember this on about attempt three at the earliest.

ssh will read commands from stdin so this will work:

    echo "cd /tmp && pwd" | ssh localhost

Or with a here string that bash and a few others support:

    ssh localhost <<<"cd /tmp && pwd"

I often use the here string method. Maybe one of those would be easier to remember.

Oooh, the here string reads nicely to me and would require less thought about quoting/interpolation choices which is a win on its own even if it still takes me multiple attempts to remember to do that.

Much appreciated.

The problem is that the quote signs are already eaten by your local shell. The SSH binary gets the parameters like this:

    ['sh', '-c', 'cd /tmp && pwd']

How should SSH know what shell is running on the other end and escape it properly? Will it escape for Sh? Bash? Fish? Powershell? Python shell? Custom script? The SSH client would need to know what shell is running on the other end, which it can't. The server, which knows what will run, cannot fix this because it only gets the already mangled string.

This is not solvable the way the protocol currently works because you can't support all possible constellations of client/server applications and shells.

This. Exactly this.

Rule 5 of http://cr.yp.to/qmail/guarantee.html remains completely true. Don't parse. When you try to use a user interface as a command interface, you have to parse. And some day it will bite you.

The solution is to remotely invoke programs designed for the purpose, and then pass data to them in a structured format.

By the way, I had to use Powershell over ssh a couple of times (don't ask) and it works perfectly fine.

Reply on news.ycombinator.com