Ok, it looks like we need to see what’s being reporting in the logs, Is there a logfile/syslog on your ReadyNAS so you can see what was recorded when you tried it ?
QQ:, when you first sent the shutdown command, (using putty to ssh on to Vera ) did you get a response back?
Yes, when I entered the following: “ssh root@192.168.1.86 rnutil rn_shutdown”
It asked me for the ReadyNas password, which I entered and then it shut down.
Ok, then sadly it hasn’t worked - as that key file you uploaded to your NAS should’ve allowed you connect from Vera without requiring a password. That’s why it’s not working when sending the command via Vera UI
that did not work.
after doing that, when I go back to Putty, and try to shut down the ReadyNas, I get:
“ssh: Connection to root@192.168.1.86:22 exited: No auth methods could be used.”
Ok, you’re going to need to check logs to see what is being sent/received and any messages that might result.
Another thing to try is this.
Install LuaTest on your Vera…
… and then access your new LuaTest page which will be something like this (192.168.xxx.xxx:3480/data_request?id=lr_LuaTest ) and then paste this chunk of code in…
local function sshexecute (command)
p = io.popen (command)
local out = p: read "*a"
print(command)
print(out)
local f = assert(io.open("/www/popen.txt", "a"))
f:write(out.. "", "\n")
f:write(command.. "", "\n")
f:close()
p:close()
print("-----------")
return out
end
at the very end of that code above , add the ssh command wrapped within this ‘sshexecute’ function
Hummmm, not sure what’s occurring there, I’ll need to look at the code again (as that’s not my area) - For now, let’s look at the ‘ssh’ command we’re using on Vera, as it seems using ssh via Putty works …
~# ssh -help
Dropbear SSH client v2019.78 https://matt.ucc.asn.au/dropbear/dropbear.html
Usage: ssh [options] [user@]host[/port] [command]
-p <remoteport>
-l <username>
-t Allocate a pty
-T Don't allocate a pty
-N Don't run a remote command
-f Run in background after auth
-y Always accept remote host key if unknown
-y -y Don't perform any remote host key checking (caution)
-s Request a subsystem (use by external sftp)
-o option Set option in OpenSSH-like format ('-o help' to list options)
-i <identityfile> (multiple allowed, default .ssh/id_dropbear)
-A Enable agent auth forwarding
-L <[listenaddress:]listenport:remotehost:remoteport> Local port forwarding
-g Allow remote hosts to connect to forwarded ports
-R <[listenaddress:]listenport:remotehost:remoteport> Remote port forwarding
-W <receive_window_buffer> (default 24576, larger may be faster, max 1MB)
-K <keepalive> (0 is never, default 0)
-I <idle_timeout> (0 is never, default 0)
-J <proxy_program> Use program pipe rather than TCP connection
-c <cipher list> Specify preferred ciphers ('-c help' to list options)
-m <MAC list> Specify preferred MACs for packet verification (or '-m help')
-b [bind_address][:bind_port]
-V Version
We currently just use -i, so as you know/trust the ReadyNAS you’re connecting to, let’s add -y too this time, and go back to the original os.execute approach.
nope -
os.execute( " ssh -i -y /etc/dropbear/dropbear_rsa_host_key root@192.168.1.86 ‘rnutil rn_shutdown’ " )
didn’t work. Command sent but did not shut down the NAS.
I may have to admit defeat and defer to others who may be following this thread.
Sadly it’s not unusual for Vera to come up short, hence sometimes I have to use other tools, the main one being Node-Red - and conveniently someone has posted something there that might help.