Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I like to be able to ssh into my server (shocking, I know). The problem comes when I'm traveling, where I face a variety of firewalls in hotels and other institutions, having a variety of configurations, sometimes quite boneheaded.

I'd like to set up an sshd listening on a port that has a high probability of getting through this mess. Any suggestions?

The sshd currently listens on a nonstandard (but < 1024) port to avoid script kiddies knocking on the door. This port is frequently blocked, as is the other nonstandard port where my IMAP server lives.

I have services running on ports 25 and 80 but anything else is fair game. I was thinking 443 perhaps.

Much appreciated!


share|improve this question
Answering "What ports tend to be unfiltered" would help a lot of people I'd rather not help!! – Make it useful Keep it simple May 30 '10 at 21:13
@Sholom, security by obscurity is crap 99% of the time. In this case really all you have to do is take about 5 seconds to figure out what are the most common network protocols used on the Internet, and then assume those ports tend to be open for outbound access. If anyone has a firewall setup that assumes that an attacker is ignorant they probably deserve the problems they will get. – Zoredache May 31 '10 at 9:07
Thanks for all the suggestions, everyone -- this is very helpful! – Reid Jun 1 '10 at 0:00

I don't see why 443 shouldn't work.

However, i always question running sshd on a port other than 22. I haven't tried, myself, but is security via obscurity. It provides a mostly false sense of security. Many bots will take the time to port scan a host before attacking, or if 22 is closed. If 22 works on most firewalls, i'd just go back to using 22 and set up keypairs for auth, and disable password auth entirely (regardless if you move back to 22 or not)

443 sounds like a good choice, as it should be frequently open.

share|improve this answer
Thanks! On port 22 I get tons of failed login attempts, and on the other port I get none. You're correct that it's security by obscurity, but it definitely reduces the attention the daemon gets. I don't know if port 22 is commonly open through firewalls, but I'd doubt it since SSH is a UNIX thing (and thus somewhat obscure) and my impression is that a lot of these things are set up by ignorant drones. – Reid May 30 '10 at 20:43
I would think you would have less issues with 22, as others have pointed out problems for 443. 21 and 53 could be used, but i imagine 53 could cause problems, depending on their firewall. You could always run ssh on many ports and do testing on the road to see which has the greatest success. I know of no reason why multiple ssh servers on one host would expand your vulnerability. Also fail2ban, as mentioned can fw off ssh bots, but if password auth is disabled, you are at very minimal risk. You could also look into "port knocking" – cpbills May 30 '10 at 21:45
@Reid, SSH may have started life on UNIX but is certainly not constrained to it. As for it being "somewhat obscure", are you serious? – John Gardeniers May 31 '10 at 1:31
John, in the context of barely competent hotel firewall configurators, yes. I'm not talking about people who know what they're doing here. :) – Reid May 31 '10 at 23:57

443 is not a good idea. especially port 443 is dangereous solution, if you will not use it for SSL traffic. first of all, gmail or any big service provider will mark you as a public proxy server (they mark everything works on 443 without SSL enc.) Also some professional firewalls also block any traffic on 443 without SSL. because of proxy programs like ultrasurf or thor etc. maybe you can take it back to 23 or leave it on 22. if you don't like bruteforcers on sshd. i can advice you to use fail2ban it's a perfect solution to protect sshd, also ftp servers etc.

share|improve this answer
+1 on fail2ban. – Sean Edwards May 30 '10 at 20:48
OK but is port 22 likely to get through? I'd like it to work even in the face of seriously incompetent firewall administration, that is unlikely to know about SSH. – Reid May 30 '10 at 21:04
hmm.. what about 21 ? it's a common port as 80. i don't think it will be blocked too. – risyasin May 30 '10 at 21:16
I am a bit confused about what you mean when you say 443 is dangerous? Can you provide a link for this? I know of a pretty large number of VPNs and other services that listen on this port. – Zoredache May 31 '10 at 8:59
i've searched for a revelant document for that kind of dangereous note but nothing found. Last year my 2 production servers' ip addresses were blocked just because they were marked as free public proxy (this was written on block reason: Non-ssl connection accepted on port 443). i dont remember the RBL's names. but if i find my mails for explanation. i will post here. A note: i was using that port for remote SSH tunneling while it was not necessary for that time. BTW most of VPN's works with SSL or uses any other encryption way, in my guess this keeps them of being marked. – risyasin May 31 '10 at 14:00

I'd say 443 would be a good port, though be aware that some firewalls may do content inspection to make sure that the port 443 traffic is actually https. There are also some weird locations where they don't like encrypted traffic, so deny port 443.

Depending on the setup, port 53 may be ok - if they haven't restricted outgoing traffic to only their own dns servers that is.

It may also be considering whether you could use a spare ip address. You don't necessarily have to have your web server listening on every ip address your server owns, in which case you could just use port 80 which is the least likely to be blocked ip.

Then again, it's probably not wise putting your ssh server on a well-known port when what you're doing is trying to make it obscure. And there may be inline proxy servers on port 80 and 443 which stop you doing this.

share|improve this answer

I support a VPN for several users who take their systems to lots restrictive of networks. In my experience there is no single port you can listen on that will work 100% of the time. If you want highly available connectivity you probably need to setup your system to accept connections on many ports.

Just setup SSH to listen on some port and then use NAT to make it available on other ports.

Since you mentioned port 80 is in use. If you have apache running on port 80, you could even set it up as a proxy. But please make sure you take the time to understand how to setup access correctly so you that you don't become an open proxy.

Unfortunately if you really want your system to be able to be access from restrictive networks you are likely to have lots of scanning. The same protocols that are commonly allow through firewalls are the ones that are commonly used and scanned for. Setup something like denyhosts or fail2ban so your system will lock people out.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.