-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.

Jason Croyle
  • 101
  • 5
  • 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 07 '21 at 18:29
  • 2
    Does this answer your question? [What to do about ssh breakin attempts](https://security.stackexchange.com/questions/66441/what-to-do-about-ssh-breakin-attempts). See also [Found a lot of SSH login attempts in auth.log](https://askubuntu.com/a/1058391/230823) and [Is it normal to get hundreds of break-in attempts per day?](https://serverfault.com/a/244627/283663). – mentallurg Apr 07 '21 at 19:46
  • 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 07 '21 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`. – Steffen Ullrich Apr 07 '21 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 08 '21 at 07:51
  • Thank you everyone I appreciate the information and it does make sense the server can reject the attempt until it is received I was under the assumption ssh wouldn’t even allow the attempts. – Jason Croyle Apr 08 '21 at 14:12

1 Answers1

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.

borcho
  • 550
  • 2
  • 15
  • 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. – usr-local-ΕΨΗΕΛΩΝ Apr 08 '21 at 08: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 08 '21 at 08: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 08 '21 at 08:30
  • Best practices: not many. The easiest is from the RFC standard and replace domains with `example.com`. IPs can be masked or replaced with private ranges (`10.1.1.1`, etc.). – schroeder Apr 08 '21 at 08:33
  • 2
    @schroeder If you want to be 100% compliant to [RFC 5737](https://tools.ietf.org/html/rfc5737), you can use `192.0.2.0/24`, which is an IPv4 range specifically reserved for documentation and examples. –  Apr 08 '21 at 10:56
  • @MechMK1 but harder to type and more difficult to quickly parse for unique IPs. But, yes, that complies with the RFC. – schroeder Apr 08 '21 at 11:10
  • 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. – Jason Croyle Apr 08 '21 at 14:16
  • @schroeder You're right, I just love the oddity of having IP addresses reserved for documentation. –  Apr 08 '21 at 14:25