Option to use key file instead of ssh agent signing

[Fluffy9]

After using the CLI to create a profile and attempting to create a project from existing, I get this error Environment variable SSH_AUTH_SOCK not found

It would be better to have the option to use a key file to circumvent this. This is not compatible with windows docker desktop at all: https://stackoverflow.com/questions/56078850/how-to-set-ssh-auth-sock-env-variable-in-docker-container-windows

After trying the same steps in docker in Debian linux, I get the same error so it may be more than just an issue with windows.

[FintanH]

Hey @Fluffy9, thanks for trying out the CLI!

If we go with key-file access then it would require prompting the user for their password on each command. This is possible and the CLI could be reworked to make this an option. I would not, however, really want to store the key unencrypted without knowing the security risk involved in that.

Since this seems to be a Docker issue, have you tried following the advice in article linked in the SO article: https://medium.com/@tonistiigi/build-secrets-and-ssh-forwarding-in-docker-18-09-ae8161d066?

I get the same error so it may be more than just an issue with windows.

It's definitely going to be an issue on Windows. There's no implementation for the ssh-agent code on Windows.

[Fluffy9]

Are you saying it couldn't be done securely or you just aren't sure if it could be done securely yet? I think it'd be a good feature to have and just not be the default option perhaps (and with a disclaimer maybe?). Windows support is a higher priority than absolute security in my mind. I would be using the CLI on my personal computer, so it'd be a lower security risk of than a server. In production, I'd move to linux

[kim]

Please see RFC0682 for why and how we are requiring key management to occur through a SSH-compatible agent. It does not have much to do with security, but with the fact that multiple applications need access to a signing key.

I don't expect Windows to become a supported platform in the foreseeable future, unless someone would step up as a Windows maintainer. There are too many platform specifics for which there does not even exist library support in Rust (eg. service management, unix sockets). I could imagine that a WSL2 setup would work, but I don't have experience with it.

To my knowledge, there is a native SSH agent implementation for Windows, and I don't see a reason its socket could not be mounted into a WSL2 VM. It will surely need some setup, though.

[Fluffy9]

I was hoping to be able to use radicle link in docker on windows, or at least in docker on linux. I suppose this could be revisited if that medium article doesn't solve the issue with the CLI on linux.

[kim]

that medium article doesn't solve the issue with the CLI on linux.

I admit that I didn't actually look at it. I don't think it is addressing what you're asking for, the article is about accessing SSH keys when building images.

It is a bit unclear what you are trying to do: are you wrapping the CLI commands so they get run in a stateless container? Like docker run --rm -ti rad something? Or are you entering a container, and then executing multiple commands?

If it is the former, you can simply mount the SSH socket file from the host into the container, and set the SSH_AUTH_SOCK variable. If it is the latter, I would suggest to bind-mount a directory from the host which you set as XDG_HOME inside the container. Then use the ssh agent from the distro of your container image.