Configuration help required

[Rene1695]

Hey,

i have installed your plugin and just need a little bit help for the configuration.

• Do i have to add every container manually to the json by providing the ip adress?
• Do each docker need a unique IP adress or can i add the "port" to the "user@server:port" statement?
• What is the fingerprint and where do i find this and where do i have to set this in the json?

Thank you!

[chibidev]

Hi,

You don't need to add containers one-by-one. The configuration describes how to access the computer the containers are running on. Since only SSH is supported, you need to have an SSH daemon running on that server, and user, IP address and port entails the connection details to reach that daemon.

Upon the first connection, the SSH client usually asks for confirmation that you're connecting to the right server, hence it displays the fingerprint of the server. Once you confirm, it stores that and will not ask again.

Since this confirmation cannot be completed by the plugin, you need to manually connect from the machine running HomeBridge to the server running the containers, store the fingerprint, then you can configure the plugin with the appropriate username, IP and port.

Hope this clears up some of the confusion in the readme.

[Rene1695]

Hi,

thanks for the clarification and your quick response! So from Homebridge terminal i was able to access my unraid server through ssh and the fingerprint was created.

Now i am unsure, because i am able to set password and username attributes in the config file:

But in your guidelines you said that it is needed to have a password less access. Do you have done any patch so that i can use my normal root access with password as can be seen in my config?

Also i was wondering about this message in homebridge:

Do you know where the problem is?

[Rene1695]

Okey, so i managed to set up a public ssh key to password-less access my unraid server from homebridge. Also the fingerprint is stored and i set the port of my unraid ssh daemon to 22.

Sadly, i still dont see my docker containers in homekit. Do you have any more ideas? Also the yellow message in homebridge is still present.

[chibidev]

So that warning is pretty harmless, but if you want to resolve it, modify the json so it looks like this:

{
    ...
    "machines": [
        {
            ...
            "host": {
                ...
                "power": {
                    "switchOffMechanism": "suspend"
                }
            }
        }
    ]
}

but you only need that, if you want to turn on/off the host when you control the VMs/containers (i.e. turn on the server when you turn the first container/VM, turn off, when you turn off the last one). I can see that the example in the README is not up-to-date (which is why you get the warning), so it's on me :)

If the command that the plugin is running fails, you might get no containers. Can you try running the following and seeing if it succeeds? docker ps --format '{{ json . }}' --all --no-trunc | jq -s '[.[] | .Names |= split(",") | .Mounts |= split(",") | .Labels |= (split(",") | (map( split("=") | { (.[0]) : .[1] } ) | add)) | .Ports |= (split(",") | ([.[] | capture("(?<ip>[^:]+):(?<hostportrange>[0-9-]+)->(?<containerportrange>[^/]+)/(?<protocol>[a-z]+)")]))]'

[Rene1695]

Hey,

thanks for the help! Interestingly if i run this command in the homebridge console, i got "bash: docker: command not found" error. But when i run this command on my unraid server, i got a big json file returned with all the informations of my dockers etc.

But isnt this command suposed to run inside the homebridge console, because your plugin is installed inside this docker ether?

[chibidev]

No-no, this should be run on your Unraid server. Homebridge (wherever it may be running) through this plugin connects to the server via SSH, and runs this command periodically. If you got back a huge json on your Unraid server that's great.

My next guess (sorry, it's been some time since I've worked on this plugin) is that before that command even runs, the plugin pings the server to check whether it's available or not. However, as far as I can tell, it relies on the ping utility being present in the system. Can you check whether you have ping available in your homebridge console? If not, can you install it inside the Homebridge container?

[Rene1695]

Oh sorry, this makes sense, your right! So what i can tell is:

• I logged into homebridge, enter the console and ssh into my unraid server (without any password)
• I executed your docker command and i got back the hugh json file

Now i think it will be tricky and i guess, here is where the problem might be. I set up my unraid server (and all of my dockers) without custom IP addresses. I think its called "bridge" mode, so all of my dockers (also unraid) are using the same ip address but on different ports.

This way, it is hard to ping my server. I mean, i just pinged the ip adress inside the homebridge docker image and i got data received back. But i am not sure if it was my server who was responding, because also unraid uses a port number.

Do you think this might be a problem and i should assign custom (but definite) ip address for each docker container?

