Hi @robin !

I'm working to this feature on my fork: https://github.com/bitstorm/onedev/tree/ssh-server. It's almost done, I should complete a first version in the next days. When I'm done I will open a PR on GitHub if it's ok for you.

That is great! Can you fork/open pull request here at code.onedev.io? Only this way we can improve OneDev quickly.

Sure! No problem

Hey, I have been just stumbled upon OneDev. This project is awesome!
Installation is a one liner and it just works™ !

Does "Commited" mean this feature is part of the master branch now?
I would be happy to test it.

Yes it means code is committed but official build is not released yet. You may test it out by compiling from master branch, just run mvn clean package and you will get onedev zip in folder "server-product/target". However please be noted that data is not guaranteed to be migrated into official releases.

I plan to release 3.1.0 in the end of this month to include ssh support as well as yaml based build spec.

Hi @mweimann ,

I still working on the documentation for this feature, but if you want to test it you might find helpful my initial post on the pull request: https://code.onedev.io/projects/onedev-server/pulls/2/activities

Really - setting up the dev env also took only five minutes 😀

I've tested the ssh support - it works.

Maybe that one is a tiny usability flaw:
The system should remember whether I have chosen SSH

Another point could be access keys per repo; for example for external tools.
A work around is easy: Creating an API user with a key assigned.

The Use SSH does not mean to enable ssh access. It simply displays alternative clone url via ssh protocol. Maybe displaying it at right side of clone label as protocol dropdown will be better. I will take that task as part of improving ssh support (to pull/push with native git instead of jgit for better performance on Windows).

As to access keys per repository, can you please elaborate with an usage scenario?

The Use SSH does not mean to enable ssh access.

Yes I know. What I mean is the system should remember if I have chosen "Use SSH".
It should show me the SSH clone URL from now on until I change back to HTTP.
I hope now it is better to understand.

As to access keys per repository, can you please elaborate with an usage scenario?

One example are external tools that should be able to push into the repo.
Concrete example is a web site generator that is connected to git and that dumps the pages and pushes them if an author wants to publish changes.

Thanks for the elaborating. I agree it is better to remember this. Will improve it.

For external tool accessing, I'd prefer with the api user approach instead of binding public keys directly to repository. Public keys and passwords are used to authenticate user, and group membership of that user is used for access authorization.

I'd prefer with the api user approach instead of binding public keys directly

I am also fine with that. The API user approach is quite flexible.

What I worry about is that users may look for this feature, because it is quite common

GitLab

image_2.png

Gitea

image_3.png

GitHub

image_4.png

Thanks for these screenshots. It helped me understanding more of the use cases. It is more convenient to use deploy keys without creating user I admit. Added a feature request for this.

Yes I know. What I mean is the system should remember if I have chosen "Use SSH". It should show me the SSH clone URL from now on until I change back to HTTP.

Rather than implementing a "remember my choice" feature, as general improvement we could also simply show the SSH clone URL if user has set a public key. I think it's safe to assume that those who has set such key prefer to use SSH to work with GIT.

Checked GitHub and it remembers the protocol whether or not ssh key is being specified. I'd second this approach as it does not make any preferences over http/ssh.

Would be ok if we implement a simple solution based on cookies or local store? I see we already use some cookies for the markdown editor

I am fine with a cookie remembering this.

Thanks for the work! With SSH I put OneDev in production for us (an open source project).
Will get back with feedback and some code from time to time :)