-1

I switched all my servers to ssh publickey login and disabled password login about a week ago (root login IS still enabled). I also run Fail2ban and logwatch.

Why is there still login attempts showing up in the logs? I admit the number of attempts is down to low double digits, but shouldn’t there basically be none? Are there bots actually trying to brute force a key that makes no sense? Or my guess I have something configured incorrectly?

Serves are Ubuntu 18.04 and Debian 10 both up to date.

EDIT: For future reference this question pertains more to the logging of login attempts then the security there of.

6
  • 2
    Which logs, in particular, are you seeing? Even with pubkey auth required, you'll still see log messages for invalid users or preauth failed (for valid users) when auth without a key is tried.
    – gowenfawr
    Apr 7, 2021 at 18:29
  • 2
  • 3
    1) Disabling login does not mean that you can prevent login attempts. You cannot prohibit other people or bots to send IP packets to your server. 2) Fail2ban works based on analysis of made attempts. If an IP packet was sent from a new IP not covered by Fail2ban rules, traffic will be allowed. That's why new login attempts can still be possible.
    – mentallurg
    Apr 7, 2021 at 19:58
  • 2
    "and disabled password login" - how exactly did you do this. Please try to login with ssh -v ... and check what the lines debug1: Authentications that can continue: .... say, i.e. if they only show publickey or if they also list password. Apr 7, 2021 at 20:25
  • I'm confused. Changing login types does not prevent bots trying to log in. They will just give up a lot faster. And, as Steffen says, this is super easy to test: just try to log in with a password and see what the logs say.
    – schroeder
    Apr 8, 2021 at 7:51

1 Answer 1

3

It is very common to see login attempts in the logs. As long as you see the "publickey" message you are good to go.

For example, have a look, I just tried on my AWS instance which only has pubkey auth:

➜  ~ ssh heysecuritystack@x
heysecuritystack@x: Permission denied (publickey).

And this is how it looked on my logs:

Apr  8 07:37:25 ip-x sshd[128054]: Invalid user heysecuritystack from 192.168.2.2 port 43892
Apr  8 07:37:25 ip-x sshd[128054]: Connection closed by invalid user heysecuritystack x port 43892 [preauth]

PS: As a curious fact, I just had a look at the SSH logs and saw more than 20 login attempts in the last hour.

8
  • 1
    It's not (simply) a matter of being allowed or disallowed. A number of valuable IT professionals are sight impaired and cannot just read text from images by themselves. Apr 8, 2021 at 8:03
  • This makes perfect sense @usr-local-ΕΨΗΕΛΩΝ you provided a very valid point that I did not take into account before. Is there any resource where I could check the best format? For example I replaced the IP with a X but I would like to know if there are "best practices" on this field
    – borcho
    Apr 8, 2021 at 8:06
  • It's not about "not being allowed". It's easier to read, parse, and it looks better on mobile. And, it means you are less likely to redact info poorly. It's not like we delete images, we just strongly encourage.
    – schroeder
    Apr 8, 2021 at 8:30
  • 2
    @schroeder If you want to be 100% compliant to RFC 5737, you can use 192.0.2.0/24, which is an IPv4 range specifically reserved for documentation and examples.
    – user163495
    Apr 8, 2021 at 10:56
  • 1
    Thank you everyone I appreciate the information and all the feed back and it makes sense if you think about it ssh can’t reject the attempts until it receives them and by that point there already logged. Again thank you. Apr 8, 2021 at 14:16

Not the answer you're looking for? Browse other questions tagged .