Is there luup code for sending ssh commands to a server?

[microcode]

I also wanted to execute a command on a remote server using SSH from Luup code and a search led me to this thread.

I got as far as @milillicuti but could not get the os.execute command to work either even though everything worked correctly from the command line.  After some investigation, I figured out what was wrong and how to fix it.

The problem appears to be a quirk in the Vera environment.  When you SSH into Vera the home directory is "/root" as you would expect. But when Luup code is running, the home directory is "/".  And since SSH reads and writes files in a special ".ssh" directory under the home directory, it's working with two totally different directories when running from the command line versus running from Luup code ("/root/.ssh" vs. "/.ssh").

The solution is easy: Create a symlink from "/.ssh" to "/root/.ssh" so the two different environments will always use the same directory.  This is done by running the following two commands at the Vera command line.  The first command deletes the existing "/.ssh" directory, so you may want to look at the contents first to make sure nothing important will be destroyed.  Mine contained only an empty known_hosts file, so destroying it was OK.

Code: [Select]

rm -rf /.ssh
ln -s /root/.ssh /.ssh

With that symlink in place, if you can connect to your remote server successfully from the command line without using a password, then it should also work successfully from within Luup code.

So I can shutdown my server with this Luup code:

Code: [Select]

os.execute("ssh -y -i ~/.ssh/id_rsa <user>@<server> sudo /sbin/poweroff")

The remote machine also has to be set up properly so the given command can be executed without needing a password.  For my remote machine (which is a Linux box), I did this with a sudo config file for the "vera" user.  I created the "vera" user specifically so I can control the environment and what commands can be executed when connecting from Vera. I agree with @garrettwp that access should be tightly controlled.

The user-specific sudo config file is "/etc/sudoers.d/vera":

Code: [Select]

Defaults:vera !authenticate
vera <your_hostname>=/sbin/reboot,/sbin/poweroff


As a side note, these are the commands I used on Vera to generate the private and public key files:

Code: [Select]

dropbearkey -t rsa -s 2048 -f ~/.ssh/id_rsa | grep ^ssh-rsa > ~/.ssh/id_rsa.pub
chmod 400 ~/.ssh/id_rsa
chmod 400 ~/.ssh/id_rsa.pub

Then the contents of the public key file "~/.ssh/id_rsa.pub" must be appended to the "~/.ssh/authorized_keys" file on the remote machine.

[chixxi]

I have the following command, which when I run it on vera directly suspends my pc without having to enter a password:

Code: [Select]

ssh -i ~/.ssh/id_dss -l USER IP 'bash -ic suspendnow'
However, when I try this from a scene, it doesn't work. Any ideas?

Code: [Select]

os.execute("ssh -i ~/.ssh/id_dss -l USER IP 'bash -ic suspendnow'")
I setup an alias on my linux machine, the "bash -ic" makes this work over ssh.

[futzle]

See microcode's remark above about home directories.

[chixxi]

See microcode's remark above about home directories.

Hmm, I don't know how I missed that. Thanks for pointing it out again!

[jimpapa]

I know this is an old thread but.. everyone is still around, sooooo...


I am following this and generated a public key on Vera, VI authorized_keys2 .. that create a new file, is that right .. I have an authorized_keys file already in /.ssh

.. pasted in: (using my generated key and my vera's MiOS_xxxxx)
ssh-rsa Axxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxE= root@MiOS_12345678



but still my Linux machine is asking for a Password.

[PurdueGuy]

When you ssh from Vera, it won't use your key file directly unless you tell it to.
Did you follow the steps here:  http://forum.micasaverde.com/index.php/topic,11663.msg89171.html#msg89171
I don't do this any longer, but I can try at home later to see if it still works.

[jimpapa]

Yes.. I followed you post (the one you just linked to also)

Did everything there, but yes, still prompts for the password.

[PurdueGuy]

Do you have another machine you can try to SSH from to check the key?
Is your .ssh directory (and maybe the files inside it) only readable by your user?

[jimpapa]

Yes, I have an office full of MAC's.. 

Are you saying to test from the Mac to the linux box?  I can SSH to it... but still get prompted. 

I confused on how to test if not coming from vera since the public key is from the Vera..

I know I am missing a point here someplace 

[guessed]

Check the file permissions on the receiving end, for both the ~/.ssh directory and for the ~/.ssh/authorized_keys file.  sshd's will not let you in if the file perms are incorrect, see the FILES section of the man page for the specifics on what's needed:
    http://www.manpagez.com/man/8/sshd/

[jimpapa]

Thanks for the link!

Right.. looks like a have some more reading to do..

I'm goin to set up a Virtual Machine to do my R&D on so I can break till my heart is content and not worry.

From my Mac, just now

Asked for Password still so I just kept hitting enter to not login... and I got:

Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).

so.. thats new. I don't know what it means but looks like permissions IS my issue huh ?

[gibby]

run ssh -vvv .... and post the output

[guessed]

Just a WAG, but your authorized_keys file has this as the "trusted" user:
    root@MiOS_12345678

Is "MiOS_12345678" resolvable in your DNS service by the receiving machine?  If not, try substituting the IP Address of your Vera (as a temporary work-around)

eg. root@192.168.54.34

... or whatever IP your Vera is on.  For SSH I have my Mac's FQDN in my RaspPi, as that'll resolve in my local DNS subsystem, but swapped it out for the IP and that works also.

[futzle]

VI authorized_keys2 .. that create a new file, is that right .. I have an authorized_keys file already in /.ssh

Possibly not right. Try instead adding your new (long) line to the end of authorized_keys. That one file lists all allowed keys, one per line. _Some_ SSH servers use authorized_keys2 but some ignore it.

The email address at the end is just a comment and can be anything. Don't fuss about it.

The other thing you can do to debug the situation is to tail the sshd log file, which is somewhere is /var/log and depends heavily on your exact distribution.

[jimpapa]

[root@localhost ~]# ssh -vvv
OpenSSH_5.3p1, OpenSSL 1.0.0-fips 29 Mar 2010
usage: ssh [-1246AaCfgKkMNnqsTtVvXxYy] [-b bind_address] [-c cipher_spec]
           [-D [bind_address:]port] [-e escape_char] [-F configfile]
           [-i identity_file] [-L [bind_address:]port:host:hostport]
           [-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p port]
           [-R [bind_address:]port:host:hostport] [-S ctl_path]
           [-W host:port] [-w local_tun[:remote_tun]]
           [user@]hostname [command]

Don't see any -vvv options...

I started over on a Virtual Machine and having the same problem

had to create the /.ssh dir by running ssh keygen on the linux Machine
created authorized_keys
and pasted in my Vera generated key with root@local_ip

chmod 400 ~/.ssh/id_rsa
chmod 400 ~/.ssh/id_rsa.pub

still prompted for a PW when ssh from vera to test linux VM