[chibidev]

Bridge mode should work fine. As far as I know, containers in bridge mode still have distinct IP addresses, it's just NATed by the docker daemon. So instead of your usual 192.168.x.x IP addresses, you'll get something like 172.17.x.x. Pinging your home network from inside a bridged container should work without an issue.

Pinging does not rely on ports, just addresses. So as long as you get an answer, you're good to go, the containers won't "impersonate" your Unraid server.

Are you still getting no accessories from the plugin? If not, you can try running Homebridge in debug mode. This plugin (unfortunately) isn't overly populated with log messages, but it contains some that might help us debug the situation.

[Rene1695]

Ah okey, learned something new :) so i managed to start homebridge in full debug mode, but there are no more debug messages regarding the "unraid" plugin. I only have these two entries in the whole log file (right at the beginning of a restart):

I don't want to steal any more time from you now, i think i just accept that it doesn't work for me. Thanks for all your help so far! :)

[chibidev]

Okay, so, if there are no other log entries for this plugin, then gathering the container list fails (otherwise we would see a bunch of "Adding new service ..." messages in the log. Assuming there isn't a bug with the code (as far as I know I was the sole user of this plugin, so the code might not be properly prepared for all situations, however the last time I had it installed it was working, though it was many moons ago), the following might be the culprit:

1. enableContainers is set to false (based on your previous screenshot, this is not the case)
2. ping is not available, so this plugin cannot ping the server
3. The server you're trying to poll is not available
4. Cannot establish an SSH connect 4.1. Wrong username or IP address 4.2. Fingerprint hasn't been added previously 4.3. Passwordless access hasn't been setup
5. Cannot run the command 5.1. Missing docker command 5.2 Missing jq command

Unless I missed something going through the code, these are all the decision points where no list might be returned. Based on your previous screenshot and our interactions, none of these should be an issue anymore, so I'm not sure what goes wrong.

The only thing that comes to mind is that due to the fact that you're running this inside a container, unless you set the container to bind volumes to the necessary paths (/root/.ssh/known_hosts), I think the fingerprint has to be added every time you restart the container. But if you have that setup, or you're 100% sure it is there (you can check the contents of /root/.ssh/known_hosts), I'm out of ideas.

If you're willing to give it another go, I'd gladly push out a tiny update to include more logging in a week or so (and maybe fix the README in the same go as well), and see what comes out of your setup that way.

This plugin was my first Homebridge plugin, and although I stopped developing it, because I stopped using it due to the fact that my setup is completely different now, I'd very much be happy if I had found someone else who finds it useful. So no need to apologise for taking my time, but in the same time, don't give up either! :)

[chibidev]

Oh, and one more thing. The first time when the command is actually run is after interval seconds. So in your case, the first time containers might appear in Homebridge is after 15 seconds.

[chibidev]

Btw. if you check the syslog on your Unraid server, you should see periodic logins through SSH if the plugin is working correctly (look for sshd entries). If there's any kind of issue with the SSH setup, you won't see it.

[Rene1695]

Okey i think with your last comment, we found the issue. This is my sys log on my unraid server:

But i dont know what to do with it. It seems like the ports will be count up. But it seems to be an ssh login issue, that is good to know :)

[Rene1695]

So after a couple of time on stackoverflow i tried some more stuff e.g. adding

HostKeyAlgorithms ssh-rsa PubkeyAcceptedKeyTypes ssh-rsa

to my .ssh/config but still got the some error log on my server. When i connect from homebridge via debug mode, there seems to be everythings fine:

[chibidev]

HostKeyAlgorithms ssh-rsa PubkeyAcceptedKeyTypes ssh-rsa

I tried dusting off some of my crypto knowledge and figure out what might be wrong. After digging through a vast amount of online posts (most of which recommended adding these very lines, although not specifying whether on the client or server side), some news about OpenSSH, and a bunch of random threads across the internet, and hacking together a somewhat debuggable version of this plugin, I think I might understand what's happening.

Unfortunately, 4 years of neglect seems to be shining through the blur. There were a bunch of updates for OpenSSH, but this plugin was never updated with a newer SSH client, so it uses the same algorithms that were popular 4 years ago. Unfortunately (or fortunately? depends on your POV), during this time, OpenSSH updated so many things to stay on top of security, that older standards (like using PEM format) are considered insecure, meaning that by default they will not work. This is what's happening between your HomeBridge container, and the Unraid server.

