5

I'm trying to mux between two ssh servers based on incoming username i.e.

ssh user1@testserver will go to one sshd instance and user2@testserver goes to another.

Can this be done?

3
  • Just have everything go to one server, then setup a ForceCommand to connect to the other server?
    – Zoredache
    Jan 23, 2014 at 6:15
  • WHY do you want to do this -- What actual, practical, real-world problem are you trying to solve? There is almost certainly a better solution than what you're suggesting.
    – voretaq7
    Jan 24, 2014 at 18:03
  • @voretaq7 - the question is old, but i've looking for the same. Not all is a better solution. A userbased proxy is a good idea, when you want to limit user access. Mostly, the configuration for limitations are hard to jail an user. Aug 2, 2017 at 4:51

3 Answers 3

-1

No. Everything in an ssh session is encrypted. How do you propose the proxy would be able to snoop on the username?

2
  • I was hoping the sshd instance could serve as the proxy!
    – Amaterasu
    Jan 23, 2014 at 4:16
  • 1
    The proxy would have to admit the user locally and then proxy the connection to the internal system. This is quite feasible (see the other answers)! Alternatively, port forwarding (assuming consistent IP ranges unique to each proxied user) can do it without local access.
    – Adam Katz
    Jul 22, 2015 at 23:46
7

I think you can do this with ForceCommand, like:

ForceCommand proxyscript

in /etc/sshd/sshd_config. Here proxyscript would be a custom script that would ssh to whatever the next server should be, depending on which user is running it. The script would have enough information to do that because according to the man page for sshd_config, it will run under the user's login shell, so for example $USER will be available.

If you only have a small, fixed set of users who you want to do this for, then you can configure it all in sshd_config with for example

Match User user1
ForceCommand ssh user1@host1

Match User user2
ForceCommand ssh user2@host2

But I don't know if this would correctly hook up the standard out/in of the incoming connection to standard in/out of the new ssh command.

2
1

This is quite nontrivial to do transparently (maybe tweak an SSH honeypot program to auto-login and then use ForceCommand to handle the proxy? sounds messy), but you could set up a proxy and instruct your users on how to use it easily enough.

This concept is called an SSH bastion host. No special software is needed on the proxy (the bastion). The only software the end users need access to is netcat (nc), so you could create a rather bare-bones jail for them if you wanted.

Each OS X / Linux / BSD / UNIX user would have an entry in their ~/.ssh/config file (on their local clients, not the bastion) that looks like this:

Host MYSERVER
  ProxyCommand ssh BASTION nc -w 600 USER1_SERVER 22

Each user's config would only differ in the target server (e.g. USER1_SERVER), which is connected to on the local network by the bastion. (If user names differ, consider ProxyCommand ssh BASTION_USERNAME@BASTION nc -w 600 USER1_SERVER_USERNAME@USER1_SERVER 22.)

That's actually all there is to it. Now USER1 can run ssh MYSERVER. If not using SSH keys, USER1 will be prompted for a password to BASTION, then a password to the internal system USER1_SERVER. If using SSH keys, and USER1's public key is installed in both BASTION and USER1_SERVER, login will be automatic.

Windows users can do this through PuTTY by using plink (a part of PuTTY). Here is a guide.


If you want to tightly restrict the user on the bastion, you can do this:

Match User user1
  ForceCommand nc -w 600 USER1_SERVER 22

... though this does prevent user1 from managing their authorized_keys file on the bastion.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .