1

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
8
  • Did you try with ' xxx@yyy '?
    – Hastur
    Jul 9, 2016 at 7:20
  • I just tried this and it doesn't work. Good try though! Remote sshd still reports same error.
    – Bob
    Jul 9, 2016 at 12:11
  • I found a suitable workaround by passing the argument on stdin to the remote script but it still would still be nice to know if it is possible to pass the argument on the command-line.
    – Bob
    Jul 9, 2016 at 12:54
  • 1
    I have no problem at all ssh remothost ./Echo.sh xxx@yyy. Where Echo.sh is a script executable in the remote home. Please edit again your post and add the Systems on which you work, and the versions of ssh and sshd. BTW -o HostName=myhost myhost is the remote one. Try to put its IP address (host myhost). If still not enough try with ssh -v ... to have verbose output of the informations.
    – Hastur
    Jul 9, 2016 at 12:56
  • 2
    Why don't you do jsut ssh -i id_rsa_mykey abc@myhost xxx? Using the options for the host and user is very weird. And ssh does not interpret the second @ on the command-line.
    – Jakuje
    Jul 10, 2016 at 13:28

1 Answer 1

1

I assume you have your reasons to use -o User=abc -o HostName=myhost over abc@myhost.

… however the remote sshd is interpreting the value as a user@host and appears to …

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 as host or user@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 from user@host takes precedence over -o User=abc,
  • but host (standalone or from user@host) is suppressed by -o HostName=myhost.

Conclusion: while using -o HostName=myhost, host doesn't matter. This makes the following possible:

ssh -i id_rsa_mykey -o User=abc -o HostName=myhost dummy_host foo@bar

Thanks to the presence of dummy_host, foo@bar is passed to the remote side as a command, even though it includes @ character. Still ssh connects to myhost, not dummy_host, because -o HostName=myhost takes precedence.

Note: dummy_host may or may not be myhost. It may even be blank ("").

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .