Homey Community Forum

SSH Client

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).

4 Likes

Get yourself a Developer Account on https://developer.athom.com/apps and then the original Developer can Transfer the App to you when you give him your Athom ID
(When you go to your Account https://accounts.athom.com/profile/####SOMEID#####)

image

image

Thanks, I have passed these instructions on.

The app can now also be tested from here:

I have received ownership so can now publish it to the store.

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.

The contents of the private key file must be pasted completely, not the public key.

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.

Thanks you for your response.

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.

Thank you for your reply!

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.

Passwords are hard to do in a batch / cron. Executing a bash script is not a problem.

Hi,

I was playing around a bit with it and first ran into problems. I usually secure my servers to only allow “good” ciphers like:

Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes256-ctr
KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
MACs hmac-sha2-512-etm@openssh.com,,hmac-sha2-256-etm@openssh.com,hmac-sha2-512

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?

Best,

Thomas

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.

1 Like

I will be taking a look at that, I am not sure when I will have the time for it though.

If I can help with testing let me know.

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?