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 just set up remote ssh for the first time with openssh.

I was able to ssh into my server with putty using the following three settings:

  1. /etc/init.d/ssh restart

    # What ports, IPs and protocols we listen for
    Port 1234
  2. dd-wrt network control panel ( into the url of the browser)

    Application----Port From----Protocol----IP Address----Port to----Enable


  3. putty

    Host name (or IP address)----Port


Is there a reason I should use port 22 instead of 1234?

share|improve this question
You should check out this question:… – gWaldo Dec 27 '11 at 22:13
up vote 8 down vote accepted

First, well-known port numbers are "well-known". They eliminate some guess-work as to what port a given service is listening on.

Second, ports 1024 and below can only be opened by root. This gives an additional level of "trust" to these services. I.E., the service I'm connecting to on port 22 must be running (or have been started) as root. If a service is running on 1234, it could be any user that has access to the box that opened and started a "program-that-acts-like-SSHD-but-intercepts-passwords" program. (This assumes that there is no NAT or other redirections in place - see mmi's answer.)

Also agreed with a point made by mmi - I wouldn't unnecessarily run a program as root just to obtain the desired port number. If a program running as root were to be compromised, the entire system is then compromised. However, if a program is already running as root for other needs, may as well use the proper port number.

Some people will advise against using the well-known ports in an effort to "hide" common services that might be used for exploit attempts, but I consider this to be only "security by obscurity" - and advise against doing such.

share|improve this answer
Thanks man. What are the pitfalls of using another well-known port like 37 for ssh instead of 22 or an unassigned one? – user784637 Dec 27 '11 at 21:41
@LedZeppelin - you may run into conflicts with other services that expect that those port numbers will be available. I.E., port 37 is reserved for "time". You can review the complete list at… or . You should really only use unassigned port numbers if you're not going to use one that already fits your purpose. – ziesemer Dec 27 '11 at 21:54
The pitfall is that another service on your server might want to provide his service an that well known port. So IMHO-go ahead - you should know what is running on your server. – Nils Dec 27 '11 at 22:02
Did you mean 1234 rather than 1022? Last time I checked, 1022 < 1024. Also, I think a clearer wording would be "... ports 1024 and below can only be opened by root"; your current wording implies that root cannot open higher ports. – Keith Thompson Dec 27 '11 at 23:40
@KeithThompson - thanks for the catches. Answer updated appropriately. – ziesemer Dec 27 '11 at 23:46

It basically depends on how much you want to hide that service.

People (and bots scanning for security vulnerabilities) will assume SSH is running on port 22, HTTP is running on port 80, and so on. If a service is running on a non-standard port, it will be less easy to detect, but it will be more difficult to use for legitimate users.

  • HTTP running on port 80:
    • You can reach it using http://servername
    • It will be easily reachable by anyone pointing a web browser to it
  • HTTP running on port 8042:
    • You will need to type http://servername:8042 to reach it
    • It will not be easily detected as a web server

  • SSH running on port 22:
    • You can reach it by telling Putty (or any similar program) to connect to your server's hostname or IP address
    • It will be easily reachable by anyone pointing a SSH client to it
  • SSH running on port 2242:
    • You will need to tell your SSH client to use that custom port
    • It will not be easily detected as a SSH server

And so on...

share|improve this answer

There's a good reason to use 22 for ssh, avoid the necessity to learn how to configure or additional parameters to use in several clients, ssh, scp, git, rsync etc. And also avoid to change premade scripts written to assume the default port.

There's always subjective security gains changing a default port, but I think that should exist a good and uncircumventable reason to change a default behaviour.

share|improve this answer

Is there a reason I should use port 22 instead of 1234?

Because that's where the other 99% of SSH services listen and people will expect it to be so. Convention isn't a hard and fast rule but you'll find that most administrators expect to see SSH on port 22, HTTP on port 80 and so on. Unless you have a very good reason to deviate from the established convention - I suggest you don't.

Nine times out of ten, some one much smarter than you (or I) picked the default settings for a good reason and unless you have a better one why change it?

(It's really annoying to have to spend your first day on the job nmap-ing everything to try to figure out which "non-conventional" ports the previous admin/consultant/BOFH decided to run everything on).

share|improve this answer

I disagree at some point with ziesemer: These programs do NOT have necessarily to be run by root. And it is NOT recommended to run any network related service as root unless you need to do so. When someone is able to exploit your service he or she will gain root rights.

Besides, a NAT can translate port 80 from outside to any port in the LAN. Therefore you can run a service as non-root.

The main advantage of well-known ports (especially port 80): They are usually not blocked by firewalls (port filters). If you try to access your server from school it may fail, depending on the school's router configuration.

share|improve this answer
What @ziesemer was talking about was permissions restrictions in some operating systems that require root privileges (or are granted permissions through something like authbind or a number of other methods) to bind to ports <=1023. – Shane Madden Dec 27 '11 at 23:17
I know, but he says "This gives an additional level of "trust" to these services. I.E., the service I'm connecting to on port 22 must be running (or have been started) as root.". Thats IMHO a wrong conclusion. I know that you have to be root on UNIX systems, but NAT can destroy this "illusion" easily. – mmi Dec 27 '11 at 23:25
+1 for your answer as well. I think both viewpoints are valid - it all depends upon what is all being considered. Also to note - agreed to not run things as root if at all possible, but if necessary anyway, may as well use the proper port number then. – ziesemer Dec 27 '11 at 23:48

You can use any port you like. Use of port 22 for ssh is conventional, and you'll find many firewalls, ssh clients and daemons default to this for convenience.

The better question should be "why shouldn't I use port 22?". There's some debatable security benefits to doing so, but I've never personally been convinced by them.

share|improve this answer
and of course sometimes NAT is involved at the edge, but I agree with you, keep the real host on the known port. – SpacemanSpiff Dec 27 '11 at 21:44

Your Answer


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

Not the answer you're looking for? Browse other questions tagged or ask your own question.