At the server level, I would first look over the contents of
tail -50 /var/log/auth.log
That'll give you an idea of who has logged in, or attempted to, and whether it was successful or not. If you don't recognize one of the users, see if they exist.
One a clean (freshly deployed) Ubuntu 16.04 Droplet, where no additional users have been added, the above file looks like:
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin
systemd-timesync:x:100:102:systemd Time Synchronization,,,:/run/systemd:/bin/false
systemd-network:x:101:103:systemd Network Management,,,:/run/systemd/netif:/bin/false
systemd-bus-proxy:x:103:105:systemd Bus Proxy,,,:/run/systemd:/bin/false
If you see someone you don't recognize and you're sure it's not a user that's associated with your site or services you're running, you can remove them using
userdel. Be careful there as if you delete a user that is associated with a service, it will fail.
Beyond the basics of checking logs and the current system users, run a root kit check using either
chrootkit. Using DenyHosts is also a pretty good option to block certain attempts at logging in, though as with any tool that can deny access, you need to be careful not to block and lock yourself out.
If you're not already, use SSH Keys over plain-text password authentication when accessing SSH. An RSA key with a bit size of 4096 bits or even 8192 is ideal, though you can also use ed25519 as well. You'd generate the key(s), download the private key (if you can't generate them locally) and make sure the public key is in your users
SSH Keys are the preferred way to login, though I would also advise making sure your key has a valid passphrase protecting it, otherwise key-based login can be as insecure as password-based login since there's no valid protection preventing someone from using your key(s) if they get ahold of them.
Once you have SSH Keys setup, completely disable password-based login.
Also server side, check permissions on files and directories. If any directories or files are using a
chmod of 777, fix it now. There's no reason to give such higher level access. Files should be at best using a
chmod of 644 and directories a
chmod of 755 (some may get by with 750).
On the WordPress side, check out WordFence:
Also check your theme files, plugins, etc -- make sure they are 100% up to date as well.