Currently I'll be installing one AIX server behind a firewall, I just asked to open port 443 to use the SSH protocol to access this UNIX server.

I already changed the default ssh port to be 443 instead of 22 to log in and manage the server.

My question: is this enough to access and manage this server which is behind the firewall or is there any additional ports that should be included in the firewall rules?

  • 4
    Using 443 seems a bad move as that port will get barrages of dud requests because it's the standard https port. Probably not a big deal, but if the duds are going to be rejected anyway, you might as well reject them more efficiently by leaving 443 closed too and choosing something more arbitrary.
    – goldilocks
    Jul 19, 2013 at 0:26

3 Answers 3


This is security by obscurity, and you have chosen a port that in my experience is more often scanned. Just leave ssh on port 22 and get that opened. If you do plan to use security by obscurity, it is best not to pick a well known port. Scanning rates on them tends to be higher than other ports.

An alternative approach is to ssh into an already accessible system and connect from there. ssh can be programmed to automatically forward you to another system.

The only ports that need to be open to any network are those that are used. The list of outbound ports is usually different than inbound. You may want to retrieve patches from your vendor (often on port 80), while not allowing incoming HTTP requests.

Email should generally go to a relay server which will route it appropriately.

  • 1
    Port 22 is often scanned for the same reason, so recommending someone "leave it on 22" instead of using 443 is sort of meaningless -- the point about using a genuinely obscure port is better.
    – goldilocks
    Jul 19, 2013 at 0:22
  • 2
    @goldilocks When I was monitoring scanning on ports 22 and 443, it was 443 that was scanned more frequently. That is one of the reasons I said to leave in on 22. There are a number of ways to secure ssh, and I apply a stack of them. The preferable option, is to use an already open server as a gateway, but failing that security by obscurity generally isn't secure.
    – BillThor
    Jul 19, 2013 at 0:27
  • 1
    If ssh isn't secure to start with, there's probably not much you can do about it. WRT to 443 vs. 22, I agree 443 will get scanned more often, but my point was if you don't want or need to use the standard port, then don't -- "You might as well" just seems wishy-washy logic.
    – goldilocks
    Jul 19, 2013 at 0:36
  • @goldilocks It has been my experience that using an obscure port is seen as having secured the service. As a result not much thought goes into properly securing it. It is better to secure the service well, in which case an obscure port invites forgetting which obscure port it is on, or forgetting that it is running. As soon as your custom entry for secure-ssh gets dropped form /etc/services tools like netstat won't make open connections obvious.
    – BillThor
    Jul 19, 2013 at 0:56
  • Security by obscurity is a damn stupid policy anyway because it tends to lull you into a false sense of security "hurr hurr, they'll never guess this is here". Put ssh back on the port it belongs and set up fail2ban to deal with scanners and brute force attacks. Jul 19, 2013 at 6:27

If you're only interested in remoting into this server using SSH on port 443, then what you've done is sufficient.


to see what ports are being listened to (blocked by a firewall or otherwise)

as root, run

netstat -lp

This will list all open ports, and what applications are listening. then you can open the ports you need in your firewall.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .