How about a plugin for sshpiperd (reverse ssh proxy based on usernames / cert)

[TomFreudenberg]

Hi

I am wondering if a plugin for this tool maybe helpful and does make sense:

https://github.com/tg123/sshpiper

This tool will run a SSH daemon based on the ssh-go-lib and allows to create pipes for
forwarding ssh requests.

Instead having multiple ip addresses or multiple ports open to forward traffic to internal ssh servers, you may define a pipe list based on usernames or/and certs to allow forwarding:

e.g.

ssh user1@local ---> operator@machine1
ssh user2@local ---> user@machine2

This is at least very helpful and could be managed by a front-end as opnsense plugin.

My questions are:

a. does this break security in a way that it won't be selected as a opnsense plugin?

b. is this a interesting plugin which should be on the plugin-list?

[TomFreudenberg]

Update from component author:

sshpiper is based on modified golang crypto library:

https://github.com/tg123/sshpiper.crypto

This is the diff:

https://github.com/golang/crypto/compare/master...tg123:master

[psuter]

Hi Tom
I just discovered sshpiper myself and saw your issue on the gihub page. My concerns are more with the type of application that would come from using it on opnsense rather than with the tool itself. I can't say anything about the internal security of the tool.

So let's assume that you are using opnsense as a firewall between the internet and your corporate network. The idea of using sshpiper might be, to allow (root?) access to some servers in your corporate network from the outside in oder to remotely administer them without the need of a vpn connection, or for some unprivileged users to do stuff on the server without a vpn connection to your office and without the need to remember which server is forwarded to which port.

because sshpiper acts a s a man-in-the-middle, it won't be possible to connect via sshpiper with your private-key for which you have stored the public key to the authorized_keys file of your server. instead, you will have to add your public key to the sshpiper's authorized key for this specific user and then create a  new private-key which needs to be stored on the sshpiper host (opnsense in this case) and then add the public key for this key to the authorized_keys on your target server for the target user. Alternatively you can of course enable password authentication but that's just a bad idea in itself on internet reachable servers..

so now comes the issue with this: if for some reason your opnsense gets compromized, let's say there is a vulnerability in opensense itself or one of the plugins you may have installed, that allows through one way or another to retrieve those private keys from your opnsense firewall, you have of course an issue, because someone now has a bunch of keys for your servers that will let them straight in. worst case, the same vulnerability allows to access your corporate network too, the attacker just got access to all your ssh servers and the linked accounts bascially "for free" when he hacked your firewall. that's bad.. or in another scenario, a user on the inside of your network (say a student at a school, or a frustrated co-worker) may use those keys to access your servers from the inside.
in boths cases, your servers are compromised, even if you have taken the time and effort to configure a zero-trust corporate network..

so personally if i where to use sshpiper for an application like this, I would run it in a dedicated VM, container or even appliance (think raspberry pi or similar) if you have a docker envrionment anyway, where you can make sure that the VM or container exposes only the sshpiperd port to the outside world. This will lower the chance of a "side-channel" attack on your private keys via some other potentially vulnerable software tremendously.

with this in mind, you can then start to leverage the security advantages this setup may give you.. for exmaple if the admins of those target servers or the users behave insecurely (let's say they create test users with really weak passwords for example) you know at least, that those weak user's accounts won't be accessible from the internet and are only a risk to your internal network security..
or you coud use the sshpiper's log for a fail2ban rule that will lock out any IP addresses that have too many failed authentication attempts within a short period of time. sshpiper will log an entry like "2020/11/06 11:22:27 connection from x.x.x.x:yyyyy establishing failed reason: ssh: disconnect, reason 2: Too many authentication failures" so just make your fail2ban look for this and help secure your servers at least from the outside.

hope this is at least some food for thought before someone spends all the time to create a plugin for opnsense.