Support port-forwarding restricted ssh login

[ThomDietrich]

          It now runs through up until the actual connection:

I restricted the user on the server to only allow tunneling. This is the relevant section out of the authorized_keys: command="",restrict,port-forwarding,permitopen="localhost:8123"

restrict will disallow pty, so this will probably be the reason of the error, but why would the addon try to open a pty? I have a similar setup running with autossh in a systemd service and a similarly restricted user which does not have this problem.

Originally posted by @karlbeecken in #24 (comment)

[karlbeecken]

Hi, thanks for copying this over. This restricted setup worked up until the 1.3 update btw.

[ThomDietrich]

Hey @karlbeecken,
I like what you are doing. I wonder if we want to add a similar restriction in the recommendation by the script.

I think your issue should be solved by adding additional ssh arguments. Could you please test? It's probably something like -N or -T

[karlbeecken]

Thanks, it was -N. Actually had that in the additional arguments before, it just got lost in all the debugging in the last days 😅

I think it is a good idea to limit access for machine-to-machine SSH keys as much as possible, because as they are typically not secured by a passphrase, they are especially vulnerable if the file gets "lost" somehow.

So I would suggest that the restricted access for the key gets introduced into the addon setup message, so anyone with a copy-and-paste setup has this more secure approach by default.

[ThomDietrich]

The -N is already a default :)

home-assistant-addons/autossh/config.yaml

Line 26 in ecd5aa9

other_ssh_options: '-v -N'

[karlbeecken]

Alright, then I must have deleted it by accident 🙈

[ThomDietrich]

Btw I work with a dedicated ssh service inside a docker, which is then also linked to traefik for let's encrypt. Might be interesting for you as well. (The restriction is still meaningful.)

Would you like to offer a PR?

1. Add the restriction to the line for authorized_keys
2. I wonder if with that change -N should move to the permanent COMMAND?
3. A quick note in the README (assure the user of the limited attack surface)

Thanks!

[ThomDietrich]

Hey Karl,
just checking in. Are you still interested to create a PR for this improvement?

[karlbeecken]

Hi Thomas, sorry for the delay, I would be still interested but I have a question: Should we apply the restriction by default or make it an option somehow? If we want to add it by default, we could simply print the restricting entries in front of the pubkey during the setup "please add this key" message.

[ThomDietrich]

Happy to hear that!
Good question. As we are only making a suggestion to add the line to the server, it's still the users free choice to include this part or not. At this point, I am not even sure why the user would bother to remove it. Leaving the restriction does not offer any benefits, features or new use cases. That said, yes let's just add it to the line (instead of the alternative to offer multiple versions of it).

How about we add a bit of explanation to it. After all, not even I was aware of these additional restrictions so far. A short "Btw this first parts adds more security to your setup" would be more than enough.

As for your restriction: I'd suggest to not include the explicit permitopen and I believe we can leave out command?