Is it possible to have a configuration like this:

  • A server which listen ssh connections on port 22 as usual
  • For one user (let's say git) redirect all the traffic through another port (2222 for instance)

As a result the command ssh git@host will produce the same result as ssh -p 2222 git@host.

Basically I try to have a sort of reverse proxy on ssh but as I know we can't use sub domains to distinguish ssh incoming connection, I was wondering if we can accomplish this kind of thing with an user approach.


The reason is I have set up a gitolite server in a Docker container so at the end I have a ssh daemon which listen on the port 2222 for git purpose. Additionally I have a "regular" ssh daemon which listen on the port 22 (and I want keep it).

Of course I can access to the git server through the port 2222 (if I open it from the outside) but I was wondering if I can use the "regular" ssh server from remote and then locally redirect it to the "git" ssh for the user git.

So the traffic will be something like this for the user git:

client <==> 22:server:2222:git_container

  • 1
    What are you trying to accomplish? – Michael Hampton Sep 8 '14 at 15:29
  • 2
    Could you rephrase and add more info about the "reverse proxy" thing you want? You can force a local user to always connect using a default SSH port instead of regular 22 (local user, not remote user), and set up a server to listen on several ports, but as per sshd_config you cannot have a match for a user with a specific port related directly. – NuTTyX Sep 8 '14 at 17:27
  • I added some details, I hope it's more understandable. I think that I want is not possible but it's the best place to get fixed. – FabiF Sep 8 '14 at 22:56
  • 1
    I'm dealing with similar requirements and it looks like sshpiper is what we need: github.com/tg123/sshpiper – dumolibr May 6 '15 at 15:34
  • @dumolibr Thanks a lot, it's exactly what I was looking for. – FabiF May 7 '15 at 8:36

A simple TCP port-forwarding can't do it: the username is only mentioned further into the SSH protocol, so if you insist on starting off with ssh git@host, then there have to be two full SSH authentication handshakes. I am not aware of a generic SSH-proxy that could do that transparently. You could automate the second hop server-side, e.g. by making a shell script ssh -p 2222 localhost the user's shell on the outer host. But that would be not compatible with lots of SSH's nice perks, like port-forwarding, sftp, scp, ...

A better way would be to customize the client side. E.g. in ~/.ssh/config

Host git_host
    Hostname host
    Port     2222
    Username git

and then ssh git_host (instead of ssh git@host).

If you have to walk through the outer host first (e.g. because you have no direct visibility to port 2222), then you could use these tricks here, e.g.

Host git_host
    Hostname host
    Username git
    ProxyCommand ssh -q git@host nc -q0 localhost 2222

(might not be 100% correct, play with the options)

  • I'm trying to avoid client side customization (sadly a minor ssh configuration can be too much for some users...). But it sounds like I have no user transparently solution, I'm not so surprised. Thanks for your time. – FabiF Sep 9 '14 at 10:09
  • 1
    Maybe you can have a 2nd IP address on the host and portforward its port 22? – Nils Toedtmann Sep 9 '14 at 10:36

Configure your regular SSH server to listen on a non standard port. Then you can configure gitolite to use the now free port 22.

This makes it easy for your users, and you seem capable enough to use ssh on a different port.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.