ssh on port 443 [INACTIVE]

[lorenzo]

they're installing a new firebox firewall where I work. I'm not yet sure how locked down they will make the network, but I'm looking for a solution to my boredom before it gets to that point.

https port 443 will be open to the outside internet. can I set up brazilfw at my house to listen for ssh connections on port 443? I added Port 443 to /etc/ssh/sshd_config and added admin permission to the firewall for port 443. I saved everything and rebooted, but I can't get a connection on that port.

[bcthies]

The easiest way is to connect to the BrazilFW on the internal side and connect to port 8180. For example http://192.168.0.1:8180

After logging in as root and your password that you used when you set up, click on 'Administrative Config'. Change port from 22 to 443 and click submit on the button.
Then click 'Backup Now' on the column on the left.
Reboot and check it out by connecting to 443 from your secure shell client. (I use putty.exe on windows)

For direct editing select 1 from the main menu after logging in to the main console.
add these two lines to the bottom of your file

ENABLE_EXTERNAL_SSH='YES'
SSH_PORT='443'
<Control> Q to quit, 'Y' to save.
'w' to write to disk
'l' to logout.

This should do it.

Enjoy.

bcthies

[lorenzo]

I think I tried adding a second line for SSH_PORT='443' but it didn't work. could I do something like SSH_PORT='22,443' ? because I'd still like to have port 22 working also.

[bcthies]

Warning: I am not a BrazilFW expert! Make any of these changes at your own risk!
I have successfully gotten two (22 and 443) ports to work on my BrazilFW box.
Make a backup before doing this!


1 Edit the /etc/rc.d/rc.inet file.

Find the line

echo "Starting SSH daemon..."
if [ -z "$SSH_PORT" ] ; then SSH_PORT=22 ; fi

directly under it, add the line
if [ -z "$SSH_PORT2" ] ; then SSH_PORT2=443 ; fi

Find the line /usr/sbin/sshd -p $SSH_PORT

directly under it, add the line /usr/sbin/sshd -p $SSH_PORT2

<control> q to quit, 'y to save.

2. Edit the /etc/rc.d/rc.firewall file

Find the line

if [ -z "$SSH_PORT" ] ; then SSH_PORT=22 ; fi

Directly under it, add the line:

if [ -z "$SSH_PORT2" ] ; then SSH_PORT2=443 ; fi

find the line
iptables -A remote-admin -i $IF_INET -p tcp --sport 1024: --dport $SSH_PORT -

Directly under it, add the line:
iptables -A remote-admin -i $IF_INET -p tcp --sport 1024: --dport $SSH_PORT2

<control> q Y to save.

edit the /etc/coyote/coyote.conf
remove any references to SSH_PORT
<control> q Y to save.

menu <to go back to the menu>

w <to write the file>

reboot and test.

[bobbb]

There is an alternative with less changes. No nice pretty way though. The sshd program specifies the port(s) as -p 22 443

Leave the webadmin config as is and then as in the post above.

Step 1
Find the line: /usr/sbin/sshd -p $SSH_PORT
and change it to:

Código: Selecionar todos

/usr/sbin/sshd -p $SSH_PORT 443

You can't change the port in Webadmin to 22 443 because it breaks the iptables command.

Step 2 There seems to be a typo in the above instructions.
Find the line: iptables -A remote-admin -i $IF_INET -p tcp --sport 1024: --dport $SSH_PORT -j ACCEPT
and change it to:

Código: Selecionar todos

iptables -A remote-admin -i $IF_INET -p tcp --sport 1024: --dports $SSH_PORT,443 -j ACCEPT

I have not tested this.

[lorenzo]

is there something in the firewall or the port forward software that would prevent port 443 from being forwarded or accepted from the wan side? I never got my last problem working, but fortunately it wasn't needed. I can still connect to ssh on the default port from work. I am now working on a new project.

