Currently, Git over SSH with OneDev is handled via a server process that binds to a port. If you have no other SSH server running, you can bind this to the standard port 22; or if you have another IP address available, you can point a subdomain to that IP (e.g. clone.example.com) and bind to port 22 on that interface.

But for smaller-scale deployments, where there is a local SSH server already running on the host and no other IP addresses available to bind on, it becomes necessary to bind OneDev's SSH port to a non-standard port, like 222, or move the existing SSH server to another port. This is not very clean, and requires compromise however you decide to implement it.

It is possible to work around this with some Git servers, like GitLab and Gogs: you can make changes to the host SSH server's config to allow checking keys against and proxying Git operations to the underlying Git server. This is not possible with OneDev, as its SSH server is very basic, with its various processes not exposed to external programs as with GitLab. To get something like this working in OneDev, an executable would need to be created that allows for dynamic testing of pubkeys via the AuthorizedKeysCommand config option in the host's SSH server. From there, a command to proxy traffic to OneDev would be executed. This command would need to assume the user is pre-authenticated.

I considered implementing this myself but the solution would have been very hacky. A native implementation would work much better.