How can I protect SSH?

I check /var/log/secure and I have these logs:

Jul  9 13:02:56 localhost sshd[30624]: Invalid user admin from 223.196.172.1 port 37566
Jul  9 13:02:57 localhost sshd[30624]: Connection closed by invalid user admin 223.196.172.1    port 37566 [preauth]
Jul  9 13:03:05 localhost sshd[30626]: Invalid user admin from 223.196.174.150 port 61445
Jul  9 13:03:05 localhost sshd[30626]: Connection closed by invalid user admin 223.196.174.150 port 61445 [preauth]
Jul  9 13:03:16 localhost sshd[30628]: Invalid user admin from 223.196.169.37 port 62329
Jul  9 13:03:24 localhost sshd[30628]: Connection closed by invalid user admin 223.196.169.37 port 62329 [preauth]
Jul  9 13:03:29 localhost sshd[30630]: Invalid user admin from 223.196.169.37 port 64099
Jul  9 13:03:30 localhost sshd[30630]: Connection closed by invalid user admin 223.196.169.37 port 64099 [preauth]
Jul  9 13:03:45 localhost sshd[30632]: Invalid user admin from 223.196.174.150 port 22816
Jul  9 13:03:46 localhost sshd[30632]: Connection closed by invalid user admin 223.196.174.150 port 22816 [preauth]
Jul  9 13:06:17 localhost sshd[30637]: Invalid user admin from 223.196.168.33 port 33176
Jul  9 13:06:17 localhost sshd[30637]: Connection closed by invalid user admin 223.196.168.33 port 33176 [preauth]
Jul  9 13:07:09 localhost sshd[30639]: Invalid user admin from 223.196.173.152 port 61780
Jul  9 13:07:25 localhost sshd[30641]: Invalid user admin from 223.196.168.33 port 54200
Jul  9 13:07:26 localhost sshd[30641]: Connection closed by invalid user admin 223.196.168.33 port 54200 [preauth]
...

It seems someone tries to log in by SSH. I disable login by root user and enable public/private key login, but is this a DDoS attack? And does it use RAM/CPU?

What should I do?

As @Simon Richter mentionned, that's just internet background noise and you shouldn't worry. A few things you have to make sure are that:

• You don't allow password-based authentication but only public key auth
• You can disable unsafe and poorly designed ciphers, remove small Diffie-Hellman moduli and other cryptographic improvements
• You can install fail2ban

Changing the port will make the problem go away, but it's security through obscurity and it can create the illusion of safety while providing none.

Here are a few other recommendations surrounding SSH, as well as counter arguments to mainstream "best practices" arguments.

Are you in India? All those IP addresses listed are in the block:

223.196.160.0 - 223.196.191.255   

which according to the WHOIS database is allocated to

descr:   Andhra Pradesh State FiberNet Limited
address: 10-2-1,III Floor, FDC Complex,AC Guards,Hyderabad,Andhra Pradesh-500028

One short-term solution is to block the whole block 223.196.160.0/19 at the firewall, but that is micromanaging IP addresses and becomes an uphill battle.

Instead you could deny ALL ssh except for the source IPs that you know are trusted. Simply take care to not lock yourself out of your own host. If you don't have a static IP, you can permit a block, or possibly look at running a VPN server on the host.

Or if you don't need to permit SSH connections from the internet, just deny them and only reenable when its required.

1. Use only key-based auth. Many bots only attack password-based systems. Using password-based auth is bad idea anyway.
2. Use https://www.sshguard.net/ : it blocks IPs after a couple of failed logins.
3. Use random port (not 22), it will stop some bots.
4. Make sure your system doesn't permit root login
5. If you only login from your home, consider only open SSH for your IP/ISP or country.

Here is a simple script I wrote to block all unauthorized attempts at logging into my dev server.

#!/bin/bash

ban=$HOME/banned.txt
b_log=/var/log/banned.log

log () {
cat $ban | uniq >>  $b_log
}

l_log () {
lastb | awk '{ print $3 }' | sed -r '/(Mon|Tue|Wed|Thu|Fri|Sat|Sun|boot|tty2)/d' | sort | sed '/^$/d' | uniq | tee $ban
}

drop () {
for x in $(cat $ban); do iptables -A INPUT -s $x -j DROP; done
}

l_log
drop
log
rm -f $ban
echo > /var/log/btmp
iptables-save

If you set the script to run via cron every minute, it will dramatically reduce the noise in your logs and block offending IPs giving them just 1 minute to attempt their brute force before being blocked.

