Как узнать дату\время авторизации в Ubuntu

/proc/uptime, например?

Если вам на будующее, то я пользуюсь на распи программой tuptime. С опцией -l она выводит в следующем формате:

Startup:  1  at  10:14:08 15.11.2022
Uptime:   42 seconds
Shutdown: BAD  at  10:14:50 15.11.2022
Downtime: 2 days, 19 hours, 51 minutes, 21 seconds

Startup:  2  at  06:06:11 18.11.2022
Uptime:   3 minutes, 51 seconds
Shutdown: BAD  at  06:10:02 18.11.2022
Downtime: 4 minutes, 28 seconds

Startup:  3  at  06:14:30 18.11.2022
Uptime:   5 days, 0 hours, 42 minutes, 33 seconds
Shutdown: OK  at  06:57:03 23.11.2022
Downtime: 21 seconds

Не на будущее, а как раз таки отследить событие 10 месячной давности, кстати установил, и прога показывает отсчет от последней перезагрузки, что для меня как раз не вариант, так как по той , что меня интересует , было их, перезагрузок , стартов штук 15.

видимо не то, там выводится большое число, и наверное по сути время считается от последней загрузки\старта.

Так и не понял что же хочет ТС.

ТС видимо хочет получить ответ на вопрос, содержащийся в первом посте. А именно точную дату время (10 месячной давности) когда стартовала машина. Ибо дата\время по факту в ручную были отредактированы в терминале, судя по команде last

Невозможно

uprecords ---> uptimed

uprecords -m 30
     #               Uptime | System                                     Boot up
----------------------------+---------------------------------------------------
->   1    11 days, 02:12:16 | Linux 5.15.0-56-generic   Tue Dec  6 15:13:13 2022
     2     4 days, 07:03:21 | Linux 5.15.0-43-generic   Mon Nov 28 19:46:15 2022
     3     1 day , 20:06:45 | Linux 5.15.0-23-generic   Sat Apr  2 01:17:33 2022
     4     1 day , 19:52:18 | Linux 5.15.0-22-generic   Thu Mar 17 09:27:52 2022
     5     1 day , 17:37:47 | Linux 5.15.0-23-generic   Sat Mar 19 12:48:21 2022
     6     1 day , 06:01:19 | Linux 5.15.0-23-generic   Fri Mar 25 13:56:13 2022
     7     0 days, 17:02:01 | Linux 5.15.0-22-generic   Wed Mar 16 16:25:24 2022
     8     0 days, 14:54:01 | Linux 5.15.0-23-generic   Mon Mar 21 12:40:42 2022
     9     0 days, 10:02:54 | Linux 5.15.0-23-generic   Tue Mar 22 17:55:06 2022
    10     0 days, 05:49:54 | Linux 5.15.0-25-generic   Wed Apr 20 02:09:14 2022
    11     0 days, 04:12:11 | Linux 5.15.0-33-generic   Wed May 25 17:44:38 2022
    12     0 days, 02:29:21 | Linux 5.15.0-23-generic   Fri Apr  1 22:48:00 2022
    13     0 days, 02:23:41 | Linux 5.15.0-25-generic   Wed May 25 11:32:58 2022
    14     0 days, 02:22:43 | Linux 5.15.0-25-generic   Thu Apr 14 17:54:54 2022
    15     0 days, 02:17:41 | Linux 5.15.0-25-generic   Sun Apr 24 17:13:34 2022
    16     0 days, 01:36:48 | Linux 5.15.0-23-generic   Tue Mar 22 16:18:07 2022
    17     0 days, 01:32:42 | Linux 5.15.0-18-generic   Mon Mar  7 22:32:25 2022
    18     0 days, 01:18:37 | Linux 5.15.0-35-generic   Wed Jun 15 12:36:35 2022
    19     0 days, 01:03:10 | Linux 5.15.0-40-generic   Wed Aug  3 09:14:51 2022
----------------------------+---------------------------------------------------
NewRec     6 days, 19:08:54 | since                     Sat Dec 10 22:16:35 2022
    up    24 days, 19:59:30 | since                     Mon Mar  7 22:32:25 2022
  down   259 days, 22:53:34 | since                     Mon Mar  7 22:32:25 2022
   %up                8.720 | since                     Mon Mar  7 22:32:25 2022

