Shutting down my server

[PerthSteve]

Attempting to use this for my Ubuntu server for WOL and shutdown. I'm using oznu/docker-homebridge setup on a pi Zero W. I'm able to WOL without problems, and ping is obviously working as the status is correct in the Home app.

I'm unable to successfully perform a poweroff command via this accessory. I have tried a few things to see what's happening but I'm at a loss.

from config.json: { "accessory": "NetworkDevice", "name": "Server", "mac": "<mac-address>", "ip": "x.x.x.x", "pingInterval": 45, "wakeGraceTime": 120, "shutdownGraceTime": 15, "shutdownCommand": "ssh -v user@x.x.x.x sudo poweroff" },

This is what I see when I view the logs after switching off the server in the home app:

`[2018-7-10 13:53:45] [Server] NetworkDevice shutdown cycle started for "Server" (x.x.x.x) [2018-7-10 13:53:45] [Server] Attempting to shut down "Server" (x.x.x.x) using "ssh -v user@x.x.x.x sudo poweroff" [2018-7-10 13:53:45] [Server] NetworkDevice "Server" (x.x.x.x) went from status "Online" to "Shutting Down" [2018-7-10 13:53:46] [Server] An error occured while trying to shut down "Server" (x.x.x.x): Error: Command failed: ssh -v user@x.x.x.x sudo poweroff OpenSSH_7.5p1-hpn14v4, LibreSSL 2.6.3 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Connecting to x.x.x.x [x.x.x.x] port 22. debug1: Connection established. debug1: key_load_public: No such file or directory debug1: identity file /config/.ssh/id_rsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /config/.ssh/id_rsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /config/.ssh/id_dsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /config/.ssh/id_dsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /config/.ssh/id_ecdsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /config/.ssh/id_ecdsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /config/.ssh/id_ed25519 type -1 debug1: key_load_public: No such file or directory debug1: identity file /config/.ssh/id_ed25519-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_7.5p1-hpn14v4 debug1: Remote protocol version 2.0, remote software version OpenSSH_7.2p2 Ubuntu-4ubuntu2.4 debug1: match: OpenSSH_7.2p2 Ubuntu-4ubuntu2.4 pat OpenSSH* compat 0x04000000 debug1: Remote is NON-HPN aware debug1: Authenticating to x.x.x.x:22 as 'USER' debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: algorithm: curve25519-sha256@libssh.org debug1: kex: host key algorithm: ecdsa-sha2-nistp256 debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: compression: none debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: compression: none debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: ecdsa-sha2-nistp256 SHA256: debug1: read_passphrase: can't open /dev/tty: No such device or address Host key verification failed.

[2018-7-10 13:53:46] [Server] NetworkDevice "Server" (x.x.x.x) went from status "Shutting Down" to "Online"`

I've managed to do this exact command from a terminal session within the docker container (using homebridge-config-ui-x), which seems to run as root. I am able to ssh into the server without a password, so my key is correctly installed. I have made sure my user on the server is full sudo access.

What I can't figure out is "who" is performing the command. Is it run as root within the container? What's the difference between running the command in a terminal session, and running the command via the homebridge instance?

Pulling my (thinning) hair out, any help is appreciated

Steve

[AlexGustafsson]

I’d say that the command doesn’t seem to find any type of key for use with authentication. It tries to use a password from the stdin as a fallback but obviously fails.

Homebridge is run as the user starting it and as such all commands. If you start it with root, all wake or shutdown commands will use the same permissions.

Try to use ls /config/.ssh as a shutdown or wake command which should list your keys if they can be found. If you can’t find it, neither can OpenSSH.

Usually the keys are in ~/.ssh/ but I imagine you’ve changed some configuration. Otherwise that may be an issue.

It could also be that either your key or the server’s is created with a passphrase. Make sure that you haven’t put a passphrase on any key as you won’t be able to unlock them via a shutdown or wake command.

[TommyCardello]

Hi,

I have very similar issue. Here is the log:

Jul 12 23:39:36 tommycardello homebridge[2329]: [2018-7-12 23:39:36] [Macbook Pro] NetworkDevice "Macbook Pro" (TommyCardelloMac.local) went from status "Online" to "Shutting Down"
Jul 12 23:39:36 tommycardello homebridge[2329]: [2018-7-12 23:39:36] [Macbook Pro] An error occured while trying to shut down "Macbook Pro" (TommyCardelloMac.local): Error: Command failed: ssh TommyCardello@TommyCardelloMac.local pmset sleepnow
Jul 12 23:39:36 tommycardello homebridge[2329]: Host key verification failed.
Jul 12 23:39:36 tommycardello homebridge[2329]: [2018-7-12 23:39:36] [Macbook Pro] NetworkDevice "Macbook Pro" (TommyCardelloMac.local) went from status "Shutting Down" to "Online"

Here's what I tried:

I understand that my issue related to SSH Keys.

1. I create key on Pi and then ssh-copy-id TO my Mac. When I start Homebridge manually, Homebridge-wol works perfectly.
2. I create key on Mac and then ssh-copy-id TO my Pi. wake on lan works but asks for a password.

My issue, that I use serviceD. And when I go with option 1. everything works. But when I start serviceD it shows me log above.

I don't know how to deal with serviceD in this case.

[PerthSteve]

Hi Alex, Thanks for replying. I can see nothing in /config/.ssh when using a terminal within the Homebridge-config-ui-x. I can see that the homebridge instance is running as root. So my .ssh exists in /root (along with the associated keys and known_hosts), so is this the wrong place for this accessory? Why would it be looking in /config/.ssh? As an exercise I've copied the contents of /root/.ssh to /config/.ssh and tried the command from the home app. This didn't change the outcome. I'll check the existence of a passphrase on the server key, but there isn't one on my RasPI key. Like I mentioned the ssh works without issue if I just do it manually from the terminal, so I can't figure out why it would be any different running it from the home bridge config.json. Thanks, Steve

Edit: Just discovered that everything inside /homebridge (including config.json) is owned by abc:abc. Is it possible this has something to do with it? I can't login as that user to try it out.

[AlexGustafsson]

I read the logs which suggested that the command was searching for the configuration in /config. This accessory does not alter the way a command is executed so paths etc should be unchanged. Given that your exercise didn’t work, there must be something else grinding the gears.

If your install runs homebridge as abc so will the ssh command. You should be able to try your command as abc by using sudo -H -u abc ssh user@host with your actual command after ‘abc’.

See here for more info on running commands as other users: https://askubuntu.com/questions/294736/run-a-shell-script-as-another-user-that-has-no-password

[PerthSteve]

I think you are spot on there. As the Homebridge instance is running as abc it has no keys generated or installed on my server. abc also cannot sudo, so I’m still a bit stuck here. I’ve tried to login as abc in the docker shell, but I seem to be stuck as the user root (if I do “su - abc” I am still root). It’s as if the user abc is not allowed to login. Thanks for the link, I’ll do a bit more reading.

[AlexGustafsson]

Good thing you’ve seem to have found the core issue. It seems I cannot help you further. Be sure to come back and write about how you solved your issue - it helps me and others to debug similar issues.

Good luck!

[AlexGustafsson]

Closing due to inactivity.