User account periodically fails to login with correct password

It looks like I actually have several ssh keys in my /etc/ssh/ directory.

ls /etc/ssh/ gives

ssh_config        ssh_host_ecdsa_key      ssh_host_rsa_key
ssh_host_dsa_key  ssh_host_ed25519_key

I will admit I am brand new to ssh. I got it merely working so I could manage my computer remotely but I am not sure if I am doing it right or not. I plan to dive in and learn it better soon.

If you don’t recognize the IP address - I am guessing - your ssh runs on default port 22 and you have allowed incoming traffic in firewall/router?

If so - I recommend to close it - and if you need external access then you should open a non default port e.g. 63000 and map the port to your internal port 22 on the target system.

Interesting. So you think this may be an external attack?

No - that is not what I am saying - because I don’t know how you have configured your network.

I am merely guessing and based on my guessing I come up with suggestions which may guide you in the right direction.

One suggestion is to look into your configurations to avoid potential scanning from outside and to avoid potential issues caused by scanning from outside your network.

All those messages are a clear sign of a bruteforce password attack on your root account - and depending on the complexity of your password it could be a matter of time before they guess it - and then your system are owned and not by you.

Protecting against brute force attacks

Brute forcing is a simple concept: one continuously tries to log in to a webpage or server log-in prompt like SSH with a high number of random username and password combinations. - OpenSSH - ArchWiki

If it should happen - there is no other way than reinstalling your system - and learn from it.

Thanks for this. I have installed ufw and configured it to allow a high number port for ssh then reconfigured sshd_config to use that port and it appears to be working.

It may be then that I was getting locked out of my account legitimately because attackers were trying to brute force in. In that case, it would not be a faillock problem but faillock actually doing its job to protect.


Running port scan on remote systems and brute-forcing passwords is a lucrative business. Only shady VPS providers allow their users to run port scanning from the rented server. Most VPS providers has - as a part of the agreement - a clause that such activity is banned and if caught it results in an immediate take-down - no refunds.

Of course there can be legitimate use of it - e.g. as a part of a penetration - which is also a profitable business.

But done rest - check your logs from time to time - I run a system which I only occationally use from outside and I used the deception technique but they eventually found that port too.

So lesson number two - always keep an eye on your logs - no matter if its a web server or shell server and no matter if it is self-hosted or rented - always keep an eye on your logs.


I swept up two post targeting SSH from the archived forum and made them into one.

They are my notes on the steps I took to secure public SSH instances on VPS I had some fun with.

Since securing my ssh I have not seen this problem show up again. I’ll probably keep this open for a few more days and if it does not show up again, I think we might have our answer. Thanks linux-aarhus.

Marked as solved.

Looks like the problem is back and I only bought myself a few days before a botnet found the new port. There are different IP addresses in every attempt about every 30s even with my firewall on and on a unique port.

Look into fail2ban and other tools like crowdsec to auto ban IP with failed attempts.

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.