An authorized_keys entry's mtime is 40 days old but auditd retains 14 days — how do you set your lookback window?

## Why the time axis is the one that breaks Hosts and accounts you can enumerate on demand. "Since when" is answerable only if something wrote it down and kept it, and retention is decided months before your investigation by someone optimising storage. This is the axis where scoping runs into a wall, and the interview question is what you do at the wall. ## What the file's mtime actually says `authorized_keys` is **one file containing many key lines**. The filesystem stores one modification time for the file, not a timestamp per line. So a 40-day-old mtime supports one claim: the file was last written 40 days ago, and therefore every line currently in it existed by that date. It does **not** say the unexplained key was added on that date — if a second key was appended later, the mtime belongs to the later write and the suspicious key is older still. Two more caveats worth knowing: - `mtime` can be set to an arbitrary value by anyone who can write the file, so it is attacker-controllable. - Setting `mtime` backwards updates `ctime` (the inode-change time) to the present, so a `ctime` far newer than `mtime` is itself an oddity worth noting. Treat the timestamp as a hypothesis to corroborate off the host, not as a fact to build on. ## What auditd can and cannot cover `auditd` records syscalls and file accesses **only where a rule told it to** — a watch on the path, or a syscall rule. If nobody configured a watch on `/home/*/.ssh/authorized_keys`, the 14 days you do have contain nothing about the file being written, and that is a configuration fact, not evidence about the adversary. On top of that, its on-disk logs rotate by size and file count, so "14 days" is itself an estimate that shortens on a noisy host. The common wrong move is to raise the retention setting and re-run the query. Retention is not retroactive: rotated logs are gone, and changing the config helps the *next* investigation. ## Sources that outlive auditd The productive answer is to stop treating the case as having one window and start listing sources by horizon: | Source | What it can answer here | | --- | --- | | Config-management run history / config repo git log | Whether the key was deployed by automation, by which commit and when — git history is effectively permanent | | Central `sshd` authentication logs | `Accepted publickey for <user> from <ip> ... SHA256:<fingerprint>` — searchable by *this key's* fingerprint, often retained far longer than host audit logs | | Bastion / jump-host session logs | Whether anyone reached the host at all in a period, and from where | | Identity-provider or VPN sign-in logs | Which human sessions existed around a candidate window | | Host backups or snapshots | Whether the key was present in a snapshot from before the retention edge — a cheap binary search on the date | | Network flow records | That bytes moved between two addresses; flow carries no payload, so never what they were | The backup search is the underrated one: if last quarter's snapshot of `~/.ssh` already contains the key, "since when" just got answered from outside the log estate entirely. ## Direction of the claims An `Accepted publickey` line proves the key was **accepted**, not who held the private half. The absence of such a line within the retained window proves only that no retained record shows it; it is not evidence the key was never used. Encoding that inversion into a case note is how a scoping gap silently becomes a conclusion. ## Writing the gap down The output of this axis is usually a bounded statement rather than a date: *the key existed by \<mtime\>; usage is verifiable from \<retention edge\> forward, where none was seen; the period before that is not covered by any available source.* That sentence is what the rest of the investigation, and any later decision to close, has to work from — and it also tells you where **not** to spend more hours, because no amount of extra effort makes a rotated log come back.