Matching SSHD information in audit logs

[MAUPERTUIS, PHILIPPE]

> -----Message d'origine-----
> De : Steve Grubb [mailto:sgrubb at redhat.com]
> Envoyé : mardi 17 décembre 2019 15:21
> À : linux-audit at redhat.com
> Cc : MAUPERTUIS, PHILIPPE
> Objet : Re: Matching SSHD information in audit logs
>
> On Tuesday, December 17, 2019 5:57:53 AM EST MAUPERTUIS, PHILIPPE
> wrote:
> > Hi,
> > When setting the SSHD log level to verbose as recommended by the CIS, I
> get
> > the following in the secure log : Dec 17 11:32:29 myserver sshd[8456]:
> > Connection from xx.xx.xx.xx port 44090 on xx.xx.xx.xx port 22 Dec 17
> > 11:32:30 myserver sshd[8456]: Accepted key RSA SHA256: qhpzQKKbwaX8
> found
> > at /usr/bin/sss_ssh_authorizedkeys:1 Dec 17 11:32:30 myserver
> sshd[8456]:
> > Postponed publickey for myuser from xx.xx.xx.xx port 44090 ssh2
> [preauth]
> > Dec 17 11:32:30 myserver sshd[8456]: Accepted key RSA SHA256:
> qhpzQKKbwaX8
> > found at /usr/bin/sss_ssh_authorizedkeys:1 Dec 17 11:32:30 myserver
> > sshd[8456]: Accepted publickey for myuser from xx.xx.xx.xx port 44090
> > ssh2: RSA SHA256: qhpzQKKbwaX8 Dec 17 11:32:30 myserver sshd[8456]:
> > pam_unix(sshd:session): session opened for user myuser by (uid=0) Dec 17
> > 11:32:31 myserver sshd[8456]: User child is on pid 8460
> > Dec 17 11:32:31 myserver sshd[8460]: Starting session: shell on pts/4 for
> > myuser from xx.xx.xx.xx port 44090 id 0
> >
> > What are the corresponding events in audit ?
>
> I don't think anyone has ever tried to map between syslog and audit. I also
> think that CIS maybe doesn't understand audit and how it works. For quite
> some time, there has been a requirement to log any key lifecycle in the audit
> logs. This means that the DH key exchange and the session keys get logged
> when they are created and when they are destroyed. Also, pam logs the
> session
> beginning and end. And sshd logs any keys that it accepts. So, I think the
> information is there if one wanted or needed to map between them. But it
> should be unnecessary. I'm not sure what CIS is looking for in syslog.
> Because if there is something important in syslog that is not in the audit
> logs, I'd like to know what it is.
>
>
> > My main concern is with the bold line which indicates how the public key
> > was granted
>
> That should also be in the audit logs.
I find in the audit log which key has been accepted but not that it has been accepted due to /usr/bin/sss_ssh_authorizedkeys (and not a local authorized_keys file).
In the USER_AUTH message I can see a field grantors=auth-key but I don't know how to interpret it.
I had a look at https://github.com/linux-audit/audit-documentation/blob/master/specs/fields/field-dictionary.csv but grantor is not mentioned there
I didn't other fields as well :
>From SOFTWARE_UPDATE the fields sw, sw_type, key_enforce are not listed.
The page https://github.com/linux-audit/audit-documentation/blob/master/specs/messages/message-dictionary.csv doesn't mention the type SOFTWARE_UPDATE
Maybe I am looking at the wrong place, Where should I look ?
>
>
> > Could you point me to a documentation showing which events a ssh login
> > would generate ?
>
> To my knowledge, there is no document that singles out what a sshd login
> should look like. There are documents that explain what the record type are.
> And you should be able to isolate them by ausearch -x sshd.
>
What I missed was this ausearch -x sshd which gives me the events

> -Steve
>
Philippe
equensWorldline is a registered trade mark and trading name owned by the Worldline Group through its holding company.
This e-mail and the documents attached are confidential and intended solely for the addressee. If you receive this e-mail in error, you are not authorized to copy, disclose, use or retain it. Please notify the sender immediately and delete this email from your systems. As emails may be intercepted, amended or lost, they are not secure. EquensWorldline and the Worldline Group therefore can accept no liability for any errors or their content. Although equensWorldline and the Worldline Group endeavours to maintain a virus-free network, we do not warrant that this transmission is virus-free and can accept no liability for any damages resulting from any virus transmitted. The risks are deemed to be accepted by everyone who communicates with equensWorldline and the Worldline Group by email