By coincidence I looked at my servers ssh log (/var/log/auth.log) and I noticed that someone is constantly trying to gain access:

Sep  7 13:03:45 virt01 sshd[14674]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=  user=root
Sep  7 13:03:48 virt01 sshd[14674]: Failed password for root from port 13423 ssh2
Sep  7 13:03:52 virt01 sshd[14674]: message repeated 2 times: [ Failed password for root from port 13423 ssh2]
Sep  7 13:03:52 virt01 sshd[14674]: Received disconnect from 11:  [preauth]

This happens a few times every minute, and has been going on for a long time without me knowing about it.

Question Should I be concerned about this, if yes: What should I do about it?


4 Answers 4


Unfortuntately, this is absolutely normal and something every SSH server experiences. Welcome to the internet.

As long as you properly secure your server (e.g. keep it updated, allow only key-based login, disable root SSH access), this shouldn't be a problem, but you can limit this even further with something like fail2ban and other approaches like IP whitelisting, changing ports and stuff like that where possible and appropriate.

  • 5
    Yes, it's business-as-usual. The best thing I've found to limit this spam in my logs is changing the SSH port. Other measures are probably helpful for security, like ensuring that root SSH logins are disabled, minimizing the number of people who can log into the server, and ensuring they choose good passwords. If it's just you, and you choose good passwords, then you're fine: they typically just try common username/password combos. Ideally, though, disable password auth and just use ssh keys. Then the spam will stop completely. Sep 7, 2016 at 14:34
  • 2
    I was truly surprised how much brute-forcing I got on my Raspberry Pi after I set it up with a DDNS and forwarded a port to it... It's like every single person on a busy street trying to see if their key works on your car. Sep 7, 2016 at 19:14
  • 1
    fail2ban is an essential tool for any server you have with a public or natted IP address. My network has also been targeted recently by this address, and after a couple days, I began to see other traffic, so I used iptables to block the entire /24. You can do the same with iptables -A INPUT -s -j REJECT
    – Rache
    Sep 7, 2016 at 20:39
  • 1
    log-based banning packages have the downside that any service that can log to syslog or use /dev/log can block anyone from using SSH. Using something like Suricata or Snort might be overkill for just 1 server, but if you have a network to protect, an IDS/IPS system isn't exactly just a luxury. Sep 7, 2016 at 21:55
  1. Block the IP using your firewall (iptables or whatever your service provides). Yes, they might change IPs, but make them do the work
  2. If you have an external firewall (i.e. AWS console lets you set access rules via a web page) consider limiting port 22 to JUST your IP. No need to fiddle with fail2ban in this case
  3. As mentioned in the comments, switch to key-based authentication and turn off password authentication
  4. Disable root logins. Add this to /etc/ssh/sshd_config

    PermitRootLogin no

    Just let them hammer away at root all they want. They'll never get in that way then.

  • 1
    "make them do the work". But you're doing just as much work as them in this scenario and possibly more. This is a losing scenario.
    – user247175
    Sep 7, 2016 at 16:31
  • @DoritoStyle So... don't block someone who's hammering your server with requests? That makes no sense. I've had several low-key attacks executed from a single IP. Won't save you from DDOS but that's outside the scope here
    – Machavity
    Sep 7, 2016 at 16:55
  • 1
    If you get more than a dozen attacks from unique IPs throughout the day you'll quickly end up spending a major chunk of each day blocking IPs. Something like fail2ban does this automatically and and is much better (That would be an excellent edit to your answer). Also, if it's only a few SSH requests then it shouldn't affect performance unless it escalates to DDOS levels. In any case, i'm happy to start a chatroom for further discussion.
    – user247175
    Sep 7, 2016 at 19:06

In addition to securing server as Sven points out, one of the best things to do (especially if ssh is therej ust for you, the admin) is just change sshd port away from default 22.

Not only is it simple (especially when you put new port in your ~/.ssh/config so you don't have to type it everytime) and it will stop 99% of those automated scans so you won't even see them, but it will also help somewhat even if some 0-day ssh vulnerability is discovered to give you more time, or you key is leaked etc.

  • 3
    Security through obscurity isn't. All you accomplish is forcing people who have a legitimate need to connect to your server via SSH/SFTP to use a non-standard port, which may require them to ask their InfoSec team to approve a firewall rule allowing that connection. Stop making my job more difficult to create the false illusion of improved security. Sep 7, 2016 at 15:23
  • 10
    @MontyHarder Wikipedia defines security through obscurity as "the reliance on the secrecy of the design or implementation as the main method of providing security.". In contrast this method actually uses the port as a small additional secret. Obviously this has costs (inconvenience) versus little benefit assuming a secure ssh server. However, I do follow the argument of a critical 0-day ssh vulnerability. There are many much less effective, more annoying snake-oil solutions widely accepted...
    – Zulan
    Sep 7, 2016 at 15:37
  • 1
    Change the ports and you'll get extra port scans instead of SSH login attempts. Sep 7, 2016 at 15:56
  • 2
    @MontyHarder It's not even about "security through obscurity". If I run my server on a non-standard port I simply reduce the script-kiddie noise which makes it easier to see real targeted attacks. Sep 7, 2016 at 18:09
  • 1
    @DmitryGrigoryev if you are targeted specifically, yes. But 99% are automated probes, who won't bother (they can try tens of thousands other servers instead of focusing on your ONE - it is just not cost effective). And if they have to resort to port scanning, you can autodetect and autoblock them so much easier before they have a chance to attack ssh or other nondefault-port service (via portsentry and friends). Sep 8, 2016 at 21:52

This pretty normal behavior. I get several thousand of those each day, and I assume even that is minuscule compared to what large companies face.

But do you need to worry?

  • Have you installed fail2ban?
  • Have you disabled root ssh login?
  • Have you blocked the user www-data from ssh login?
  • (optional) Have you disabled password based login in favor of public key login?
  • (optional) Have you changed the SSH Port from 22 to something else?
  • (optional) Have you added a TOTP pam module for login?

If yes, then you don't need to worry. Those attacks are usually dictionary based attacks on common unix user names. For example, I frequently see those "users" try to login:

  • root
  • www-data
  • test
  • admin

I really recommend installing fail2ban, as it will rate-limit any user trying to log in based on their ip, that alone should filter out most of the malicious traffic. Contrary to what others say, I am not a proponent of ip based blocking. That seems like a very coarse solution to a very fine problem. Also, those attackers usually control multiple ips, so even if you block several (or even several ip blocks), there is no guarantee you'll block them all. Fail2ban however is very flexible for those scenarios.

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