uprecords -b -m 30
     #               Uptime | System                                     Boot up
----------------------------+---------------------------------------------------
     1     0 days, 01:32:42 | Linux 5.15.0-18-generic   Mon Mar  7 22:32:25 2022
     2     0 days, 17:02:01 | Linux 5.15.0-22-generic   Wed Mar 16 16:25:24 2022
     3     1 day , 19:52:18 | Linux 5.15.0-22-generic   Thu Mar 17 09:27:52 2022
     4     1 day , 17:37:47 | Linux 5.15.0-23-generic   Sat Mar 19 12:48:21 2022
     5     0 days, 14:54:01 | Linux 5.15.0-23-generic   Mon Mar 21 12:40:42 2022
     6     0 days, 01:36:48 | Linux 5.15.0-23-generic   Tue Mar 22 16:18:07 2022
     7     0 days, 10:02:54 | Linux 5.15.0-23-generic   Tue Mar 22 17:55:06 2022
     8     1 day , 06:01:19 | Linux 5.15.0-23-generic   Fri Mar 25 13:56:13 2022
     9     0 days, 02:29:21 | Linux 5.15.0-23-generic   Fri Apr  1 22:48:00 2022
    10     1 day , 20:06:45 | Linux 5.15.0-23-generic   Sat Apr  2 01:17:33 2022
    11     0 days, 02:22:43 | Linux 5.15.0-25-generic   Thu Apr 14 17:54:54 2022
    12     0 days, 05:49:54 | Linux 5.15.0-25-generic   Wed Apr 20 02:09:14 2022
    13     0 days, 02:17:41 | Linux 5.15.0-25-generic   Sun Apr 24 17:13:34 2022
    14     0 days, 02:23:41 | Linux 5.15.0-25-generic   Wed May 25 11:32:58 2022
    15     0 days, 04:12:11 | Linux 5.15.0-33-generic   Wed May 25 17:44:38 2022
    16     0 days, 01:18:37 | Linux 5.15.0-35-generic   Wed Jun 15 12:36:35 2022
    17     0 days, 01:03:10 | Linux 5.15.0-40-generic   Wed Aug  3 09:14:51 2022
    18     4 days, 07:03:21 | Linux 5.15.0-43-generic   Mon Nov 28 19:46:15 2022
->  19    11 days, 02:13:30 | Linux 5.15.0-56-generic   Tue Dec  6 15:13:13 2022

где есть? на гитхабе нету

Кстати, откуда прога берет данные? Если оттуда же откуда и терминал, то будет все та же ерунда.

Если программы берут данные из файла wtmp, то результат будет у всех один и тот же. Файлы которые требуются для обработки командой journalctl по странным обстоятельствам за нужный период отсутствуют. Откуда еще можно вытянуть логи если не загрузок\стартов системы, то хотя бы действий юзера в определенное время? Интересует время \дата изменения системного времени. Еще интересует чисто технический момент. Как видно из 1 поста, обновление скачалось в автоматическом режиме без участия юзера. Что происходит дальше? Какие варианты? Я понимаю, это наверное зависит от того, как настроен режим обновления. Тем не менее, в контексте 1 поста, невзирая на то, что дата исправлена на 10 января, есть понимание, что ребут мог произойти после 2022-02-22 06:52:31 Здесь, как я понимаю, возможны варианты ребута. 1.С участием юзера 2.или без (я так понимаю, если это прописано в настройках). Была ли авторизация , не понятно, ибо время сессии 139+08:25 при том, что дата не правильная, ни о чем не говорит. Или я не прав, и можно посчитать и учесть время предыдущей сессии со знаком «минус» ? Затем, 23 февр. (из 1 поста) видим , что якобы был авторизованный вход в систему. Теперь объясняю, почему так подробно объясняю ситуацию, и что хочу понять. Теоретически, хозяина ноутбука, не должно было быть рядом с ноутбуком 22 и 23 февраля, теоретически можно предположить, что ушел, оставив крышку не закрытой ( спящий режим отключен). Пин код никто точно не знает (кроме меня)) Могло ли все так случиться, как написал выше? Без хозяина скачалось новое ядро, ноут перезагрузился (либо кто то подошел, нажал на кнопку принудительного отключения, и затем сновал нажал на включение). Авторизованного входа не было, но лог пишет, что был авторизованный вход. Могло быть такое ? Извиняюсь , что так длинно, и для ответа точно нужно вникать в буквы.

