CLI: SSH Support

[ava-affine]

unitctl should support configuring and interacting with instances over SSH, but should not automatically log into servers without a specific invocation from the user (unitctl instances should not seek instances over SSH). CLI needs to handle control sockets specified over SSH at least with file sockets, and preferably with TCP endpoints as well. This applies to the following subcommands:

• status
• listeners
• edit
• save ( CLI: subcommand for saving configuration #1317 )
• execute
• import

[avahahn]

So, the general solution to this in my opinion is to open an SSH tunnel on demand for the user and then interact with the control API over it (or perhaps via SSHFS in the case of a Unix socket). At the moment the user can already configure either of those externally, but it would be a value add that Unitctl does this for them.

That said, I have qualms:

• do we want to be responsible for remote administration of a users server?
• do we really want to touch the user's ssh config?
• is the engineering time worth the effort for now? I am not aware of any other similar solution that does this (except maybe Teleport by Gravitational)

The reason why we are tracking this is to make sure we are at feature parity with unitc so that we can standardize on unitctl instead.

@lcrilly Im interested if you feel like this is a priority function or if you feel like we could replace unitc with this work still pending.

[lcrilly]

Thanks for the tag.

When I think about remote management of Unit I see it in the context of a developer accessing a server that is part of their development environment. So either local VM or a something nearby over a trusted network. I don't think there is much value in building a production-grade control plane.

I'd be happy for unitctl to prioritize local unitd and Docker images, especially as this is in line with other efforts to improve the first-touch developer experience.

Securing the control API with mTLS would be a better investment of engineering effort IMO.

[avahahn]

Securing the control API with mTLS would be a better investment of engineering effort IMO.

Is there another ticket that tracks this?

[lcrilly]

Not succinctly. It has been discussed several times over the years :)

There is an active discussion (#1315) that covers one of the use cases for exposing the control API over the network. And a discussion (#993) that describes a workaround for selectively exposing parts of the control API.

It's a bit off-topic, but separating the control API from the status endpoint would remove pressure on securing the control API itself.