2

A Linux (specifically Debian Jessie) server that needs to be exposed to the Internet is spitting out various OpenSSH 6.7 preauth errors in the logs. For example, I'm getting (timestamps elided for clarity):

  • error: Received disconnect from A.B.C.D: 3: com.jcraft.jsch.JSchException: Auth fail [preauth]
  • fatal: Unable to negotiate a key exchange method [preauth]
  • fatal: no matching cipher found: client ... server ... [preauth]
  • Received disconnect from A.B.C.D: 11: Normal Shutdown, Thank you for playing [preauth]
  • Received disconnect from A.B.C.D: 11: ok [preauth]

and so on.

I'm not terribly worried about the probes themselves; the system is kept up to date, the OpenSSH configuration is fairly well hardened according to current best practice, and there are additional protections (e.g. fail2ban) in place.

Is there any reason why any preauth OpenSSH log entries would warrant specific human attention?

The answers to the question What does “Normal Shutdown, Thank you for playing [preauth]” In SSH logs mean? indicates that the specific case in that question is safe to ignore; my question is more generic.

Community
  • 1
user
  • 4,267
  • 4
  • 32
  • 70
  • These are just different failed connection attempts. The `preauth` part is the good part: All of that is going on in sandboxed process which does not have any reasonable access to your server. But when you would see some nonstandard messages, that would mean that somebody is playing more than you want (but not necessarily compromise). I would say nothing to worry about. Anyway the question as it is answered by these lines or just too broad ... – Jakuje Mar 07 '16 at 21:57

1 Answers1

2

It looks like you've taken some specific steps to harden OpenSSH.

As a side effect of these changes, combined with running a relatively recent OpenSSH version, you will receive many more detailed log entries about connection failures.

All of the preauth messages you are seeing fall into this category, and represent a client which failed to make a connection for some reason. For the most part, these connections fail before the client is able to attempt a username and password.

The best thing to do with these log entries is to feed them to a log aggregator and make nice graphs for security researchers to look at. They do not need any individual human intervention.

Of course, you should continue to intervene on messages which indicate a password was attempted and failed. Your existing tools such as fail2ban will serve you well here, though you'll find your ban lists far smaller than before, as most ssh brute force bots do not yet use modern crypto (which is the root cause of most of these messages).

One other place where you may need to intervene is with authorized users who are no longer able to connect, because they are using old versions of ssh clients (e.g. an ancient version of PuTTY or FileZilla). Updating the client to the latest version fixes these issues.

Michael Hampton
  • 237,123
  • 42
  • 477
  • 940