I set up a dedicated SSH key pair for the purpose of forcing a specific command on a remote server. I added the public key to the remote server authorized_keys file along with a command option specifying the command to be execute when this key is used. The command is a shell script which requires a single command line argument that I'm expecting to get passed in the $SSH_ORIGINAL_COMMAND
environment variable.
When I execute the ssh
command from the client and specify the use of this specific key like this:
ssh -i id_rsa_mykey -o User=abc -o HostName=myhost xxx
The remote script executes as expected and is passed the xxx
in the SSH_ORIGINAL_COMMAND
variable.
If I attempt to pass the remote command an email address however the remote sshd
is interpreting the value as a user@host
and appears to attempt authentication on the part before the @
symbol and the remote command is never executed. /var/log/auth.log
on the remote server has the error:
Invalid user xxx from 192.168.0.1
How can I escape the @
symbol or otherwise not have sshd
evaluate the value as a user@host
and instead pass the value as is to the remote command?
I've tried both attempting to backslash escape the @
symbol as well as using --
before the argument but sshd
does not appear to support this end of arguments convention.
- Client machine is running Ubuntu with
ssh
version OpenSSH_7.2p2. - Server machine is running Debian with
sshd
version OpenSSH_6.7p1
Best Answer
I assume you have your reasons to use
-o User=abc -o HostName=myhost
overabc@myhost
.No, I think it's your local
ssh
that interprets this.In my Debian the first argument that cannot be interpreted as an option is interpreted by
ssh
ashost
oruser@host
, depending on whether@
is there or not. After this no other argument is interpreted in such way, even if there's@
in it.Now some observations:
user
fromuser@host
takes precedence over-o User=abc
,host
(standalone or fromuser@host
) is suppressed by-o HostName=myhost
.Conclusion: while using
-o HostName=myhost
,host
doesn't matter. This makes the following possible:Thanks to the presence of
dummy_host
,foo@bar
is passed to the remote side as a command, even though it includes@
character. Stillssh
connects tomyhost
, notdummy_host
, because-o HostName=myhost
takes precedence.Note:
dummy_host
may or may not bemyhost
. It may even be blank (""
).