reverse ssh, but with a catch

[user_with_name]

I have been thinking about remote access to my services sitting behind dedicated opnsense firewall at home. I see there are many options to achieve this including setting up vpn on opnsense or vpn on vps or tailscale/zerotier, etc., I also see there is an option to setup reverse ssh to a vps hosted ssh server, so that no ports are needed to be opened as the traffic originates from the inside.

But, i got a thought what if the ssh server is run on a laptop instead of vps. I am not sure if this even makes sense or doable, i would like to explore. Intention is to avoid opening any ports in Home-A and to avoid vps. Opening port in Home-B temporarily is fine.

scenario: opnsense and homelab services are installed in Home-A. Home-B is a remote location where i go once a month. I also have two domains mydomainA.com and mydomainB.com. Both places have dynamic ip from isp. I use ddns to update the dns entries on both places. I now need to setup reverse ssh to access Home-A from Home-B and set the ssh server on the laptop which i can switch on or off on-demand.

How to ensure ssh connection is only established when the laptop's ssh server is switched on ? One way i can think is to set up opnsense to keep trying every 15 minutes for 10 tries to establish ssh pointed to Home-B domain. Like:

Code: [Select]

ssh -R user@mydomianB.com:fw.mydomainA.com

[bartjsmit]

It will be your luck that you open your laptop just after OPNsense tried to connect to it. It is also not very resilient - if your SSH connection drops you need to wait for an average of 7.5 minutes until it comes back.

What about SSH over a Cloudflare tunnel?

Bart...

[user_with_name]

yes, but that's something i am thinking about, how to leverage this ssh option without compromising the convenience of access. There is a mention of fwknop(link below) in this forum, a tool to port knock and allow temporary port opening. I am not familiar with the tool and have explore it.

https://forum.opnsense.org/index.php?topic=23915.0

While i explore, i would like to keep third parties away as much as possible. Cloudflare tunnel is good but their ssl termination is bit concerning for me as they might have the possibility to sniff packets in between.

[bartjsmit]

You will likely have an easier time setting up a port knocker SSH call-back on a Linux server behind OPNsense: https://www.tecmint.com/port-knocking-to-secure-ssh/ I'm always wary that the next OPNsense update wipes the config of anything that's not an installed plugin.

You'd obviously change the iptables commands to SSH tunnel up and down commands. You can probably just log out of the shell instead of tearing down the tunnel with a port knock.

Bart...

[user_with_name]

Thanks. I agree with updates wiping the config. I use bind plugin for internal dns and wanted to have bind views. So, modified the bind template. Now most times when there is an update to bind plugin, it overwrites the template file which i have to replace manually to get my bind views to work.

Thanks for sharing the article, I have come across about konckd. Its interesting. Unfortunately, its not secure enough as the following two shows:

https://vickieli.dev/system%20security/port-knock-sniffing/
https://security.stackexchange.com/questions/71134/is-there-any-practical-attack-on-port-knocking-method

I did find couple of repos that discuss about secure port knocking:
https://github.com/Jiab77/cryptknock  --> this repo was updated 7 years ago
https://github.com/moxie0/knockknock --> this repo was updated 11 years ago, from moxie0 founder of signal messenger

Nevertheless, there is a detailed article about Single Packet Authorization (SPA) based on fwknop in ubuntu documentation here:
https://help.ubuntu.com/community/SinglePacketAuthorization

And one more article discussing port knocking with OTP: https://armin.su/port-knocking-with-otp-to-secure-ssh-port-53f2724a07cd?gi=9c55f87bc9c0

I will have to spin up a opnsense development vm and some test vms to explore by testing them.

[cookiemonster]

Would it not be simpler and just as safe/secure to have a small VM always on as a listening ssh server. Lock down the access to it from OPN and additional hardening on the VM itself with the likes of fail2ban, etc.?
Or maybe I miss something.

[user_with_name]

Would it not be simpler and just as safe/secure to have a small VM always on as a listening ssh server. Lock down the access to it from OPN and additional hardening on the VM itself with the likes of fail2ban, etc.?
Or maybe I miss something.

wouldn't the firewall then needs to have an open port for that small vm with a listening ssh server ?
I am trying to find a way to access the internal networks behind opnsense at home without opening ports or using a ssh server on a vps.

[Patrick M. Hausen]

I am trying to find a way to access the internal networks behind opnsense at home without opening ports

Why? Don't you trust VPN or SSH technology and modern cryptography?

If you open SSH, use public key authentication only, keep your private key on e.g. a Yubikey device ... there is no way in this universe someone will get unauthorised access as long as the key never leaves your possession.

[cookiemonster]

Exactly. It seems the OP is IMHO overcomplicating for no real gain.

[user_with_name]

Why? Don't you trust VPN or SSH technology and modern cryptography?

If you open SSH, use public key authentication only, keep your private key on e.g. a Yubikey device ... there is no way in this universe someone will get unauthorised access as long as the key never leaves your possession.

the post is not about unauthorised access to a device or cryptographic technologies. Its about accessing the device without opening ports. As mentioned in the previous posts if a ssh server is running in a vps, then there is no need to open ports as the internal device can already make a tunnel connection to vps. I looking into what if vps is not an option.

[Patrick M. Hausen]

Open the port, plain and simple. I'm arguing that this is a valid option.

[user_with_name]

i agree its a valid option and that's what i use now. All i am searching is an alternative.

[bartjsmit]

Unfortunately, its not secure enough as the following two shows:

I disagree - those articles you quote discuss attempts to replay the port knock sequence to take advantage of the firewall port that gets opened to the knocking IP.

If you use port knock as a trigger to make an outbound connection, this does not apply since the target of the outbound is not the knocker IP but a DDNS endpoint you control.

For the record, I agree with Patrick that there's nothing wrong with a keypair-secured SSH inbound other than endless connection attempts in your logs. I enjoy a good puzzle though 

Bart...