It would be a good idea to insert your IP and any other IPs you access your server with to your firewall iptables -I INPUT -s xxx.xx.xxx.xx -j ACCEPT

A log of all IPs banned will be generated.

1. Change your sshd listening port

As simple as it sounds, changing your port from the default 22 to a custom value (e.g. 2200) on a public IP could reduce the number of port scans from thousands a day to a few dozen. For a tutorial see here.

That being said, while this does reduce the annoyance of being port-scanned, it DOES NOT provide real security. "Security by obscurity" is a myth and nothing more.

2. Use public key login and disable password login

Bots might guess a password right, but they're never going to guess a private key right. As long as you use modern algorithms and don't leak your key accidentally. For a tutorial see here.

Note that this does mean you will no longer be able to login from any random machine, unless you carry the key with you (which you need to secure via some other way).

3. Use fail2ban

If they fail 5 times, ban them from trying again for a day or something. That'll show them. Very effective against brute force attempts. For a tutorial see here.

The downside is that you might lock yourself out if you've got wobbly fingers one day (drunk or something, I don't know).

4. Pre-ban a list of IPs known for abusive use

Sources like AbuseIPDB maintain big lists of known malicious IPs accessible via API. You will need an API key to use it, but you can register a free account easily enough. Pull the list and use something like iptables to ban those known IPs in bulk. Set up a cron job to automate it periodically for best effect. Here's a very simple script I wrote (and am personally using) to do just that. Feel free to use it as reference, but DON'T USE IT IN PRODUCTION.

In my personal experience, this method is equally effective (if not more so) as method #3.

Personally, I use all 4 methods listed above, and my VPS might get one or two malicious login attempts in my security log at most, in a bad month. Here's the interception history of iptables via method #4:

$ abip-hist
Chain abip-ban (1 references)
 pkts bytes target     prot opt in     out     source               destination
  362 14480 DROP       all  --  *      *       45.143.200.6         0.0.0.0/0
  307 12280 DROP       all  --  *      *       185.156.73.104       0.0.0.0/0
  288 12672 DROP       all  --  *      *       212.133.164.75       0.0.0.0/0
  277 19911 DROP       all  --  *      *       146.88.240.4         0.0.0.0/0
  250 11000 DROP       all  --  *      *       212.133.164.14       0.0.0.0/0
  230  9200 DROP       all  --  *      *       45.146.164.213       0.0.0.0/0
  215  8600 DROP       all  --  *      *       185.156.73.67        0.0.0.0/0
  214  8560 DROP       all  --  *      *       5.188.206.18         0.0.0.0/0
  202  8080 DROP       all  --  *      *       193.27.228.63        0.0.0.0/0
  201  8040 DROP       all  --  *      *       193.27.228.64        0.0.0.0/0
  199  7960 DROP       all  --  *      *       193.27.228.59        0.0.0.0/0
  197  7880 DROP       all  --  *      *       193.27.228.65        0.0.0.0/0
  197  7880 DROP       all  --  *      *       193.27.228.61        0.0.0.0/0
  196  7840 DROP       all  --  *      *       45.135.232.119       0.0.0.0/0
  196  7840 DROP       all  --  *      *       193.27.228.60        0.0.0.0/0
  196  7840 DROP       all  --  *      *       193.27.228.58        0.0.0.0/0
  189  7560 DROP       all  --  *      *       45.146.165.149       0.0.0.0/0
  184  7360 DROP       all  --  *      *       45.155.205.247       0.0.0.0/0
  184  7360 DROP       all  --  *      *       195.54.160.228       0.0.0.0/0
  182  7280 DROP       all  --  *      *       45.143.203.12        0.0.0.0/0
  181  7240 DROP       all  --  *      *       45.141.84.57         0.0.0.0/0
  180  7200 DROP       all  --  *      *       45.135.232.85        0.0.0.0/0
  176  7040 DROP       all  --  *      *       45.146.165.148       0.0.0.0/0
...
this goes on for 1700 lines...

$ uptime
06:36:49 up 16 days, 15:24

As other answers mentioned, you don't need to worry to much about it, but if you do want to add another layer of security, you can try using port knocking.

The idea is to keep the ssh port closed, and only open it to ips, that perform a specific sequence of operation prior, something like:

syn port 1000
syn port 2000
syn port 3000
# ssh port is now open
ssh ...

can get more details here: https://www.rapid7.com/blog/post/2017/10/04/how-to-secure-ssh-server-using-port-knocking-on-ubuntu-linux/