ssh/sftp (optware) and iptables config to allow wan access?

3 posts / 0 new
Last post
Skyler
Skyler's picture
ssh/sftp (optware) and iptables config to allow wan access?

I'm running kong mod of dd-wrt (don't have the version in front of me but it's recent).  I installed optware (with frater's scripts) on my usb hard drive that is connected to my wnr3500l.  It took a while but I finally got sftp and ssh working with dropbear and optware, including using rsa public/private keyfiles to connect.  Yay!

The problem is that I can only connect to it inside my LAN and I need to get to the files from the internet, too.  I disabled the ssh built into the interface since I don't want my optware dropbear and the built-in one duking it out for control.  I'm using dyndns to resolve the domain name to the ip of my router.

At this point I'm pulling my hair out after all day trying to figure it out. I can't get anything to work the way I expect with iptables. A lot of the information I'm finding seems to be out of date or wrong.

I'm seeing solutions like creating /etc/firewall and adding  -A INPUT -p tcp --dport 22 -j ACCEPT .

Or editing /etc/firewall.user .   Or typing iptables commands like:

iptables -t nat -A prerouting_wan -p tcp --dport 22 -j ACCEPT

iptables        -A input_wan      -p tcp --dport 22 -j ACCEPT

When I try these things it never seems to make much difference.  My dropbear is running on a port like 2285 (and I changed the port numbers in these commands to mine). I don't really care too much which port it runs on as long as I can connect to it, but I still can't.

So what command should I use to allow WAN access?  What file do I need to modify so that my changes stay in place after a router reboot?  How do I restart the firewall (the script wasn't in the init.d folder like many people said).

Any help is very appreciated since there is a lot of conflicting information and I can't get this working.

Skyler
Skyler's picture
Ok, after looking around and

Ok, after looking around and reading a lot more I figured out how to open a port for ssh/sftp in optware in a reasonable way and keep it working on reboot of the router.

First off, this page gave me clear and useful information about iptables without being full of junk like most descriptions (or assuming you know already).

Next, a dd-wrt page on preventing brute force attacks had some good examples. The simplified example I used just for ssh/sftp on example port 2277 is:

iptables -N rate_limit
iptables -F rate_limit
iptables -A rate_limit -p tcp --dport 2277 -m limit --limit 3/min --limit-burst 3 -j ACCEPT
iptables -A rate_limit -p tcp -j REJECT --reject-with tcp-reset
iptables -A rate_limit -j DROP
iptables -I INPUT -p tcp --dport 2277 -m state --state NEW -j rate_limit

This will prevent repeated failed login attempts to 3 per minute before dropping further connection attempts.

Now, I couldn't figure what file to put this stuff in so it survived a reboot but finally figured out I could do it in the dd-wrt web UI by going to Administration > Commands and pasting the commands in the box and then clicking *save firewall*.

I hope this helps someone else out there since it took a long while to figure out.

Skyler
Skyler's picture
I ran into another problem

I ran into another problem with the authorized_keys disappearing with every router reboot (ick). This is a problem because the /tmp/root/.ssh folder is stored in router memory it seems. In case it's helpful, this is how I fixed the problem.

I added a folder:

/opt/users/root/.ssh/

and copied any files I needed to it (in my case, only authorized_keys). Be sure the permissions are set right. Maybe "chmod 600 authorized_keys".

Then I edited the dropbear startup script:

vi /opt/etc/init.d/S51dropbear

Within the if block I added a line to copy the .ssh configurations from my /opt/users/root/.ssh/ folder to the /tmp/root/.ssh folder. It looks like this now:

if [ -n "$DROPBEAR_PORT" ]; then
    cp /opt/users/root/.ssh/* /tmp/root/.ssh
    /opt/sbin/dropbear -p $DROPBEAR_PORT -d $DROPBEAR_DSS -r $DROPBEAR_RSA
else
...

This was an annoying problem, too.