Shutting down my server
See original GitHub issueAttempting 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: <implicit> compression: none debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: ecdsa-sha2-nistp256 SHA256:<DETAIL REMOVED> 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
Issue Analytics
- State:
- Created 5 years ago
- Comments:7 (4 by maintainers)
Top GitHub Comments
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
Closing due to inactivity.