Your SSH client in the HB debug console is probably a newer one, so negotiating and communicating with the Unraid server is not a problem. However, the client that this plugin uses is outdated, and expects a format that the server does not support out-of-the-box, as a way to increase security.

Now, if you want to resolve the error "no matching host key type found", you can add HostKeyAlgorithms +ssh-rsa into your sshd config (/etc/ssh/sshd_config) and restart your SSH daemon (/etc/rc.d/rc.sshd restart). The host key negotiation should complete, and at least we should be one step closer getting this plugin work, if not working altogether (I believe we'll need to change the format of the RSA key as well, but let's see). However, there's a reason why that option is not included by default, and I'm not a security expert to understand the context enough to confidently recommend enabling it. If your server isn't published on the internet, has proper security measures in place, no insecure computers in the network, and your RSA key is fairly large, I don't think this should be a problem, but progress at your own risk. Obviously, the proper solution is for me to push out an update that updates the SSH client as well (although it may not be as easy as it sounds), however I'm not sure exactly when I will be able to do so (most probably not within 2 weeks, maybe more).

One note, though: since Unraid uses Slackware, and by default does not persist the sshd_config file, you might want to look into other ways to persist this change (e.g. by adding a one-liner to /boot/config/go).

Not that it matters too much, but I just want to add, that by using a key generated with the older format, and by adding this option to sshd_config, I could successfully run the plugin (or at least a very wacky version of it) and it showed my containers, so we're not far from succeeding. But don't let this tempt you into doing something insecure, progress only if you aren't opening up your data, yourself, and others in your home to vulnerabilities.

[chibidev]

Oh, and I think the two configuration lines that you posted are for the reversed situation. One of the OpenSSH updates moved away from the older PEM format for keys and began using a newer one. Servers tend to lag behind with updates (unless security or some other circumstance dictates otherwise), so what I think happened, is that clients were updated to prefer the newer format, while servers still offered the older one, which was then considered insecure. So people with established setups had to explicitly enable accepting the "insecure" format (since the key was already in that format), hence the configuration change you posted above.

[Rene1695]

Thanks for all your effort so far! To be honest, I don't know the subject well enough to give a qualified answer here. I have at least understood through you, what seems to be the problem and what I could then read through. Especially the area of security, here I would have to deal with it again in detail.

But I would like to try it at least once or get so far to run as with you. I have added the line in the config file and restarted the daemon. Strangely, my entire homebridge then no longer responds. No error messages come up and apparently some data is received from devices, however when I go into Homekit no device is accessible. If I then deactivate the Unraid plugin in Homebridge, everything works again. Have you experienced something similar or do you generally no longer have a Homekit setup?

If i check the log file in Unraid, there seems to be connection because the "no matching key" has gone.

[chibidev]

Did you check the Homebridge container logs as well? In my experience, two things may be happening:

1. Homebridge hangs
2. There's an exception in one of the plugins (in our case in homebridge-unraid), which completely shuts down Homebridge. Depending on the container's settings, this might put the container in a loop (if the service is set to automatically restart), otherwise the container will just exit.

I'm leaning towards option no. 2. If I understand what's happening correctly, the plugin now should be able to negotiate with the server, and check the fingerprint, however I don't think it will be able to correctly parse the key you're using, so essentially either the check fails, or the key parsing fails, both will result in an exception - crashing Homebridge altogether. Checking the container logs might be able to confirm my hunch, since you'll have a clear error message in this case.

In the long run, you might want to look into utilising child bridges. Putting plugins on their own bridge would prevent a situation like this (i.e. a faulty plugin tearing down everything else with itself), which is extremely helpful considering we're kind-of experimenting, but even in a fairly stable setup they just add stability if you're using multiple plugins (prevents a faulty update for a single plugin crashing the service). I myself have a HomeKit setup with Homebridge and a bunch of custom plugins, but I never got to setup child bridges and I regret it to this day. Unfortunately, it would be a huge effort to migrate, since I'd essentially re-create all accessories and therefore need to re-establish all scenes and automations. To be fair, child bridges weren't a thing when I first established my HB setup, but if I started now, I'd definitely utilise them right from the beginning.

