Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

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 have a server with ubuntu. I do work on it over SSH. I had a problem with brute force attempts over port 22. I changed the port and I assumed it fixed the brute force problem. Am I right or are the attempts on another port just not logged anymore in /var/log/auth.log?

share|improve this question

migrated from Aug 18 '09 at 17:06

This question came from our site for professional and enthusiast programmers.

Migrated in 3..2.. – Mike B Aug 18 '09 at 17:06

11 Answers 11

To avoid bruteforce attacks here is what i do:

  • Change ssh port
  • Install denyhosts
  • Limit number of connections per second on ssh port
  • Use only keybased no root ssh, instead use sashroot if needed, or console login
  • port knocking to open ssh port in some case


  • create a canssh group, add the people whom i wanna give ssh to this, add "AllowGroups canssh" to sshd_config. And set DENY_THRESHOLD_(IN)VALID*/ROOT in denyhosts to 1 e.g. one wrong ssh as root or (in)valid user, and your ip is blocked, add my ips to hosts.allow, create ~/.ssh/config and define which ssh-key to use for which server and create aliases say:
    • alias ssyc = 'ssh -i yahoo-com.identity.rsa'



  • Use logwatch to email you important logs...


And as mentioned earlier, in case of bot attacks, they try 22 by default, so i guess you aren't being targeted any more.


share|improve this answer
Cool. Do you have a link for the place you got your tin hat? – theotherreceive Aug 19 '09 at 3:48
nah, just somethings i picked from here and there in the years since i started nix. Don't have a specific resource, remain on irc (error404notfound on freenode), have subscribed to some of blogs and sites which deal with security, linux and such. Plus for everything i do a google first like: "Secure ssh linux OR distroname" – Shoaibi Aug 19 '09 at 7:03
thinking to write my own personal "Linux server pocket reference guide" in one of these days that will contain the common tricks, tweaks and hacks that i do with linux servers. – Shoaibi Aug 19 '09 at 7:06

No, all attempts will be logged to /var/log/auth.log regardless of the port that sshd is listening on.

share|improve this answer

The attempts are probably just generated by bots trying to get easy access. Unless someone is specifically targeting your system, they won't even look on a different port.

Security by obscurity.

share|improve this answer

As long as you didn't change anything but the port number, the logging won't be affected.

share|improve this answer

No automated attack is going to try other ports, as there are plenty of SSH servers on 22 to try.

As long as all you are relying on the port migration to do is reduce the log spam, then that's fine, but you shouldn't rely on it for any real security.

I've done the same thing to provide the same benefit of preventing the log entries.

share|improve this answer

For added hilarity (and if you have some time to kill), implement Port Knocking:

share|improve this answer
That's great! I'd never heard of that before. Somewhat security by obscurity though... – Luke Aug 20 '09 at 2:44

As pointed out by others changing the port will stop the annoying log spam and extra traffic, but is not a security measure as obscurity does not equal security.

A good idea might be to audit the passwords on your system with a password cracker, and/or set new passwords using a methodology like the one described here by Redhat's documentation:

share|improve this answer
A better Idea is to use keys, instead of passwords. – Brad Gilbert Aug 19 '09 at 3:21
+1 for obscurity is not security – theotherreceive Aug 19 '09 at 3:44

Your logging shouldn't be different because of a port change.

You may also want to look at setting up denyhosts or fail2ban.

share|improve this answer
aye, fail2ban is more than enough to have the script kiddies go away, and probably the best solution for this problem. – theotherreceive Aug 19 '09 at 3:45

Take a look at here - 20 OpenSSH best security tips:

share|improve this answer

You can rate-limit brute force attak with iptables:

sudo iptables -A INPUT -p tcp -m tcp --dport 22 -m recent --update --seconds 60 --hitcount 3 --rttl --name SSH --rsource -j LOG --log-prefix "ATTACK SSH BRUTE FORCE "
sudo iptables -A INPUT -p tcp -m tcp --dport 22 -m recent --update --seconds 60 --hitcount 3 --rttl --name SSH --rsource -j DROP
sudo iptables -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name SSH --rsource -j ACCEPT

share|improve this answer

If you must have the login connection, you may also limit the allowed users to connect by editing /etc/pam.d/ssh and add the line :

auth required item=user sense=allow file=/etc/sshusers_allowed onerr=fail

Create a file /etc/sshusers_allowed and put all allowed users line by line.

Maybe a ssh restart, not sure.

share|improve this answer
Please use the "code" or "blockquote" tags to format your answer. – Dennis Williamson Aug 18 '09 at 18:08
Done, thanks to point me that – Dom Aug 18 '09 at 18:45
You can also add groups to the /etc/ssh/sshd_config file under AllowedGroups – Rory Aug 19 '09 at 13:16

Your Answer


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