What's new

How to open SSH to WAN using command line?

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

merloid

New Around Here
I'm trying to work out a way to open SSH to the WAN using a CLI command instead of the web interface, I've been messing with iptables but I can't get it to work.

I was wondering if anyone knows how to do this?

Thanks in advance.
 
Depends on the device you're using.

In general though you need INPUT / OUTPUT rules allowing ssh or TCP:22
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -p tcp --sport 22 -m state --state ESTABLISHED -j ACCEPT

You need to enable SSH on the device and create the certificate to authenticate ((assuming Asus))

To secure things adding additional iptables rules such as sourcing from a particular subnet or IP would be recommended. Changing things from TCP:22 is advisable as well.
 
Thanks. I should have said, this is an Asus RT-AX56U running Asuswrt-Merlin

I have SSH set up, and when I open the port (not using 22 :) to the WAN via the settings in the web admin interface, it works.

But if I leave it set to local-only in the web interface, and then add those iptables rules (with the port changed appropriately), I can't connect externally.
 
There's probably a default rule being added to restrict it from the outside in the rules when you toggle local only.

Rules are processed from the top down and if the local only is above the permit 22 it will keep you out.
 
For instance here's what I run for rules on my custom router to keep everything out from the outside.

Code:
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]

-A INPUT -j PERMIT-IN
-A FORWARD -j PERMIT-FWD
-A OUTPUT -j PERMIT-OUT
-A PERMIT-FWD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A PERMIT-FWD -m conntrack --ctstate NEW -j ACCEPT
-A PERMIT-FWD -j DROP
-A PERMIT-IN -i lo -j ACCEPT
-A PERMIT-IN -i br0 -j ACCEPT
-A PERMIT-IN -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A PERMIT-IN -j DROP
-A PERMIT-OUT -o lo -j ACCEPT
-A PERMIT-OUT -o br0 -j ACCEPT
-A PERMIT-OUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A PERMIT-OUT -m conntrack --ctstate NEW -j ACCEPT
-A PERMIT-OUT -j DROP

Input (from WAN to LAN)
-A INPUT -j PERMIT-IN
-A PERMIT-IN -i lo -j ACCEPT
-A PERMIT-IN -i br0 -j ACCEPT
-A PERMIT-IN -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A PERMIT-IN -j DROP

Forward (NAT)
-A FORWARD -j PERMIT-FWD
-A PERMIT-FWD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A PERMIT-FWD -m conntrack --ctstate NEW -j ACCEPT
-A PERMIT-FWD -j DROP

Output (LAN to WAN)
-A OUTPUT -j PERMIT-OUT
-A PERMIT-OUT -o lo -j ACCEPT
-A PERMIT-OUT -o br0 -j ACCEPT
-A PERMIT-OUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A PERMIT-OUT -m conntrack --ctstate NEW -j ACCEPT
-A PERMIT-OUT -j DROP

(NAT = Masquerade)
-A POSTROUTING -o bo0 -j MASQUERADE

So, this is all I need to keep traffic out that I don't originate. Poking a hole in there to allow SSH would mean needing to add those lines ideally after br0 for me. So, depending on what your iptables is showing placement makes a difference in how it will react to an attempt to connect.

I've played around with a ton of different iptables configs while setting up this PC as a Router making tweaks here and there over time to either log more traffic or speed up the processing of rules. I've done auto add lists of Ip's hitting the rules and blocking them and rate limiting approaches as well.
 
With the AC86U, Set the nvram variable sshd_enable to 1, commit the changes and reboot.
 
For future reference, I found that issuing "nvram restart" to restart the WAN without rebooting the router worked.
That's not what that command is intended for. It's meant to reinitialise the wireless modules after they've been loaded/unloaded. On my router it does nothing so check that it's doing what you think it is.
 
It did seem to work for me on the RT-AX56U running Asuswrt, but is there a documented way to apply nvram changes without doing a full reboot?
 
