Support for SSH cloning

[josh-project]

Support for SSH cloning

[jstriebel]

ssh support for josh would be absolutely fantastic.

The problem is that in order to use ssh Josh would need an additional pair of keys per user.
Those keys would either have to be maintained manually, or Josh would need extra support for fetching/installing keys in the upstream server, for which, once again it would need credentials. So while ssh looks simpler at first, setting up a proxy with it is actually much more complex than with http where credentials can simply be forwarded.

I think that fetching/installing keys in the upstream server is not something josh should rely on to be available. I could think of a rather simple initial version which would generate a new private/public key-pair per user and append the public key to the first "git clone" answer that is visible to the user. This clone would fail, but contain instructions to setup the new public key with the actual upstream git server. After this setup, all other interactions via the proxy would work. I guess if @christian-schilling's work on ssh-support is still available, this might be feasible.

[LMG]

This is work in progress using SSH agent fowarding: 7028451

[jonatansberg]

We're looking in to using Josh in order to open source parts of a bigger trunk based project at my company. This includes mirroring subtrees to public repos and using a subtree approach to compose projects that would depend on one or more of our upstream repositories.

Supporting SSH and public key auth would be crucial for this to work at a larger scale. I really don't want us to have to deal with everyones private git/github credentials.

I'm fairly new to this project (and rust in general) and only have a very limited understanding of what's what, but if there is any way we can contribute to making this happen I'd be happy for us to help!

[christian-schilling]

Hi, @jonatansberg
it sounds like your use case, synchronizing parts of a bigger repo and re-composing projects from multiple dependencies, is very much like what we are using Josh for at ESR Labs.

Regarding ssh support:
A long time ago, before this thing even had a name, I implemented support for ssh but realized quickly that is
not suitable for making a proxy, so I switched over to http and removed ssh support.

The problem is that in order to use ssh Josh would need an additional pair of keys per user.
Those keys would either have to be maintained manually, or Josh would need extra support for fetching/installing keys in the upstream server, for which, once again it would need credentials. So while ssh looks simpler at first, setting up a proxy with it is actually much more complex than with http where credentials can simply be forwarded.

If you like we can have a chat/call about this in the next days. I'm curious about your use case and why http won't work for you.
Also maybe I'm missing something and there is good solution to managing ssh keys, in which case I will gladly re-add ssh protocol support to Josh.

[fire]

I use ssh via hardware keys. Could not evaluate josh.

[LMG]

That sounds like a really good idea @jstriebel

[christian-schilling]

@jstriebel I think you are right about this. A fully automatic solution that is transparent to the user is not possible but with a little manual setup (The user installing a josh generated key into the upstream) this can work.
Note that some minimal form of ssh support was added recently, but that is just for running josh-proxy on your local machine and not suited for a multi user situation.

[RalfJung]

Interestingly, ssh pushing already works when using an https URL and pushInsteadOf. That makes me wonder whether insteadOf could be used to also make josh pull via ssh.

Or is this issue here less about the SSH protocol support and more about how to get josh to be able to access the necessary SSH keys?

[christian-schilling]

What do you mean "already works"? How can it?

But yes, the issue with SSH is entirely about josh being able to access the keys somehow.

[RalfJung]

What do you mean "already works"? How can it?

I am setting --remote=https://github.com and my .gitconfig contains

[url "[email protected]:"]
        pushInsteadOf = https://github.com/

This makes josh push via SSH just fine.

[LMG]

This doesn't, though: according to the doc, "Any URL that starts with this value will not be pushed to; instead, it will be rewritten to start with , and the resulting URL will be pushed to."

So it just pushes through Https.

Or maybe I misunderstood something. You set this on the server? But how can it get credentials?

If it just gets them from its environment, josh can already do it I believe, directly with an ssh url

[RalfJung]

So it just pushes through Https.

No, that wouldn't work, since it doesn't know my GH login. I have been using this config since ~forever, it is quite convenient to pull via https without authentication and then use SSH and key-based authentication for pushing.

That config means that if the to-be-pushed URL starts with https://github.com/, that prefix is replaced by [email protected]:, which is the interpreted as an SSH URL and handled by then regular git pushing logic.

I set this locally on my machine.

If it just gets them from its environment, josh can already do it I believe, directly with an ssh url

Sure, using an SSH URL would also work.

[vlad-ivanov-name]

both fetch and push now works over ssh. to use it, use SSH agent. you can either edit SSH config or set GIT_SSH_COMMAND

export GIT_SSH_COMMAND="ssh -o LogLevel=ERROR -o PreferredAuthentications=publickey -o ForwardAgent=yes"

Add -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no when testing with a container without persistence (no mounted volumes to preserve host key)

By default the container serves SSH on port 8022, make sure to map it