Repeated login attempts from china!

ℹ️ Support
11

I agree that changing the ssh port was for me the most changing step. Since I use some random WXYZ Port I never (an I mean never!) had an attack since at least half an year.

  • Just change the port forwarding in your router to forward from random outside port to 22 of your server. Then change the port in putty/kitty accordingly.
  • Alternatively change the listening port in your sshd_config and accordingly in router an putty/kitty.

Both extremely easy and effektiv against random attacks, that of course go on random ports, because they are most promising in random case :wink: .

Here the steps I did and wrote down how I switched to to key authentication for ssh:

  1. Download PuttyGen: https://the.earth.li/~sgtatham/putty/latest/x86/puttygen.exe
  2. Start puttygen.exe, choose 4096 bit key size (at least I would recommend that) and go Generate.
  3. You can also choose some pass phrase here. Without you could login without any password but as someone could potentially get your private key, I would always recommend to secure it further with a pass phase.
  4. After done Safe private key to some secure folder on your local (remote) system
  5. On your server system do “mkdir ~/.ssh” to create “.ssh” folder in your users home directory
  6. In this directory create file named authorized_keys (nano ~/.ssh/authorized_keys) and copy the shown public key from PuttyGen into this file.
  7. In Putty/Kitty go to Connection>SSH>Auth and choose the private key from your local system there.
  8. At last change on your server /etc/ssh/sshd_config

RSAAuthentication yes
PubkeyAuthentication yes

  1. Relog into your server and see if login with your key pair works as expected.
  2. If everything works fine, disable the possibility of user password login by choosing “PasswordAuthentication no” inside /etc/ssh/sshd_config.

Actually after that I would not see fail2ban as necessary one any more. But I also use it, why not… If the time zone is asked for, it only make sense that it needs the log-files time zone. fail2ban analyses the /var/log/auth.log for login failures to ban the related ip adress. So just see which time zone is used there by comparing your local time with the one used in the log for your last authentication. For ssh fail2ban then works out of the box.

  • Nextcloud has already an integrated brute force protection, so fail2ban would just double that. Anyway before I knew that, I also enabled fail2ban to secure owncloud/nextcloud logins by doing these steps:

nano /etc/fail2ban/filter.d/nextcloud.conf

[Definition]
failregex={“reqId”:“.“,“remoteAddr”:”.”,“app”:“core”,“message”:“Login failed: '.’ (Remote IP: ‘’)“,“level”:2,“time”:”.”}
ignoreregex =

cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

nano /etc/fail2ban/jail.local

…add to the end of the file
[nextcloud]
enabled = true
port = http,https
filter = nextcloud
maxretry = 3
bantime = 600
logpath = <path to nextcloud data folder>/nextcloud.log

Of course adjust maxretry and bantime to your needs.

service fail2ban restart