Formatting to execline

I need to run a command on remote host. But seems running into problem with formatting

Currently in rules i have this

executeCommandLine(“ssh ‘someone@remote’ ‘aplay /home/pi/sounds/fire.wav’”)
Seems the quotes drive openhab mad. So how can i fix this? Everything works if running outside of openhab

I have pin pointed the problem… openhab user didn’t have access to the remote system.
One option is to run openhab as root but seems not the best option.

I have tried the following
sudo -u openhab ssh-keygen
This generates the keys in /var/lib/openhab/.ssh/

But when trying
sudo -u openhab ssh-copy-id -i /var/lib/openhab/.ssh/id_rsa.pub user@remoteserver mktemp: failed to create file via template ‘/home/MYUSER/.ssh/ssh-copy-id_id.XXXXXXXXXX’: Permission denied mktemp failed
Any ideas?

@moskovskiy82 not sure if this helps or not, but when I was using a pi and sending curl commands from OH they would fail unless they were formatted differently. This is what I had to do:

Changed this:

executeCommandLine(“curl -d ‘{"hold":0}’ http://192.168.224.50/tstat”)

To this:

executeCommandLine(“curl@@-d@@{"hold":0}@@http://192.168.224.50/tstat”)

I followed the information provided here to format the command.

Notice the “@@”. This is neccessary, because the executeCommandLine does not support using quotationmarks. To send the http header as one string, all other spaces need to be replaces by the delimiter “@@”.

During the investigation i put all the code in a separate shell script - just callling it out from openhab, so now spaces were involved.
What i had to do (ubuntu 14.04 server) is assign a shell to openhab user.
su to openhab user and run the key transfer. Now everything is working fine.

I created my ssh keys using my regular user then copied them to ~openhab/.ssh (which is located in /var/lib/openhab/.ssh) then changed their permissions and ownership to openhab:openhab. There is nothing inside the key files themselves that ties them to the account.

However, be aware that the OH start scripts will muck with the permissions of your keys which may break your ssh. See this posting.