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.
Edit:
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
Best Answer
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 scriptssh -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
and then
ssh git_host
(instead ofssh 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.
(might not be 100% correct, play with the options)