Thank you for the answer.
The problem is that, when contacted the concerned party,
they say that they don’t see any login attempts from that IP and
asking whether we were sure that the ssh login were successful.
Looking at what we have recorded using Bro, I just wanted to know how one could
tell whether the ssh login resulted a success/ failure just by looking at the bro conn.log, and ssh.log.
Hence, wanted to know the heuristics behind setting that ‘auth_success’ field to T or F.
Understood...looking at the reputation of that IP I would stick with the theory that there was success. Also I would look into correlating the bro logs with ssh logs.
If they are not seeing *any* attempts then something is screwed up with the logging on their end.
It's possible that the value of auth_success is wrong, but it's not possible that no attempt happened. There was a tcp 3 way handshake, there was a ssh protocol negotiation, they should have something in their logs.
 Or misleading, often from the SSH point of view it was a login, but sometimes the remote system drops you into another password prompt instead of a shell. Appliances do this a lot.
That makes sense, was just curious to know how bro evaluates the auth_success field
A quick question, as the connection was seen to last almost 10 secs and was thinking that
the failed login connections are not that long, hence wanted to ask could it be possible that
the user might have got multiple password prompts over the same connection and Bro logged that single
connection of 10secs?
would it also explain why no ‘R’ or ‘F’ flag was seen in the end of conn history (ShAdDa)?
So, finally some closing remarks:
When asked to look deeper, the client finally did see the ssh attempts on the server,
the issue was with the time zone. It seemed the clock on the client machine was 4hrs ahead of EST,
that’s why the attempts were getting logged with different time stamps than the ones logged in our logs.
When they searched a range of time periods they found those.
Unfortunately (or fortunately) they all were failed login attempts and Bro alert for successful ssh was a false positive from our side.
We had a case in past where Bro had reported a successful ssh in intel.log for a linux machine and when verified with the client it was a true positive,
but for this case it came out to be a false positive, hence was just thinking that may be bro might have a high false positive rate for WinSSHD or ssh for Windows for say, might be wrong.