Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I've noticed lot of admins change default ssh port. Is there any rational reason to do so?

share|improve this question
FWIW, the exact same question on Server Fault: serverfault.com/questions/189282/why-change-default-ssh-port. –  Jonik Oct 10 '10 at 18:27

3 Answers 3

up vote 24 down vote accepted

The most likely reason is to make it harder for people randomly trying to brute force any SSH login they can find. My internet-facing machine uses the default SSH port, and my logs used to be filled with stuff like this (excerpted from an actual log file):

sshd[16359]: Invalid user test from
sshd[16428]: Invalid user oracle from
sshd[16496]: Invalid user backup from
sshd[16556]: Invalid user ftpuser from
sshd[16612]: Invalid user nagios from
sshd[16649]: Invalid user student from
sshd[16689]: Invalid user tomcat from
sshd[16713]: Invalid user test1 from
sshd[16742]: Invalid user test from
sshd[16746]: Invalid user cyrus from
sshd[16774]: Invalid user temp from
sshd[16790]: Invalid user postgres from
sshd[16806]: Invalid user samba from

These days I use DenyHosts to block IPs that fail to authenticate too many times, but it's probably just as easy to just switch ports; virtually all brute force attacks of this kind aren't going to bother scanning to see if your sshd is listening on another port, they'll just assume you're not running one and move on

share|improve this answer

No, it's a security by obscurity tactic.

If your sshd setup is not fit enough to face dumb script kiddies only trying port 22, you have a problem anyway.

A more rational reaction would be:

  • make sure that your users are using good passwords which are hard to guess/brute-force
  • disable password-authentication (at least for important accounts) and just use public-key-authentication
  • watch out for ssh-security issues and upgrades

Some people may also be annoyed by the noise sshd writes into the system log, e.g.:

Jan 02 21:24:24 example.org sshd[28396]: Invalid user guest from
Jan 02 21:24:24 example.org sshd[28396]: input_userauth_request: invalid user guest [preauth]
Jan 02 21:24:24 example.org sshd[28396]: error: Received disconnect from 3: com.jcraft.jsch.JSchException: Auth fail [preauth]
Jan 02 21:24:24 example.org sshd[28398]: Invalid user ubnt from
Jan 02 21:24:24 example.org sshd[28398]: input_userauth_request: invalid user ubnt [preauth]
Jan 02 21:24:24 example.org sshd[28398]: error: Received disconnect from 3: com.jcraft.jsch.JSchException: Auth fail [preauth

It might be then tempting to obscure the sshd port or to use an automatic blocking solution (like DenyHosts, Fail2ban or BlockHosts) in order to increase the signal-to-noise ratio again.

But better alternatives do exist. For example, you can configure your syslog daemon such that the sshd log noise is only written to - say - /var/log/sshd-attempts.log and the signal (i.e. the remaining sshd log messages) is written to /var/log/messages etc. as before.

The deployment of automatic blocking tools should be considered carefully because adding more complexity to security relevant systems means also increasing the risk of exploitation. And indeed, over the years, there are several DoS vulnerability reports for each DenyHosts, Fail2ban and BlockHosts.

share|improve this answer
I don't really agree with that "it's security by obscurity" I think that, that answer is a common fallacy in this case. @Michael's reasoning generally show's a better reason to have it elsewhere. It's mostly just to get rid of all the scripted botted attacks. Doesn't necessarily mean you're afraid of them, or consider it effective against a determined attacker. I know I never worried they'd actually get in. but all the log cruft was annoying. –  xenoterracide Oct 10 '10 at 21:20
@xenoterracide: If you are only concerned about the readability of your log files then there are other better alternatives to exclude the noise instead of changing the port as an obscurity tactic, which was the question. Regarding the IP blocking, which was not part of the question: Please note that adding more complexity to security relevant systems means also increasing the risk of exploitation. Consider for example seclists.org/fulldisclosure/2007/Jun/121 ossec.net/main/attacking-log-analysis-tools . Yes, DenyHosts was affected by this. –  maxschlepzig Oct 10 '10 at 21:49
There's more than just readability in mind. A properly documented port change is not security by obscurity. –  xenoterracide Oct 11 '10 at 13:44

Changing the SSH port is mostly security theater. It gives you a fuzzy feeling of having done something. You've hidden the SSH port under the doormat.

If you run an SSH server on the Internet, you'll see a lot of failed login attempts in your logs, from bots that are looking for stupidly weak passwords, weak keys and known exploits in server older versions. The failed attempts are just that: failed attempts. As far as evaluating how vulnerable you are, they are completely irrelevant. What you need to worry about is the successful intrusion attempts, and you won't see those in your logs.

Changing the default port will reduce the number of hits by such bots, but that only foils the least sophisticated attackers who are stopped by any decent security (security updates applied regularly, reasonably strong passwords or disabled password authentication). The only advantage is reducing the volume of logs. If that is an issue, consider something like Denyhosts or Fail2ban to limit the connection rate instead, it'll also do your bandwidth good.

Changing the default port has a major disadvantage: it makes you less likely to be able to log in from behind a firewall. Firewalls are more likely to let services through on their default port than on some random other port. If you aren't running an HTTPS server, consider making SSH listen on port 443 as well (or redirect incoming TCP requests from port 443 to port 22), as some firewalls allow traffic that they can't decode on port 443 because it looks like HTTPS.

share|improve this answer

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.