Возможно пальцем в небо, но может такое быть что системные часики выставлены криво, boot records (вынужденно) используют их, а потом ntpd время вытягивает? Сравните с другими boot records - они тоже сдвинуты?

Нет, все остальные даты\времена идут по порядку. Только одна строка «неправильная» за 11 месяцев. Но ведь ручками это реализуется несложно? Отключить синхронизацию, сменить дату\время, перезагрузить с новыми данными, откатить, почистить следы «преступлений», включить синхронизацию и снова перезагрузить. Разумеется при условии , что это кому то надо. Или я что то упустил?

Через команду find / -mtime 299 -printf ‘%TY-%Tm-%Td %TT %p\n’ | sort -r

получаю следующее

find: ‘/tmp/systemd-private-dbb15c8fa52449ef9ece9fffe37378ef-bolt.service-kzJ2Nz’: Permission denied find: ‘/tmp/systemd-private-dbb15c8fa52449ef9ece9fffe37378ef-systemd-timesyncd.service-VmFuLG’: Permission denied find: ‘/tmp/snap-private-tmp’: Permission denied 2022-02-23 15:48:54.0000000000 /var/lib/dpkg/info/snapd.prerm 2022-02-23 15:48:54.0000000000 /var/lib/dpkg/info/snapd.preinst 2022-02-23 15:48:54.0000000000 /var/lib/dpkg/info/snapd.postrm 2022-02-23 15:48:54.0000000000 /var/lib/dpkg/info/snapd.postinst

на самом деле и выше и ниже еще куча строк. И по команде find / -atime

find: ‘/tmp/systemd-private-dbb15c8fa52449ef9ece9fffe37378ef-bolt.service-kzJ2Nz’: Permission denied find: ‘/tmp/systemd-private-dbb15c8fa52449ef9ece9fffe37378ef-systemd-timesyncd.service-VmFuLG’: Permission denied find: ‘/tmp/snap-private-tmp’: Permission denied 2022-02-24 01:20:23.0000000000 /snap/snap-store/638/usr/lib/x86_64-linux-gnu/libjcat.so.1.0.0 2022-02-24 01:20:23.0000000000 /snap/snap-store/638/usr/lib/x86_64-linux-gnu/libjcat.so.1

Здесь 2 вопроса.

1.Могут ли иметь место modified / created , если крышка ноута была закрыта, то есть он был включен , но в спящем режиме? 2.Могут ли быть внутри Permission denied файлов быть иные временные метки (или их история) , чем те, что видятся в свойствах файла?

Я не правильно, сложно озвучил свои хотелки. Проще и короче будет так. Как отследить действия именно юзера а не ситемы в компьютере, в каких логах, какими командами. Команда find нашла файлы и папки, к которым был доступ, которые изменялись, и даже которые поменяли статус. Но, как оказалось, ноут и спящем режиме работает. Команда last показала авторизованный вход 23 февраля, но это опять таки не 100% гарантия , видимо что вход был осуществлен юзером. Другие 2 хотелки выглядят так. Можно ли посмотреть сетевые подключения за произвольные даты, далекие от сегодня и вчера? ss как я понял, здесь не помощник? И можно ли где то подсмотреть, когда переводились часы? В виндовс такая возможность предусмотрена на уровне security.

Начал копаться в теме Linux Forensics и нашел , что есть who -t, –time print last system clock change однако у меня ничего не показывает. Вообще есть варианты отследить, когда менялось ситемное время, хоть юзером, хоть в результате сбоя ? Еще я нашел, что есть такие Иноды, в них по любому зафиксированы любые изменения , но пока не понял, как с помощью них найти допустим изменение системного времени. Подскажите, кто в курсе этой темы.