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
Kamil Maciorowski
  • 74,068
Bob
  • 635
  • Did you try with ' xxx@yyy '? – Hastur Jul 09 '16 at 07:20
  • I just tried this and it doesn't work. Good try though! Remote sshd still reports same error. – Bob Jul 09 '16 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 09 '16 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 09 '16 at 12:56
  • Note that if you are working in a script with variable and you write something like -o HostName=$myhost$command$address and the first two variable are empty, ssh will think that the address is the username and host target of the connection. BTW I suppose you do not really need to use -o HostName=myhost you can directly write ssh ... myhost command option even without " or ' if there is nothing to be expanded or substituted by the shell... – Hastur Jul 09 '16 at 13:07
  • This works if I modify the remote forced command to ignore the first argument and use the second argument. An even better solution that works is passing the first argument as the empty string! i.e. ssh -i key -o user=abc -o hostname=remotehost '' xxx@yyy. If you add this as an answer I'll accept it! – Bob Jul 09 '16 at 14:10
  • 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 '16 at 13:28
  • @Jakuje this works provided you are not using multiplexed connections. Since i have this configured in my ssh config file I had to add -o ControlMaster=no -o ControlPath=none to the command line in order to leave out the user and hostname options. Not sure if this is a bug or by design. – Bob Jul 12 '16 at 05:14

1 Answers1

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 ("").

Kamil Maciorowski
  • 74,068