[Rene1695]

Hey, the tip with the child bridges was very nice! Since i have not that much plugins and automations running, i spent the time to set all my plugins into bridge mode (except the unraid plugin). I think this setup will be much more stable in the futher :)

However, i re-enabled the unraid plugin and homekit is still responding but there is no traffic (and also no error messages ...) inside the homebridge console (and no docker containers displayed in homekit). This is the log on my unraid server. Has it look to be like that?

[chibidev]

Maybe I misunderstand your comment, but I'm a little bit confused. Did you move the Unraid plugin under a child bridge? Are other plugins within Homebridge working?

If homebridge-unraid isn't in it's own child bridge, I think it will still completely crash the entire Homebridge setup, so it will leave you with nothing working.

Unfortunately, as I've previously stated I don't have a child-bridged setup, so I don't have much experience with them, and how they handle plugin failures. I just assumed it would give us something meaningful.

However...

The Unraid log, although from a rather different perspective, may be useful. There are 2 things that occur to me reading those messages:

1. There are soooooo many login attempts. Normally, when the plugin is running correctly, you should have 1 login attempt every interval seconds (IIRC 15 in your case). You have multiple attempts happening at basically the same time (at least within a single second), but they never succeed.
2. In fact, the error message "Disconnected from authenticating user root" means that authentication never completes. It is a bit harder to compare ports and timings based on a screenshot, but if I did this correctly, the authentication window is open for ~15 seconds (basically, interval seconds). Normally, on a working key-based authentication setup, this should never happen, as the key is either almost immediately accepted, or declined.

So, I'm guessing what happens, is that the key-based authentication fails, and it falls back to PW auth, which keeps the SSH connection open for a longer time period, since it still expects the client to send over the password. It would have been nice to confirm this, but since you're not getting any error messages it's hard to see what's happening exactly. However, I must admit this is a low-confidence assumption, because it's highly dependent on your SSHD config (specifically the values for PermitRootLogin and PasswordAuthentication), but I think it should be valid for the default Unraid config.

Now, I'm not sure why you have so aggressive multiple logins happening, maybe it's a retry logic within the SSH client this plugin uses. However, if my previously detailed assumptions are correct, if we recreate the key in the old format (which the older SSH client can parse correctly), we should be able to get it running. Again, I will describe the comments you need to execute, but, as stated previously, I'm not entirely aware of the security implications of having a setup like this. So, use them at your own risk.

1. You need to re-create the key in the correct format, that the plugin will be able to parse. I could get this working with the following: ssh-keygen -t rsa -m PEM -b 1024 -f ~/.ssh/id_rsa (I chose a deliberately low bitcount, as I just wanted to get it running, rather than testing the limits of the package. I think you should be fine increasing the bitsize to 4096 or even 8192.) Run it in your Homebridge container, and make sure ~/.ssh/id_rsa does not exist (so delete/rename your previous key) when you're executing this command, as it will modify ssh-keygen's behaviour.

2. Obviously, you need to enable this key for the root user, so you have to add the public key to /root/.ssh/authorized_keys on your Unraid server.

3. At this point, you should be able to verify that the setup is working by running ssh -v -i ~/.ssh/id_rsa -o IdentitiesOnly=yes -o HostKeyAlgorithms=ssh-rsa root@192.168.0.5. This more-or-less simulates the older client and tries to use only the old formats to authenticate with the server. If you're in, you're good to go. If it fails, or asks for password, something is still not okay. Note: I'm not sure how the ssh daemon handles using the old fingerprint format compared to what it used before, so there is a slight chance it might complain about wrong fingerprint. This will look very intimidating, but it's not a problem. If you see

   @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
   @    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
   @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
   IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

   you can just replace whatever is in ~/.ssh/known_hosts to whatever you're getting as fingerprint with this command.

4. Re-enable homebridge-unraid and restart the homebridge service (or the whole container altogether, but in this case make sure everything you did in previous steps are persisted).

This is quite the journey.

[Rene1695]

Sorry for writing so late. I think the problem is that I restarted the server between and therefore the key was lost. I will try this again the days. Currently I do not have the time. Thanks a lot for all your help.