The current version of this app is incompatible with Homey version 5 due to it still making use of the SDK v1. Since development of this app has been absent for quite some time I took it upon myself to rewrite it and make it compatible.
After submitting a pull request the owner replied stating that he stopped developing for Homey and has asked if I’d want to take over ownership of the app.I have since accepted ownership and deployed a new version of this app for testing here.
I would like for some others to do some testing prior to publishing this version to all other users.
So would anyone be willing to test this version of the app and all of it’s features? And would you be willing to provide some feedback?
The new features are:
Added support for keypair authentication with and without passphrase.
Added flow trigger for a received response.
Added flow trigger for a received error.
Normal username/password authentication should of course still work also, and since this is a complete rewrite, this should also be tested.
With kind regards,
Jonathan
Update: By now I have published the new version of this app, for as far as I know there are no outstanding issues with this app. Updating this app to support SDK v3 requires only updating the SDK version in the app.json file. I have not done so yet as that would break compatibility with older firmware.
The next update to this app will only be for Homey v5 or later though (SDK v3).
want to use this for openssh on windows 10. generated and added private key at the windows side. But the app keeps giving “config.private key does not exist at given fs path”.
What is the format i need to specify the private key in the device? Thx for helping.
Following the install of updated app. I had to rebuild my SSH devices (only 2) from scratch for some reason the old ones just refused to play ball. But it’s now all working fine. The new response and error notifications are working fine too.
As I only have one Homey you can understand I could not test what happens after updating. I could not install the old version of the app as I am on v5. I did try to keep the action card and device settings backward compatibele. Too bad that updating breaks something.
I am glad to hear all is working as expected with the new features of response and error trigger cards also.
How can I push a couple of commands. I now manually upgrade my docker image. For this I do the following
sudo su -
<password>
cd /volume1/docker/
./create_unifi_container.sh
The latter is a script i’ve created to kill and delete the current container, update the latest image, copy the latest certificates and start up the container again.
That led to the situation that the ssh client hang at
Dec 28 14:16:22 pi sshd[3125]: debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received [preauth]
Dec 28 14:16:22 pi sshd[3125]: debug3: mm_request_send entering: type 0 [preauth]
Dec 28 14:16:22 pi sshd[3125]: debug3: mm_choose_dh: waiting for MONITOR_ANS_MODULI [preauth]
Dec 28 14:16:22 pi sshd[3125]: debug3: mm_request_receive_expect entering: type 1 [preauth]
Dec 28 14:16:22 pi sshd[3125]: debug3: mm_request_receive entering [preauth]
Dec 28 14:16:22 pi sshd[3125]: debug3: mm_request_receive entering
Dec 28 14:16:22 pi sshd[3125]: debug3: monitor_read: checking request 0
Dec 28 14:16:22 pi sshd[3125]: debug3: mm_answer_moduli: got parameters: 2048 4096 8192
Dec 28 14:16:22 pi sshd[3125]: debug3: mm_request_send entering: type 1
Dec 28 14:16:22 pi sshd[3125]: debug2: monitor_read: 0 used once, disabling now
Dec 28 14:16:22 pi sshd[3125]: debug3: mm_choose_dh: remaining 0 [preauth]
Dec 28 14:16:22 pi sshd[3125]: debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent [preauth]
Dec 28 14:16:22 pi sshd[3125]: debug3: send packet: type 31 [preauth]
Dec 28 14:16:22 pi sshd[3125]: debug2: bits set: 2063/4096 [preauth]
Dec 28 14:16:22 pi sshd[3125]: debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT [preauth]
Only after I added “ecdh-sha2-nistp256” to the list of kex restrictions I could get it to work. The kex is okay, but there are certain concerns in the security about the strongness of this algo. Is there anything particular you did or did not to only allow certain KEXes?
I simply made use of node-ssh. What is and is not supported is directly the result of the support offered in that repository.
I intended to keep this app lightweight and this repository seemend right for that purpose.
The previous version of this app of the former developer did not support keypair authentication at all, so I figured this was a major improvement as it is.
Having a problem with the SSH. Have created two SSH Server. But the command I want to send gets only send to the last server I created even if I selected the first SSH server.
I have the same problem as @sjoerd. Maybe some extra information what can help.
The last one added is the one with a red aclamation mark with the code:" error:{errno";“EHOSTUNREACH”,“EHOSTUNREACH”,“syscall”,“connect”,“address”,“192.168.1.100”,“port”:22,“level”,“client-socket”}". This is strange, because this is the raspberrypi that is listening to both added SSH-client on homey when i give the command:“sudo shutdown -h now”. Is the last added SSH-client maybe overwriting the first added SSH-client instead of adding a second new one?
I have found that getting the device settings from within the device action trigger does not return the device settings but actually the settings from the last device.
I have found the way to get the correct settings and applied that in a new release that is ready to be tested.
Strange enough is the other raspberry pi listening to the “sudo shutdown -h now” and is the previous working raspberry pi ignoring this with a red exclamation mark in the flow. By device i get the error:"error: “level”:“client-authentication”
Do be sure i removed and reattached them both, but that didn’t help.
In this version:
Added a state reset upon updating device settings (remove exclamation mark from a device that had a problem).
Using multiple servers now working properly.