...is there a documented way to apply nvram changes without doing a full reboot?
There's no documentation that I'm aware of. This seems to work for me:
Code:
service restart_sshd
You will be disconnected because dropbear has to be restarted.

Now log back in and run:
Code:
service restart_firewall
 
Last edited:
Thanks Colin for chiming in. I was not sure if restarting sshd alone would add the firewall rules or if both sshd and te firewall had to be restarted, thus I took the safe path and just reboot the dang thing to apply.
 
@merloid , out of curiosity, why do you want to expose SSH to the WAN? If you WAN is a public facing IP, may I suggest you further secure it by moving the port to something other than 22, adding an RSA-Key and disallowing password login. None of my business, but hate to see you hacked.
 
That's not what that command is intended for. It's meant to reinitialise the wireless modules after they've been loaded/unloaded. On my router it does nothing so check that it's doing what you think it is.

You were right. It was not doing what I thought it was doing.

There's no documentation that I'm aware of. This seems to work for me:

Thanks, the service command is what I was looking for. I should read the docs better.

out of curiosity, why do you want to expose SSH to the WAN? If you WAN is a public facing IP, may I suggest you further secure it by moving the port to something other than 22, adding an RSA-Key and disallowing password login. None of my business, but hate to see you hacked.

Very fair question! I don't have SSH or web access open to the WAN. I'm looking at using knockd to open access on-demand as an alternative to using a VPN.
 
How is knockd better than a VPN? I don't see that benefit. The exposed services are still running 24/7, after all.
 
How is knockd better than a VPN? I don't see that benefit. The exposed services are still running 24/7, after all.

Example #1:​

This example uses two knocks.The first will allow the knocker to access port22 (SSH), and the second will close the port when the knocker is complete. As you can see, this could be useful if you run a very restrictive (DENY policy) firewall and would like to access it discreetly.[options]
logfile = /var/log/knockd.log
[openSSH]
sequence = 7000,8000,9000
seq_timeout = 10
tcpflags = syn
command = /usr/sbin/iptables -A INPUT -s %IP% -j ACCEPT
[closeSSH]
sequence = 9000,8000,7000
seq_timeout = 10
tcpflags = syn
command = /usr/sbin/iptables -D INPUT -s %IP% -j ACCEPT

It's allowing you to keep the SSH obfuscated when not in use from the outside in this case by removing the iptables rule that allows access. Also, it's also defining the IP from the outside specifically "knocking" and not ALL IP's.
 
I still don't see that as secure as I would like it to be. WAN access will be available as long as the port is open (and/or hacked).
 
Opening the port on demand for a limited period of time is better than just leaving it open,

I keep mine closed 24/7 though. I can see the benefits for opening it though for certain things but, in general I agree on keeping it closed.

Also, in my "FW" I drop packets instead of giving a response / error to reduce exposure and frustrate would be attackers with the extended time out when they don't get a response.
 
How is knockd better than a VPN? I don't see that benefit.
It's not better than a VPN, it's worse. But I can't use a VPN client on my iPhone for unrelated reasons, so it's more convenient for me.

I still don't see that as secure as I would like it to be. WAN access will be available as long as the port is open (and/or hacked).
It's restricted to a specific IP address by iptables (the address of the requesting client). It's not open to the WAN in any real sense.

Also, in my "FW" I drop packets instead of giving a response / error to reduce exposure
Packets are still dropped by the incoming firewall. There's no way for an attacker to tell their packets are being scanned by knockd.

Knockd is not as safe as using a VPN for various reasons, but it makes port-scanning and brute-force attacks impractical.

If I get it working I'll post the solution here so you can see how it works and judge for yourselves how secure it really is :)
 
I know how it works... I just don't have a use for it personally.

It's a good tool to have when you need to access something remotely for whatever reason. It can be used to open other services as well. Just change the rule to whatever you need it to be other than SSH.
 

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top