| Summary: | No "$@"-like SSH_ORIGINAL_COMMAND leads to escaping, arg-sep and metachar issues | ||
|---|---|---|---|
| Product: | Portable OpenSSH | Reporter: | Craig Ringer <ringerc> |
| Component: | sshd | Assignee: | Assigned to nobody <unassigned-bugs> |
| Status: | CLOSED WONTFIX | ||
| Severity: | enhancement | CC: | djm |
| Priority: | P5 | ||
| Version: | 6.6p1 | ||
| Hardware: | Other | ||
| OS: | Linux | ||
The SSH protocol passes the requested command as a single string and not an array of arguments, so there is no way for SSH_ORIGINAL_COMMAND to reliably go back to what was specified on the client's commandline. Close all resolved bugs after 7.3p1 release |
Hi all I've recently noticed that it's quite tricky to get a remote OpenSSH command to be invoked with the correct arguments, especially if using a command= specifier in a public key entry with "$SSH_ORIGINAL_COMMAND". When ssh is invoked, any argument quoting is consumed by the calling shell. ssh then passes the command to sshd, where it's stored in SSH_ORIGINAL_COMMAND. However, no escaping is performed by ssh or sshd to ensure that shell metacharacters are escaped and whitespace regions within arguments aren't treated as argument separators. In a normal shell, one uses "$@", which is the argument-separation-and-metachar aware version of "$*". OpenSSH lacks any equivalent. It needs one to make it possible to use SSH_ORIGINAL_COMMAND securely without making arbitrary rules ("the command may not contain any shell metachars and spaces within arguments are not permitted"). It really needs a $SSH_ESCAPED_ORIGINAL_COMMAND .