Bug 2253 - No "$@"-like SSH_ORIGINAL_COMMAND leads to escaping, arg-sep and metachar issues
Summary: No "$@"-like SSH_ORIGINAL_COMMAND leads to escaping, arg-sep and metachar issues
Status: CLOSED WONTFIX
Alias: None
Product: Portable OpenSSH
Classification: Unclassified
Component: sshd (show other bugs)
Version: 6.6p1
Hardware: Other Linux
: P5 enhancement
Assignee: Assigned to nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-07-08 16:35 AEST by Craig Ringer
Modified: 2016-08-02 10:41 AEST (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Craig Ringer 2014-07-08 16:35:26 AEST
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 .
Comment 1 Damien Miller 2014-07-09 11:40:50 AEST
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.
Comment 2 Damien Miller 2016-08-02 10:41:54 AEST
Close all resolved bugs after 7.3p1 release