I'm writing a program with a built in web interface. it has a simple ssl https server built into it. it works locally, but I can't get it to work with a port forward in brazilfw forwarding to the computer on my lan.

[bobbb]

YES.

If you can connect to BFW from work, it means that in the Webadmin Administrative Config Enable External SSH Access is enabled and BFW will process the transactions locally so you cannot forward SSH packets but...

You should be able to forward another port like 4443 to any PC on the LAN as port 443. Then anyone can do it too.

OR

Use the method described here: BrazilFW Webadmin from the Internet
Now follow the instructions for Putty local port forwarding

To be even more secure you can use RSA public/private keys: Public Key encryption for BrazilFW SSH

[lorenzo]

so webadmin will grap any incoming ssl connections no matter what port they are on? it just acts like it never wants to connect to the port. sounds like a pain to get around this, but I'll have to find a way.

[bobbb]

so webadmin will grap any incoming ssl connections

Not really. Webadmin is a web server on BFW.

As it works it way on the TCP/IP stack, Linux decides to give the packet to the local PC because it is listening on port 443. The packet never goes to the FORWARD code.

See my previous post. We were both posting at the same time. The Webadmin from the Internet thing above is easy.

[lorenzo]

I'm still a little confused. let me explain a little better. webadmin ssl works fine on the default port 8181. what I want to do is a quick port forward to connect to another ssl server on my local lan and make it accessible from the outside world. I tried setting the port forward on port 443 and even tried adding an allow rule in the firewall, but it wont connect. I'm still trying to understand exactly how ssl works. my understanding is that it binds the certificate to the domain name, so ip's and port forwards shouldn't affect it, as long as the domain is pointing to the server with the certificate installed on it.

[lorenzo]

figured it out. I just thought of this, my isp is blocking the port! changed it to 8443 and it works. thanks for the help. back to my brain storming now. got more to figure out. :-)

[bobbb]

Ok I understand the confusion now.

connect to another ssl server on my local lan

This made it click. The whole time the title of the thread is ssh on port 443 but you were really talking SSL.

SSH is 22. I saw the numbers but it did not register.

[lorenzo]

lol, sorry about that. guess I should have been less lazy and started a new thread for it. at the time, the title sounded like it still fit the problem. should I continue the thread? I still have much reading and learning to do. here's what I'm doing:

I'm making an open source program to control automated home gardens. watering, lighting, webcam.. I expect people to have it set up on their computers all around the world. I'm trying to come up with the best way to offer a dynamic dns domain or subdomain to let them log into their own garden system securely over ssl. I think a self signed certificate for each system would probably be the best way to do it, but I've also been thinking about buying a wildcard certificate and have them all use a subdomain of my companies main domain and either have it point directly to their system or have it proxied. hope that's clear and understandable. it's a fun project, and I've learned a lot so far. brings all my favorite hobbies together into one project. programming, electronics, and nature. oh, and don't forget the good food. grab a fresh huge juicy tomato from the indoor garden and slap it on a sandwich or a burger. yum, I love computers.

[bobbb]

Interesting!

One thing to consider; the dynamic DNS thing has already been done and is offered by many for free so that gives you more time to concentrate on the application. I really would not put much time in that plus technically that part is irrelevant to your project. It is (should be) a separate project.

To start a self signed certificate is OK but later, if this rocks and rolls, signed by an authority sounds better.

So let's see, people go through their firewall, connect to their (your) app, and do their stuff. Most people have a router of some kind so it should be good.

Well good luck. See you on Sourceforge some day or Freshmeat.

[lorenzo]

thanks. I might post my code on one of those sites when it's ready, but I like having my own svn server for the development stage. I have a working prototype, but mass-producing the hardware will be a big challenge. I'll probably post schematics and plans on how to build it yourself, but that's no good for the general population. nothing exists on the market to fit the needs of the system. no one suggest X10, it really sucks for reliability. keep an eye out for me. it's a one of a kind app in the open source world.