SSH Tunneling as Encryption and Authentication for Local Service

Question

Background:

On my server there is a service running that listens on a domain socket at /srv/socket for incoming connections and then interacts with the user that connected. Please note that this service is one that I wrote (in C++) so I can modify the service's behavior quite easily. Right now, no authentication or permission checking is done by this service (as you will see in a second this will have to change). A few developers (think five to ten) I am working with need access to this service (and this service only) from computers somewhere else in the internet. Because this service gives them quite a few privileges, I want the authentication to be as strong as possible, and the connection to be encrypted. The underlying question I have (to avoid any XY problem) is: How do I set this up?

Idea and Questions About It:

My original idea was to provide my own authentication and then use TLS for encryption (exposing the service on an external port of course). However, writing my own authentication is likely to lead to security flaws, and setting the connection up to work over TLS will be a pain.

My second idea was then to just use SSH. SSH already has very strong authentication and encryption, and basically does what I need it to. Unfortunately, I am not quite sure how to set this up. First, I of course do not want to give the devs full shell access, and so I will change their default shell to /bin/false (as per a few other answers on this and related sites). But then I still need them to be able to connect to the relevant socket. I looked into ssh tunneling but that does not seem to be what I need, and other searches for things similar to "ssh as a proxy" all reveal related but not identical issues. What is the right thing to do here? Of course, I could write a custom executable that will act as a "shell" and simply connect those users to my service, but again, this code will be security sensitive and where possible I'd like to avoid writing my own.

Best Case Scenario:

Ideally, I'd like the following to happen:

1. The user runs some command on their client.
2. An encrypted connection to a proxy service on my server is created, and the user authenticates themselves to this service (ideally this is a well established service that is known to be reasonably secure).
3. The proxy service opens a connection to my service, forwards the username (or some user identifier), and the connects the client.

What is the best way to go about doing this?

Answer 1

I know it's been awhile since your question, but in case you are still interested, take a look at my post on Server Fault. While the issue there is unrelated to your requirement, my proposed solution may be directly relevant. I was hoping to elicit some responses to that post from experts who understand security implications better than I do, but that hasn't happened.

The post is a bit long to replicate here, but in a nutshell this is the concept:

• setup SSH to require as many authentication mechanisms you need/can tolerate, e.g. password + keys + otp, etc.
• set the user shell to /sbin/nologin (/sbin/nologin is preferred over /bin/false)
• utilize sshrc on the server to call a script when the user connects (authenticates) via ssh, the script can do whatever you need it to, e.g. start your service

In the above setup, your users authenticate via SSH, and once authenticated, /etc/ssh/sshrc does the needful w.r.t. your service, and /sbin/nologin gracefully disconnects the SSH session post authentication since it's no longer required.

You can go nuts with the script in sshrc. For example, consider starting with no ports opened for your service. Once a user authenticates, the sshrc script can open a port for the user's IP in your firewall on the fly.

Please note: the above assumes, that you really, really know what you are doing with regards to ssh configuration. While there are several well tested SSH implementations out there, many of them can be easily misconfigured with major security implications. Also, for SSH authentication, I strongly recommend always use keys + (at least one thing the user knows, e.g. password or otp, ideally both).