История грехов и перехват агента SSH

Тема 01 заканчивалась на том, как подменить функцию в чужом процессе. Но большинство компрометаций начинается не с этого, а с чтения: человек сам записал в файлы то, что не должен был, и оставил это лежать в домашнем каталоге с правами 0600, которые защищают от соседа, но не от root и не от того, кто уже получил доступ. Разведка артефактов — самый дешёвый этап операции ⁷: он не требует ни эксплойта, ни прав, ни сети, только умения читать форматы.

Второй сюжет темы — агент SSH. Он устроен так, что обладание сокетом эквивалентно обладанию ключами, которые в нём загружены: агент не проверяет, кто просит подпись, он проверяет только права на файл сокета. Отсюда две крайности: либо агент вообще не используется (ключ с парольной фразой вводится каждый раз), либо используется с пробросом на чужие хосты, где любой root бастиона получает беспарольный вход на все машины, куда этот ключ пускает.

Разбирается всё на уровне форматов. История команд — не «файл со строками», а структура с HISTTIMEFORMAT, histappend и правилами фильтрации; журналы входов — не «текстовые логи», а бинарные записи struct utmp, которые читаются utmpdump; протокол агента — не «магия OpenSSH», а length-prefixed сообщения с номерами типов, и клиента к нему можно написать на двадцати строках Python. Понимание форматов даёт то, чего не даёт заучивание команд: возможность ответить на вопрос «а что ещё здесь может быть».

Границы с соседями: тема 01 — окружение и загрузчик; тема 03 — SUID и capabilities; тема 05 — автозапуск; тема 06 — метки времени и анти-форензика на уровне inode. Здесь метки времени разбираются ровно настолько, насколько нужно для корреляции сессий, а их подделка — предмет темы 06.

На рисунке 1 сведены три группы артефактов и то, как они сходятся по времени: файлы истории, журналы входов и метки inode.

История команд: как bash её пишет и что она выдаёт

Что попадает в файл и когда

Bash хранит историю в памяти сессии ⁴ и записывает её в файл, заданный HISTFILE (по умолчанию ~/.bash_history), при штатном завершении. Ключевое слово — «штатном»: если оболочка убита сигналом, история не сохранится; если сессия живёт, файл содержит только то, что записали предыдущие сессии. Именно поэтому вопрос «почему в истории нет последних команд» имеет технический ответ, а не мистический.

Второй важный механизм — shopt -s histappend. По умолчанию bash при выходе перезаписывает файл содержимым памяти, а не дописывает. Если у пользователя открыто три терминала, каждый при выходе перезапишет файл своим списком, и в итоге останется история последнего закрытого. С histappend файл дополняется, и тогда история — объединение всех сессий, но без указания, какая команда из какой сессии.

Третий механизм — PROMPT_COMMAND='history -a': запись после каждой команды, а не при выходе. Это частая настройка у администраторов, которые боятся потерять историю при обрыве связи. Побочный эффект: файл обновляется постоянно, и его mtime перестаёт означать «конец сессии».

Проверить всё это можно на своей машине, не трогая настоящую историю:

export HISTFILE=$PWD/hist_test
export HISTTIMEFORMAT='%F %T '
bash --norc -i

Внутри интерактивной оболочки — несколько команд, затем exit. Файл будет выглядеть так:

#1792422679
echo alpha
#1792422679
echo beta
#1792422679
exit

Строки с # — не комментарии, а временные метки в формате «эпоха UNIX». HISTTIMEFORMAT влияет только на отображение при history, а в файл пишется именно эпоха — целое число секунд. Отсюда практический приём: одна и та же команда может иметь одинаковую метку, если выполнена в одну секунду, — точность истории ограничена секундой, а не наносекундами, как у stat.

Переменные, которые меняют след

Практический вывод для разведки: наличие HISTTIMEFORMAT в /etc/bash.bashrc или ~/.bashrc — подарок, потому что даёт время. Отсутствие — не приговор: mtime файла и журналы входов всё ещё позволяют восстановить хронологию, просто с меньшей точностью.

Отдельно стоит set +o history: команда отключает запись в текущей сессии. Она не стирает уже записанное и не мешает history -a записать накопленное, но новые команды в файл не попадут. Это первое, что делает человек, который знает, что делает, — и потому отсутствие подозрительных команд в истории не означает их отсутствия в системе.

Что история не сохраняет

Три вещи, которые важно понимать, чтобы не строить ложных выводов.

Команды, выполненные не в интерактивной оболочке. bash -c '...', скрипты, задания cron, ssh host command — всё это не попадает в ~/.bash_history, потому что история ведётся только для интерактивных сессий.

Команды, введённые в другом терминале, пока сессия жива. Файл обновляется при выходе (или по history -a), поэтому живая сессия видна только через history в самой сессии — то есть только её владельцу или тому, кто уже в этой сессии.

Полные командные строки после редактирования. Если пользователь исправил команду в редакторе (Ctrl-X Ctrl-E), в историю попадёт итоговый вариант, а не исходный. Черновики не сохраняются.

Как читать историю: три запроса и разбор меток

Первое, что делается с найденным файлом, — поиск учётных данных и адресов. Три шаблона покрывают большую часть:

grep -Ein 'pass|passwd|token|secret|api[_-]?key|BEGIN [A-Z ]*PRIVATE KEY' ~/.bash_history
grep -Ein 'ssh|scp|rsync|mysql|psql|redis-cli|curl|wget' ~/.bash_history | head -20
grep -Eo '([0-9]{1,3}\.){3}[0-9]{1,3}' ~/.bash_history | sort | uniq -c | sort -rn | head

Первый запрос ищет секреты, второй — внешние взаимодействия, третий — карту адресов, с которыми работал пользователь. Третий запрос особенно полезен: он даёт список хостов, к которым стоит присмотреться, даже если команды были безобидными.

Если в файле есть метки #<эпоха>, их надо развернуть в даты. Однострочник на Python читает файл и печатает пары «время — команда»:

#!/usr/bin/env python3
"""hist_time.py — печатает историю bash с расшифрованными метками времени."""
import sys
from datetime import datetime, timezone

path = sys.argv[1] if len(sys.argv) > 1 else None
if not path:
    sys.exit("usage: hist_time.py ~/.bash_history")

stamp = None
with open(path, encoding="utf-8", errors="replace") as fh:
    for line in fh:
        line = line.rstrip("\n")
        if line.startswith("#") and line[1:].isdigit():
            stamp = datetime.fromtimestamp(int(line[1:]), tz=timezone.utc)
            continue
        when = stamp.strftime("%Y-%m-%d %H:%M:%S UTC") if stamp else "(без метки)"
        print(f"{when}  {line}")

python3 hist_time.py hist_test

2026-10-19 15:11:19 UTC  echo alpha
2026-10-19 15:11:19 UTC  echo beta
2026-10-19 15:11:19 UTC  exit

Обратите внимание: все три команды получили одну метку, потому что выполнены в одну секунду. При разборе реальной истории метки обычно разнесены на минуты, и именно интервалы между ними дают представление о темпе работы: серия команд за десять секунд — это скрипт или вставка из буфера, ровные интервалы по пять минут — ручная работа с паузами на чтение вывода.

Остальные артефакты: редакторы, клиенты, сеть

.viminfo: секции и что в них лежит

Vim хранит состояние в ~/.viminfo ⁵ (Neovim — в ~/.local/state/nvim/shada/main.shada). Файл — не «список файлов», а набор секций, каждая со своим форматом:

• # This viminfo file was generated by Vim 9.0 — заголовок с версией;
• # Command Line History (newest to oldest) — история команд :;
• # Search String History (newest to oldest) — история поиска / и ?;
• # Expression History — история =;
• # Input Line History — история ввода;
• # Debug Line History — отладочные строки;
• # Registers — содержимое регистров, включая "" (последний yank), "0–"9, "-, ":, "/;
• # File marks — метки файлов с номерами строк и колонками;
• # Jumplist — список переходов.

Практическая ценность секций неодинакова. File marks даёт список файлов, которые человек открывал, — часто тех, о которых он не писал в терминале. Registers может содержать фрагменты вырезанного текста: строки конфигурации, ключи, пароли. Search String History показывает, что человек искал, — а ищут обычно то, что не знают наизусть.

sed -n '/# File marks:/,/^$/p' ~/.viminfo | head -10
sed -n '/# Registers:/,/^$/p' ~/.viminfo | head -20

# File marks:
'0  14  0  /etc/wireguard/wg0.conf
'1  1   0  /opt/backup/credentials.env
'2  82  12  /etc/postgresql/16/main/pg_hba.conf
'3  5   0  ~/scripts/deploy-api.sh

# Registers:
""1	LINE	0
	API_KEY="sec_984f7b2a9e1041cd"
	DB_PASSWORD="pg_cluster_secret_token"

Первая строка ""1 означает: регистр "1 (первый из нумерованных), тип LINE, длина 0. Дальше идёт содержимое. Для разведки важно, что регистры не шифруются и не очищаются автоматически — они живут, пока файл не перезаписан.

Клиенты: mysql, psql, python, less, wget

Каждый интерактивный клиент ведёт свой журнал, и все они лежат в домашнем каталоге:

.netrc — отдельный случай: это не история, а конфигурация с паролями в открытом виде. Формат простой: machine <host> login <user> password <pass>. Если файл есть, он почти всегда содержит действующие учётные данные, потому что иначе его бы не держали.

ls -la ~/.netrc ~/.mysql_history ~/.psql_history ~/.python_history ~/.lesshst ~/.wget-hsts 2>&1
grep -c . ~/.python_history 2>/dev/null

-rw------- 1 alice alice 214 окт 12 09:14 /home/alice/.netrc
-rw------- 1 alice alice 892 окт 18 17:02 /home/alice/.mysql_history
...

known_hosts: карта сети и её хеширование

~/.ssh/known_hosts — список хостов ¹, к которым пользователь подключался, с их открытыми ключами. По умолчанию в современных дистрибутивах имена хешируются (HashKnownHosts yes), и строка выглядит как |1|<base64>|<base64>. Хеш — HMAC-SHA1 от имени хоста с солью; восстановить имя перебором можно, но для типичного списка хостов это дороже, чем посмотреть в другие артефакты.

Проверить конкретный хост:

ssh-keygen -F 192.0.2.10
ssh-keygen -F db-primary.nsu.example

# Host 192.0.2.10 found: line 1
|1|AbCdEf123456=|XyZ987654321= ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIExampleKey1

Если хеширование отключено (HashKnownHosts no), файл читается как список: адрес, тип ключа, ключ. Тогда это готовая карта инфраструктуры, включая внутренние имена, которых нет в DNS снаружи.

~/.ssh/config дополняет картину: алиасы, пользователи, порты, ProxyJump, IdentityFile. Одна строка Host db-internal с ProxyJump bastion рассказывает и о топологии, и о том, что доступ идёт через бастион.

grep -E '^(Host|HostName|User|Port|ProxyJump|IdentityFile)' ~/.ssh/config 2>/dev/null | head -20

Временные метки и восстановление хронологии

Четыре времени inode

У каждого inode четыре отметки времени ⁶, и путать их — самая частая ошибка при разборе:

• atime — время последнего чтения содержимого;
• mtime — время последнего изменения содержимого;
• ctime — время последнего изменения метаданных: прав, владельца, ссылок, а также любое изменение содержимого (потому что mtime — тоже метаданные);
• btime — время создания inode (birth time), доступно через statx и поддерживается ext4, XFS, btrfs; на некоторых ФС отсутствует.

Посмотреть все четыре:

touch probe.txt
stat -c 'atime=%x%nmtime=%y%nctime=%z%nbtime=%w' probe.txt

atime=2026-10-19 18:11:19.210410720 +0300
mtime=2026-10-19 18:11:19.210410720 +0300
ctime=2026-10-19 18:11:19.210410720 +0300
btime=2026-10-19 18:11:19.210410720 +0300

Точность — наносекунды, но реальная гранулярность зависит от ФС и ядра. На ext4 с nodelalloc и стандартными настройками метки обновляются с точностью до наносекунды, но квантование может быть грубее.

Практическое правило корреляции: mtime файла истории — момент последней записи, ctime — момент, когда изменились права или содержимое, btime — когда файл создан. Если ctime > mtime, значит после последней записи файл трогали метаданными (например, chmod), — это признак вмешательства. Если btime свежее, чем содержимое (файл создан только что, а внутри «старая» история), это признак подделки, и разбирается в теме 06.

relatime и почему atime врёт

Исторически atime обновлялось при каждом чтении, что убивало производительность. Поэтому появились режимы монтирования:

• strictatime — обновлять всегда (редко используется);
• relatime — обновлять, если прошлое atime старше mtime/ctime или прошло больше суток (по умолчанию в большинстве дистрибутивов);
• noatime — не обновлять вовсе;
• lazytime — обновлять в памяти, сбрасывать на диск периодически.

Следствие для разведки: atime у файла, который читали вчера, может остаться недельной давности. Поэтому «файл не читали» по atime — не факт. Проверить режим:

findmnt -no OPTIONS / | tr ',' '\n' | grep -E 'atime|relatime|noatime'
mount | grep ' / ' | head -1

relatime
/dev/nvme0n1p2 on / type btrfs (rw,relatime,ssd,space_cache=v2)

Ещё одна тонкость: чтение через mmap и через sendfile может не обновлять atime вообще, потому что страницы уже в page cache. Поэтому atime — вспомогательный признак, а не доказательство.

Корреляция: рецепт из четырёх шагов

Задача: понять, кто и когда работал на машине, и что именно делал. Рецепт, который работает без специальных средств:

1. Список сессий. last -F -n 20 — успешные входы с временем начала и конца; lastb -n 20 — неудачные (нужен root); who и w — активные сейчас.
2. Метки артефактов. stat по .bash_history, .viminfo, .mysql_history — mtime и ctime.
3. Содержимое. Метки #<эпоха> в истории, если есть; иначе — интервалы между строками по смыслу.
4. Сверка. Сессия из wtmp с 14:10 до 14:40 и mtime истории 14:40:10 — это одна и та же сессия; команды внутри относятся к этому интервалу.

Журнал last на реальной машине выглядит так:

last -F -n 4

noviui   pts/6        :1               Mon Oct 19 16:21:37 2026   gone - no logout
noviui   pts/5        :1               Mon Oct 19 15:49:01 2026   gone - no logout
noviui   pts/5        :1               Mon Oct 19 15:22:21 2026 - Mon Oct 19 15:27:35 2026  (00:05)

gone - no logout — важный маркер: сессия не завершилась штатно, запись о выходе не была создана. Причины бывают разные (обрыв SSH, закрытие терминала, kill -9), но для разбора это сигнал, что окончание сессии восстанавливать придётся по косвенным признакам.

Активные сессии:

w

 18:11:27 up  3:43,  1 user,  load average: 1,83, 2,33, 2,63
USER     TTY       LOGIN@   IDLE   JCPU   PCPU  WHAT

Пустая строка после заголовка — не ошибка: w показывает процессы текущего терминала, а если сессия одна и это сама w, список может быть пуст. Смотреть надо на строку up и число пользователей.

utmp, wtmp, btmp: устройство журналов входов

struct utmp и типы записей

Три файла — три назначения: /run/utmp ³ (текущее состояние), /var/log/wtmp (история успешных входов и перезагрузок), /var/log/btmp (неудачные попытки). Все три — последовательности записей фиксированного размера, структура struct utmp (в glibc — struct utmp, размер 384 байта на x86_64).

Поля, которые имеют значение:

• ut_type — тип записи: BOOT_TIME (2), INIT_PROCESS (5), LOGIN_PROCESS (6), USER_PROCESS (7), DEAD_PROCESS (8), RUN_LVL (1);
• ut_pid — PID процесса;
• ut_line[32] — терминал (pts/0, tty1);
• ut_id[4] — идентификатор линии;
• ut_user[32] — имя пользователя;
• ut_host[256] — откуда вход;
• ut_tv — время в секундах и микросекундах;
• ut_addr_v6[4] — адрес в бинарном виде.

Записи только добавляются: wtmp не перезаписывается, а дополняется, и ротация делается через logrotate (создание нового файла). Именно поэтому wtmp — относительно надёжный источник: удалить из него запись можно только правкой файла, а это оставляет след в mtime и в журнале ротации.

utmpdump: чтение без библиотек

utmpdump переводит бинарные записи в текст и обратно. Прямое чтение:

utmpdump /var/log/wtmp | head -3

Utmp dump of /var/log/wtmp
[2] [00000] [~~  ] [reboot  ] [~           ] [6.14.9-arch1-1      ] [0.0.0.0        ] [2025-06-07T18:01:15,909554+00:00]
[5] [00073] [cons] [        ] [console     ] [                    ] [0.0.0.0        ] [2025-06-07T18:01:17,233293+00:00]

Формат строки: [тип] [PID] [линия] [пользователь] [хост] [терминал/ядро] [адрес] [время]. Первая запись — перезагрузка ([2]), вторая — инициализация консоли ([5]). Поле с версией ядра (6.14.9-arch1-1) появляется у BOOT_TIME и позволяет сопоставить перезагрузки с обновлениями.

Обратная операция — utmpdump -r — читает текстовый дамп и пишет бинарный файл. Это и инструмент восстановления, и инструмент подделки (тема 06): можно выгрузить wtmp, отредактировать строки и загрузить обратно.

Права на файлы:

ls -l /var/log/wtmp /var/run/utmp /var/log/btmp

-rw-rw-r-- 1 nobody nobody 4353792 окт 19 16:21 /var/log/wtmp
-rw-rw-r-- 1 nobody nobody    3456 окт 19 17:22 /var/run/utmp

nobody:nobody и права 0664 — стандартная настройка: писать может только группа utmp, читать — все. btmp обычно 0600 root:root, поэтому lastb без root отвечает «Отказано в доступе».

sshd и журнал: второй источник

wtmp фиксирует факт входа, но не способ аутентификации. Способ виден в журнале sshd: строки Accepted publickey for alice from 192.0.2.45 port 51234 ssh2: ED25519 SHA256:... и Failed password for .... В системах с systemd журнал читается так:

journalctl -n 5 _COMM=sshd --no-pager

сен 12 18:37:01 suprohub sshd[43448]: Server listening on :: port 22.
сен 13 00:36:19 suprohub sshd[43448]: Received signal 15; terminating.

Здесь видны только служебные сообщения — на этой машине не было входов по SSH за период. На сервере с активностью строки Accepted дают точную привязку: время, пользователь, адрес, тип ключа и его отпечаток. Сопоставление Accepted из журнала с записями wtmp — стандартный способ отличить вход по ключу от входа по паролю и от входа через sudo.

ssh-agent: протокол, сокет и проброс

Зачем агент и что он держит

Приватный ключ с парольной фразой расшифровывается при каждом использовании. Чтобы не вводить фразу на каждый ssh или git pull, ключ расшифровывается один раз и остаётся в памяти ssh-agent. Клиент не читает ключ с диска: он просит агента подписать данные.

Схема: сервер присылает случайные данные (challenge), клиент передаёт их агенту, агент подписывает приватным ключом, клиент отправляет подпись серверу, сервер проверяет её открытым ключом из authorized_keys. Приватный ключ не покидает память агента — но подпись получить может любой, кто имеет доступ к сокету.

Архитектура связки клиента, агента и сервера показана на рисунке 2.

Формат сообщений: length-prefixed и номера типов

Протокол агента описан в draft-miller-ssh-agent ² и устроен просто: сообщение — это uint32 длины (сетевой порядок байтов) и тело; первый байт тела — тип. Строки внутри тела — тоже uint32 длины и байты.

Основные типы:

Клиент на двадцати строках Python показывает, что «магия» — это два сообщения:

#!/usr/bin/env python3
"""agent_list.py — список ключей в ssh-agent без ssh-add."""
import os
import socket
import struct
import sys

sock_path = os.environ.get("SSH_AUTH_SOCK")
if not sock_path:
    sys.exit("SSH_AUTH_SOCK не задан")

s = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
s.connect(sock_path)

# SSH2_AGENTC_REQUEST_IDENTITIES = 11
s.sendall(struct.pack(">I", 1) + b"\x0b")

header = s.recv(4)
if len(header) < 4:
    sys.exit("агент закрыл соединение")
length = struct.unpack(">I", header)[0]

body = b""
while len(body) < length:
    chunk = s.recv(length - len(body))
    if not chunk:
        break
    body += chunk

if not body or body[0] != 12:
    sys.exit(f"неожиданный тип ответа: {body[0] if body else 'нет'}")

count = struct.unpack(">I", body[1:5])[0]
print(f"ключей в агенте: {count}")

off = 5
for _ in range(count):
    blob_len = struct.unpack(">I", body[off:off + 4])[0]
    off += 4
    blob = body[off:off + blob_len]
    off += blob_len

    type_len = struct.unpack(">I", blob[0:4])[0]
    key_type = blob[4:4 + type_len].decode()

    comment_len = struct.unpack(">I", body[off:off + 4])[0]
    off += 4
    comment = body[off:off + comment_len].decode(errors="replace")
    off += comment_len

    print(f"  {key_type}  {comment}")

Запуск с ключом, добавленным через ssh-add:

ssh-agent -a $PWD/agent.sock
SSH_AUTH_SOCK=$PWD/agent.sock ssh-add ./id_lab
SSH_AUTH_SOCK=$PWD/agent.sock python3 agent_list.py

Identity added: /home/alice/lab/id_lab (lab@nsu.example)
ключей в агенте: 1
  ssh-ed25519  lab@nsu.example

Три строки вывода — это весь протокол в действии: тип 12, счётчик, блоб ключа, комментарий. Отпечаток (SHA256:...) считается как SHA-256 от блоба и в протоколе не передаётся — его вычисляет клиент.

Сокет: где лежит и какие права

Путь к сокету — в SSH_AUTH_SOCK. Три варианта размещения:

• /tmp/ssh-XXXXXXXXXX/agent.<PID> — традиционный, создаётся ssh-agent без опций; каталог 0700, сокет 0600;
• /run/user/<UID>/keyring/ssh — через gnome-keyring или systemd;
• /run/user/<UID>/ssh-agent.socket — сокет-активация systemd.

ls -l "$SSH_AUTH_SOCK"

srw------- 1 alice alice 0 окт 19 18:10 /home/alice/lab/agent.sock

Первый символ s — сокет, права 0600 — только владелец. Ключевой момент: права проверяет ядро при connect, а не агент. Если файл сокета доступен на запись другому пользователю, тот сможет подключиться и попросить подпись — агент не спросит, кто он.

Схема перехвата при небезопасном пробросе показана на рисунке 3: сокет на бастионе — это точка, через которую подпись уходит к агенту.

Проброс: -A и -R /path

ssh -A (или ForwardAgent yes) просит сервер создать локальный сокет и пробросить его обратно к клиенту. На сервере появляется /tmp/ssh-XXXXXX/agent.NNNN, а в сессию экспортируется SSH_AUTH_SOCK на него. Всё, что делает клиент на сервере, проходит через этот сокет к агенту на рабочей станции.

ssh -R /remote/sock:/local/sock делает то же самое, но явно: указывает, какой локальный сокет пробросить и куда его положить на сервере. Это универсальный механизм: пробросить можно не только агент, но и, например, сокет Docker или базы данных.

Разница между «украсть ключ» и «использовать агент» принципиальна: ключ не покидает рабочую станцию, но подпись получить может любой процесс на сервере, у которого есть доступ к проброшенному сокету. Именно поэтому ForwardAgent на недоверенном хосте — это передача права подписи, а не «удобная настройка».

Проверить, что именно проброшено, можно на сервере:

echo "$SSH_AUTH_SOCK"
ls -l /tmp/ssh-*/agent.* 2>/dev/null
ss -xl 2>/dev/null | grep -c ssh

Что именно подписывает агент

SSH2_AGENTC_SIGN_REQUEST (13) — второе сообщение, которое имеет смысл разобрать. Тело: строка с блобом ключа, строка с данными, uint32 флагов. Ответ — SSH_AGENT_SIGN_RESPONSE (14) с подписью в формате SSH: строка с типом ключа и строка с байтами подписи.

Продолжение того же клиента:

data = b"nsu.example challenge"
body = (b"\x0d"
        + struct.pack(">I", len(blob)) + blob
        + struct.pack(">I", len(data)) + data
        + struct.pack(">I", 0))
response = req(body)

print("тип ответа:", response[0])          # 14
sig_len = struct.unpack(">I", response[1:5])[0]
sig = response[5:5 + sig_len]
type_len = struct.unpack(">I", sig[0:4])[0]
print("тип подписи:", sig[4:4 + type_len].decode())

тип ответа: 14
тип подписи: ssh-ed25519 длина: 83

Смысл: любой процесс, который может подключиться к сокету, получает подпись на произвольные данные. Ему не нужен приватный ключ, не нужен доступ к диску, не нужна парольная фраза. Для SSH-аутентификации этого достаточно: подпись, полученная от агента, неотличима от подписи, сделанной владельцем, потому что криптографически она и есть подпись владельца.

Флаги в запросе влияют на формат подписи: для RSA — SSH_AGENT_RSA_SHA2_256 (2) и SSH_AGENT_RSA_SHA2_512 (4). Для ed25519 флаги не используются. При разборе чужого клиента эти числа помогают понять, что именно он просил.

Ограничения, которые можно навесить на ключ

ssh-add умеет добавлять ключ с ограничениями через расширение SSH_AGENTC_ADD_ID_CONSTRAINED (25):

Отсюда ssh-add -t 1800 (lifetime) и ssh-add -c (confirm). Ограничение maxsign в CLI не выставлено, но протокол его поддерживает: если нужно ограничить число операций, это делается через прямое сообщение.

Практический вывод для защиты: -c — единственное ограничение, которое замечает владелец в момент атаки, потому что требует его участия. -t ограничивает окно, но не мешает использовать ключ, пока окно открыто.

Перехват агента: что реально даёт сокет

Кто может подключиться

Правила простые и жёсткие: connect к UNIX-сокету проверяется по правам на файл сокета. Если сокет 0600 alice:alice, подключиться может только alice и root. Если 0666 — кто угодно. Если каталог, в котором лежит сокет, доступен на запись другому пользователю, он может удалить сокет и создать свой на том же месте — это уже подмена, а не перехват.

Отсюда три сценария, которые стоит различать:

1. Свой пользователь, чужой процесс. Если злоумышленник уже работает как alice (украл сессию, получил RCE в её процессе), сокет агента для него открыт: он подключается и подписывает. Никаких дополнительных прав не нужно.
2. Root на бастионе. Root игнорирует права файлов и подключается к любому сокету. Проброшенный агент на бастионе означает, что root бастиона получает подписи от имени администратора.
3. Сосед по системе с правом записи в каталог. Может подменить сокет: удалить и создать свой. Дальше администратор думает, что говорит с агентом, а на самом деле — с поддельным.

Проверка доступных сокетов:

find /tmp /run/user -maxdepth 3 -type s -name 'agent.*' 2>/dev/null
ls -ld /tmp/ssh-* 2>/dev/null

/tmp/ssh-9Xy2ab7Q/agent.1847
/run/user/1000/keyring/ssh
drwx------ 2 alice alice 4096 окт 19 18:10 /tmp/ssh-9Xy2ab7Q

ssh-add -l на чужом сокете

Самый простой способ проверить, что сокет живой и что в нём есть, — направить переменную на него:

SSH_AUTH_SOCK=/tmp/ssh-9Xy2ab7Q/agent.1847 ssh-add -l

256 SHA256:Zx9...Kq1 alice@workstation (ED25519)
4096 SHA256:Ab4...7Fc deploy@nsu (RSA)

Если команда вывела список — доступ есть. Если Could not open a connection to your authentication agent — сокет не тот, не живой или прав не хватает. Разница между этими двумя ответами и есть результат проверки.

Дальше — использование. Два способа: переменная окружения (наследуется ssh и git) или опция IdentityAgent:

SSH_AUTH_SOCK=/tmp/ssh-9Xy2ab7Q/agent.1847 ssh -o IdentitiesOnly=no deploy@192.0.2.10
ssh -o IdentityAgent=/tmp/ssh-9Xy2ab7Q/agent.1847 deploy@192.0.2.10

Второй способ удобнее для скриптов: он не меняет окружение и действует только на одну команду.

Границы приёма

Перехват работает, пока выполняются три условия: сокет существует, ключ в нём загружен, доступ к сокету есть. Каждое условие можно сломать:

• время жизни: ssh-add -t выгружает ключ, и сокет становится бесполезным;
• подтверждение: ssh-add -c требует участия владельца при каждой подписи;
• изоляция: сокет в /run/user/<uid> с 0700 и без проброса на чужие хосты недоступен снаружи;
• отсутствие проброса: без -A и без -R на сервере нет сокета, который можно перехватить.

Отсюда практическое правило: самый опасный сценарий — не «украли ключ», а «оставили проброс на хосте, куда может попасть кто-то ещё». Ключ при этом остаётся на рабочей станции, а доступ — уже нет.

Чтение utmp программой: те же поля, но без утилиты

utmpdump удобен, но он не единственный способ. Любая программа может прочитать те же записи через getutxent — и это полезно, когда нужно отфильтровать сессии по пользователю или собрать статистику.

/* readutmp.c — печатает записи utmp с расшифровкой полей */
#include <stdio.h>
#include <time.h>
#include <utmpx.h>

int main(void)
{
    struct utmpx *u;
    setutxent();
    while ((u = getutxent()) != NULL) {
        char t[32];
        time_t sec = (time_t)u->ut_tv.tv_sec;
        strftime(t, sizeof t, "%Y-%m-%d %H:%M:%S", localtime(&sec));
        printf("type=%d pid=%d line=%-8.8s user=%-12.12s host=%-20.20s %s\n",
               u->ut_type, u->ut_pid, u->ut_line, u->ut_user, u->ut_host, t);
    }
    endutxent();
    return 0;
}

gcc -O2 -Wall -Wextra -o readutmp readutmp.c
./readutmp | head -6

type=2 pid=0 line=~        user=reboot       host=7.2.4-zen2-1-zen     2026-10-19 14:27:48
type=7 pid=1501 line=tty1     user=noviui       host=                     2026-10-19 14:29:11
type=7 pid=1680 line=pts/0    user=noviui       host=:1                   2026-10-19 14:29:14
type=7 pid=3177 line=pts/1    user=noviui       host=:1                   2026-10-19 14:29:36
type=7 pid=44979 line=pts/2    user=noviui       host=:1                   2026-10-19 17:22:10
type=7 pid=3352 line=pts/3    user=noviui       host=:1                   2026-10-19 14:29:40

Читается так: type=2 — перезагрузка, и в поле host у неё лежит версия ядра; type=7 — вход пользователя, host=:1 означает локальную графическую сессию (дисплей :1), пустой host — консоль. Именно это различие важно при разборе: :0/:1 — локальный вход, IP-адрес — удалённый, пусто — консоль или неизвестно.

systemd-logind: сессии и их области

На системах с systemd параллельно с utmp ведётся реестр сессий logind. Он отвечает на вопрос «какие сессии активны и кто их лидер»:

loginctl list-sessions
loginctl show-session 2 -p Remote -p Type -p Active -p Leader

SESSION  UID USER   SEAT  LEADER CLASS   TTY  IDLE SINCE
      2 1000 noviui seat0 1428   user    tty1 no   -
      3 1000 noviui -     1437   manager -    no   -

Remote=no
Type=tty
Active=yes
Leader=1428

Поле Remote — прямой ответ на вопрос «локально или по сети»: yes означает удалённую сессию, и это надёжнее, чем ut_host, потому что заполняется самим logind. Поле Leader — PID ведущего процесса сессии, по нему видно, что именно запустило сессию (sshd, login, gdm).

Для разведки это ещё один источник: loginctl показывает сессии, которых может не быть в utmp (например, сессии manager без терминала), и даёт привязку к cgroup, а через неё — к процессам.

authorized_keys и ограничения на ключ

Последний артефакт в ~/.ssh/ — authorized_keys, но он интересен не содержимым (открытые ключи не секрет), а опциями перед ключом. Они показывают, что администратор пытался ограничить:

grep -oE '^(command="[^"]*"|from="[^"]*"|no-pty|no-port-forwarding|permitopen="[^"]*"|restrict)' ~/.ssh/authorized_keys | sort | uniq -c

      2 command="/usr/local/bin/backup.sh"
      1 from="192.0.2.0/24"
      3 no-port-forwarding

command= означает, что ключ может выполнить только указанную команду; from= ограничивает адреса; no-port-forwarding запрещает проброс. Если в файле есть ключи без опций, они дают полный доступ — и именно они интересны в первую очередь.

Обнаружение и защита

Что видит защитник

Журнал sshd. Строка Accepted publickey for alice from 192.0.2.45 port 51234 ssh2: ED25519 SHA256:... фиксирует вход по ключу: время, пользователь, адрес, отпечаток. Если один и тот же ключ используется с двух разных адресов одновременно — это признак перехвата или кражи.

wtmp. Запись USER_PROCESS с ut_host, не совпадающим с ожидаемым, — повод сверить с journalctl _COMM=sshd.

lsof и ss. Кто держит сокет открытым:

lsof -U 2>/dev/null | grep -E 'ssh|agent' | head
ss -xl 2>/dev/null | grep -E 'ssh|agent' | head

audit и eBPF. Подключение к UNIX-сокету не логируется audit по умолчанию ⁸, но его видно в eBPF-трейсере на sys_enter_connect с фильтром по AF_UNIX и пути сокета. Для сервера с пробросом агента такое правило даёт список всех, кто подключался к агенту:

sudo bpftrace -e 'tracepoint:syscalls:sys_enter_connect /comm == "ssh"/ { printf("%s pid=%d\n", comm, pid); }'

Одна строка — и видно, что ssh подключается к сокету агента. Если к сокету подключается процесс с другим именем (python3, ssh-add), это повод разобраться.

Признаки на стороне артефактов. Чужой сокет в /tmp с датой создания, не совпадающей с сессией; SSH_AUTH_SOCK в /proc/<pid>/environ у процесса, который не является оболочкой; записи в known_hosts, которых не должно быть.

Матрица «приём — признак — контрмера»

Защита: ProxyJump вместо проброса

Фундаментальное решение — не пробрасывать агент вообще. ProxyJump (OpenSSH 7.3+) делает бастион чистым TCP-прокси ¹: аутентификация на целевом хосте идёт с рабочей станции, на бастионе сокет не создаётся.

Host bastion
    HostName bastion.nsu.example
    User alice
    ForwardAgent no

Host db-internal
    HostName 192.0.2.10
    User deploy
    ProxyJump bastion

ssh db-internal

На бастионе при этом не появляется ни SSH_AUTH_SOCK, ни /tmp/ssh-*, ни ключей. Проверить это можно, зайдя на бастион и выполнив find /tmp -name 'agent.*'.

Дополнительные меры: AllowAgentForwarding no в sshd_config (запрещает проброс всем), PermitOpen для ограничения целей, ssh-add -t и -c для ограничения времени и подтверждения, права 0700 на ~/.ssh и 0600 на ключи, отключение HashKnownHosts no там, где важна приватность.

Гигиена истории

Три правила, которые снижают утечку через историю: не передавать секреты в аргументах (mysql -p без пароля, read -s, файлы 0600), включать HISTCONTROL=ignorespace и ставить пробел перед чувствительной командой, чистить историю осознанно (history -c, shred -u, HISTFILE=/dev/null для одноразовой сессии).

export HISTCONTROL=ignorespace:ignoredups
export HISTIGNORE='ls:cd:pwd:exit'

Важно понимать, что чистка истории — это анти-форензика, а не защита: она не убирает следы из journalctl, wtmp, audit и eBPF. Подробно об этом — в теме 06.

Практика: разбор одной сессии от начала до конца

Соберём всё вместе на учебном примере. Дано: сервер nsu-bastion, пользователь alice, подозрение, что ночью кто-то работал под её учётной записью. Задача — восстановить хронологию и понять, что было сделано.

Шаг 1. Кто входил. last -F -n 20 показывает сессии, lastb — неудачные попытки, loginctl list-sessions — активные сейчас. Из last берём интервалы: 02:11–02:47 и 03:05–03:12.

Шаг 2. Чем входили. journalctl _COMM=sshd за этот интервал. Если видим Accepted publickey — вход по ключу; Accepted password — по паролю; session opened for user alice без Accepted — вход через su или локальную консоль. Способ входа определяет, что искать дальше: при входе по ключу сокет агента мог быть проброшен, при входе по паролю — нет.

Шаг 3. Что делали. stat по артефактам: .bash_history (mtime 02:47), .viminfo (mtime 02:44), .mysql_history (mtime 02:45). Совпадение говорит, что все три файла обновлялись в одну сессию. Читаем историю, разворачиваем метки, смотрим интервалы.

Шаг 4. Куда ходили. known_hosts и .ssh/config дают список хостов; journalctl по sshd на этих хостах — были ли входы с адреса бастиона в те же минуты. Если были — сессия использовалась для горизонтального перемещения.

Шаг 5. Что осталось в сокетах. find /tmp -name 'agent.*' -type s и ls -l на них: если сокет создан в 02:11 и жив до сих пор, значит сессия не закрыта, а ключ всё ещё в памяти. SSH_AUTH_SOCK=<путь> ssh-add -l покажет, что в нём.

Шаг 6. Сводка. Таблица, которая и есть результат разбора:

Такой таблицы достаточно, чтобы ответить на три вопроса: кто, когда и что. Всё остальное — детали, которые добавляются по мере необходимости.

Ограничения разбора и типичные ошибки

Ошибка первая: считать atime доказательством чтения. relatime обновляет метку не всегда, mmap и sendfile могут не обновлять вовсе, а noatime отключает её полностью. atime — вспомогательный признак.

Ошибка вторая: считать, что в истории всё. Неинтерактивные команды, скрипты, задания cron и ssh host command в историю не попадают. Отсутствие команды в истории не означает, что её не было.

Ошибка третья: путать ctime и mtime. ctime меняется при любом изменении метаданных, включая chmod и chown, но не означает изменения содержимого. Обратное тоже верно: изменение содержимого обновляет и mtime, и ctime, поэтому «ctime свежее mtime» — признак вмешательства, а не наоборот.

Ошибка четвёртая: доверять ut_host как признаку удалённости. Локальная графическая сессия даёт :0/:1, консоль — пустое поле, и только IP означает сеть. Для точного ответа нужен loginctl show-session -p Remote.

Ошибка пятая: считать, что known_hosts даёт имена. При HashKnownHosts yes имена захешированы, и восстановление — отдельная задача. Проверять надо ssh-keygen -F, а не grep по файлу.

Ошибка шестая: думать, что агент проверяет клиента. Он проверяет только права на сокет. Если сокет доступен — доступен и ключ, и никакие «настройки безопасности агента» этого не меняют.

Эти шесть ошибок покрывают большинство неверных выводов в разборах; каждая из них — следствие того, что механизм понят не до конца, а команда выучена.

Итоги темы

Артефакты пользователя — самый дешёвый источник данных о системе: история команд даёт учётные данные и карту хостов, .viminfo — файлы и фрагменты текста, клиентские журналы — SQL и токены, known_hosts и .ssh/config — топологию сети. Всё это лежит в домашнем каталоге с правами, которые защищают от соседа, но не от root и не от того, кто уже получил доступ.

Хронология восстанавливается сопоставлением четырёх источников: stat по артефактам, метки #<эпоха> в истории, записи wtmp через utmpdump/last, строки Accepted в журнале sshd. Ключевые ограничения: atime врёт из-за relatime, история не содержит неинтерактивных команд, wtmp не различает способ аутентификации — всё это надо держать в голове, чтобы не строить ложных выводов.

Агент SSH устроен так, что подпись получает любой, кто имеет доступ к сокету: протокол — это два сообщения (11/12 для списка, 13/14 для подписи), а права проверяет ядро по файлу сокета. Отсюда правило: проброс агента на недоверенный хост равносилен передаче права подписи, а ProxyJump решает проблему архитектурно — на бастионе просто нет сокета.

Дальше — тема 03: SUID-биты, capabilities и то, как легально выданные полномочия превращаются в root.

Литература

1. Barrett D. J., Silverman R. E., Byrnes R. G. SSH, The Secure Shell: The Definitive Guide. 2nd ed. — O'Reilly Media, 2005.
2. OpenSSH Manual Pages. — https://www.openssh.com/manual.html
3. Nemeth E., Snyder G., Hein T. R., Whaley B., Mackin D. UNIX and Linux System Administration Handbook. 5th ed. — Addison-Wesley, 2017.
4. Free Software Foundation. GNU Bash Reference Manual. — https://www.gnu.org/software/bash/manual/
5. The Linux man-pages project. — https://man7.org/linux/man-pages/
6. Kerrisk M. The Linux Programming Interface. — No Starch Press, 2010.
7. NIST SP 800-86. Guide to Integrating Forensic Techniques into Incident Response. — 2006.
8. MITRE ATT&CK: Linux techniques. — https://attack.mitre.org/

Дополнительные материалы

Вопросы для самопроверки

1. Почему файл .bash_history по умолчанию не обновляется мгновенно в момент ввода команды в терминале?
2. Какая системная переменная позволяет включить сохранение временных меток для каждой команды в Bash и каков её формат?
3. В каких случаях команда, введённая пользователем, гарантированно не попадёт в историю при значении HISTCONTROL=ignorespace?
4. Какие конфиденциальные артефакты можно извлечь из файла .viminfo, если сам редактируемый файл уже удалён или закрыт правами доступа?
5. Почему файлы истории клиентов СУБД (.mysql_history, .psql_history) несут повышенный риск для безопасности по сравнению с историей оболочки?
6. Каким образом утилита stat позволяет отличить время изменения содержимого файла (mtime) от времени изменения его метаданных (ctime)?
7. Какая системная база данных хранит информацию о текущих активных сессиях пользователей и какая утилита используется для её чтения?
8. В чём заключается принципиальное отличие протокола взаимодействия с ssh-agent от прямого использования закрытого ключа с диска?
9. Почему наличие прав суперпользователя (root) на сервере позволяет перехватить любой проброшенный сокет ssh-agent?
10. Какие угрозы несёт включение опции ForwardAgent yes при подключении к недоверенному серверу или серверу с коллективным доступом?
11. Как директива ProxyJump в ~/.ssh/config устраняет риск компрометации сокета агента на промежуточном сервере?
12. Какое действие выполняет флаг -c при добавлении ключа в агент через ssh-add?

Глоссарий темы

Шпаргалка

Команды анализа артефактов и журналов

# Просмотр последних команд истории с номерами строк
history 20

# Отображение метаданных файла (mtime, ctime, atime)
stat -c "Файл: %n | mtime: %y | ctime: %z" ~/.bash_history

# Просмотр истории входов конкретного пользователя с полными датами
last -F admin

# Отображение активных сессий и исполняемых ими процессов
w -u

# Поиск незахэшированных хостов в базе известных серверов
grep -v '^|1|' ~/.ssh/known_hosts

# Поиск ключевых слов (пароли, токены) в истории vim
grep -E 'PASS|SECRET|TOKEN|KEY' ~/.viminfo

Команды управления ssh-agent

# Запуск нового изолированного агента и экспорт переменных в текущую оболочку
eval "$(ssh-agent -s)"

# Просмотр загруженных в агент открытых ключей и отпечатков
ssh-add -l

# Добавление ключа с ограничением времени жизни (например, 1 час)
ssh-add -t 3600 ~/.ssh/id_ed25519

# Добавление ключа с обязательным запросом подтверждения при каждом использовании
ssh-add -c ~/.ssh/id_ed25519

# Поиск сокетов агента в общесистемных временных каталогах
find /tmp/ -name "agent.*" -type s 2>/dev/null

# Удаление всех ключей из памяти текущего агента
ssh-add -D

# Завершение работы текущего агента
ssh-agent -k

Типичные ошибки

1. Передача паролей в аргументах утилит командной строки

   • Симптом: Команда вида mysql -u root -pMyPassword или curl -u admin:Secret оседает в открытом виде в ~/.bash_history и видна в ps aux.
   • Причина: Непонимание того, что аргументы командной строки являются публичной информацией в рамках ОС и протоколируются историей.
   • Как исправить: Использовать приглашение на ввод пароля (-p без аргумента), считывать пароли через read -s или настраивать конфигурационные файлы с правами 0600 (~/.my.cnf).

2. Использование ForwardAgent yes по умолчанию в ~/.ssh/config

   • Симптом: При подключении к любому серверу на нём создаётся сокет SSH_AUTH_SOCK, доступный привилегированным пользователям этого сервера.
   • Причина: Включение глобальной директивы ForwardAgent yes для секции Host *.
   • Как исправить: Полностью отказаться от ForwardAgent в пользу ProxyJump или ограничивать проброс строго единичными доверенными хостами.

3. Очистка истории через rm ~/.bash_history в активной сессии

   • Симптом: После удаления файла при закрытии терминала он создаётся заново со всеми командами текущей сессии.
   • Причина: Оболочка Bash удерживает историю в оперативной памяти и производит сброс буфера на диск в момент выполнения exit.
   • Как исправить: Очищать буфер памяти перед выходом: history -c && history -w или временно отключать запись: unset HISTFILE.

4. Оставление бессрочных ключей в работающем ssh-agent

   • Симптом: Ключи суперпользователя остаются в оперативной памяти фонового процесса неделями после завершения непосредственной работы.
   • Причина: Вызов ssh-add без параметров времени жизни -t.
   • Как исправить: Всегда указывать предельное время хранения: ssh-add -t 1800 (30 минут) и выгружать ключи по окончании работ (ssh-add -D).

5. Игнорирование прав на родительские каталоги сокетов

   • Симптом: Сокет агента в /tmp/ создан с правами 0700, но родительский каталог имеет открытые права или предсказуемое имя.
   • Причина: Ручное создание сокетов скриптами автоматизации в общедоступных каталогах.
   • Как исправить: Использовать стандартные пользовательские каталоги systemd (/run/user/<UID>/) или создавать каталоги через mktemp -d с правами 0700.

Что почитать и посмотреть

• man 1 bash на https://man7.org/linux/man-pages/man1/bash.1.html — раздел «HISTORY», подробная документация по управлению историей команд, переменным HISTCONTROL и раскрытию событий истории.
• man 1 ssh-agent и man 1 ssh-add на https://www.openssh.com/manual.html — официальное справочное руководство OpenSSH по управлению демоном ключей, флагам подтверждения -c и ограничению времени -t.
• Barrett D. J., Silverman R. E., Byrnes R. G. SSH, The Secure Shell: The Definitive Guide. 2nd ed. — O'Reilly Media, 2005. Глава 6 («Advanced Client Configuration») подробно рассматривает риски Agent Forwarding и архитектуру сокетов.
• Nemeth E., Snyder G. et al. UNIX and Linux System Administration Handbook. 5th ed. — Addison-Wesley, 2017. Глава 14 («Security») разбирает аудит сессий администраторов, системные журналы wtmp и управление правами доступа.
• OverTheWire Bandit на https://overthewire.org/wargames/bandit/ — практическая площадка для тренировки поиска артефактов пользователя, скрытых паролей и анализа системных файлов Linux.
• OpenSSH Legacy and Deprecated Features на https://www.openssh.com/security.html — бюллетени безопасности разработчиков OpenSSH о рисках проброса агента и переходе на ProxyJump.

Карта артефактов: что где лежит и что даёт

Таблица читается как чек-лист: если при разборе не проверен хотя бы один источник из левой колонки, вывод может быть неполным. Особенно часто забывают .netrc (потому что он не «история») и authorized_keys (потому что ключи «не секрет»).

Агент SSH в сравнении с другими хранилищами

ssh-agent — не единственный способ держать ключи разблокированными. Понимание альтернатив помогает объяснить, почему «мы пользуемся keyring» не решает проблему.

ssh-agent — отдельный процесс, протокол по UNIX-сокету, ключи в памяти. Права проверяются по файлу сокета. Проброс — через -A/-R.

gnome-keyring/kwallet — хранилища секретов с D-Bus-интерфейсом; ssh-agent может быть их «прослойкой» (как в /run/user/<uid>/keyring/ssh). Плюс: блокировка при блокировке экрана. Минус: тот же сокет и те же права.

gpg-agent — аналог для GPG-ключей, с собственным протоколом (Assuan) и сокетом S.gpg-agent. Принцип тот же: обладание сокетом даёт подпись.

Аппаратные токены (FIDO2, smartcard) — ключ не покидает устройство, подпись требует физического присутствия и PIN. Это единственный вариант, где «украсть сокет» недостаточно: нужен ещё и токен.

Вывод: любой агент — это компромисс между удобством и тем, что подпись доступна процессам с доступом к сокету. Аппаратный токен сдвигает границу с «кто имеет доступ к файлу» на «кто имеет доступ к устройству и знает PIN».

Как устроен клиент агента на C

Python-клиент из теории хорош для понимания, но в реальной работе чаще пишут на C — хотя бы потому, что libssh и OpenSSH используют именно такой код. Минимальный клиент выглядит так:

/* agent_min.c — запрос списка ключей у ssh-agent */
#define _GNU_SOURCE
#include <arpa/inet.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/socket.h>
#include <sys/un.h>
#include <unistd.h>

static int read_full(int fd, void *buf, size_t n)
{
    size_t got = 0;
    while (got < n) {
        ssize_t r = read(fd, (char *)buf + got, n - got);
        if (r <= 0)
            return -1;
        got += (size_t)r;
    }
    return 0;
}

int main(void)
{
    const char *path = getenv("SSH_AUTH_SOCK");
    if (!path) {
        fprintf(stderr, "SSH_AUTH_SOCK не задан\n");
        return 1;
    }

    int fd = socket(AF_UNIX, SOCK_STREAM, 0);
    if (fd < 0) { perror("socket"); return 1; }

    struct sockaddr_un sa = {0};
    sa.sun_family = AF_UNIX;
    snprintf(sa.sun_path, sizeof sa.sun_path, "%s", path);
    if (connect(fd, (struct sockaddr *)&sa, sizeof sa) != 0) {
        perror("connect");
        return 1;
    }

    uint32_t len = htonl(1);
    unsigned char msg[5] = {0};
    memcpy(msg, &len, 4);
    msg[4] = 11;                       /* SSH2_AGENTC_REQUEST_IDENTITIES */
    if (write(fd, msg, 5) != 5) { perror("write"); return 1; }

    uint32_t rlen = 0;
    if (read_full(fd, &rlen, 4) != 0) { perror("read len"); return 1; }
    rlen = ntohl(rlen);
    unsigned char *body = malloc(rlen);
    if (!body || read_full(fd, body, rlen) != 0) { perror("read body"); return 1; }

    printf("тип ответа: %u, байт: %u\n", body[0], rlen);
    free(body);
    close(fd);
    return 0;
}

Сборка: gcc -O2 -Wall -Wextra -o agent_min agent_min.c. Запуск с SSH_AUTH_SOCK от стенда даёт тип ответа: 12. Дальше разбор тела — та же арифметика, что в Python: счётчик, затем пары «блоб, комментарий».

Зачем это знать: клиент агента — это двадцать строк, а не «магия OpenSSH». Любой процесс, у которого есть доступ к сокету, может написать такой клиент за пять минут, и защита «мы используем агент» от этого не спасает.

Что делать, если найден чужой сокет

Порядок действий при разборе инцидента:

1. Не убивать процесс. Сначала lsof -U | grep <путь> и ls -l /proc/<pid>/fd, чтобы понять, кто создал сокет.
2. Снять копию окружения. tr '\0' '\n' < /proc/<pid>/environ — там SSH_AUTH_SOCK и другие переменные.
3. Проверить, что в агенте. SSH_AUTH_SOCK=<путь> ssh-add -l — список ключей и комментарии; по комментариям видно, чьи это ключи.
4. Проверить журналы входов. journalctl _COMM=sshd на целевых хостах — были ли входы по этим ключам в подозрительное время.
5. Оценить проброс. Если сокет лежит в /tmp/ssh-*, значит использовался -A или -R; искать, откуда пришло соединение (journalctl, ss, audit).
6. Закрыть. ssh-add -D для отзыва ключей из агента, перезапуск сессии, удаление сокета; затем — смена ключей, если есть подозрение на использование.

Порядок важен: если начать с удаления, не останется данных для ответа на вопрос «что успели сделать».

Вопросы для самопроверки

1. Почему история bash не содержит команд, выполненных в скрипте?
2. Чем histappend меняет картину «чья история осталась»?
3. Какие три секции .viminfo дают больше всего и почему?
4. Почему .netrc считают конфигурацией, а не артефактом, и почему это опасно?
5. Что означает |1| в начале строки known_hosts?
6. Чем ctime отличается от mtime и как это использовать при разборе?
7. Почему relatime делает atime ненадёжным?
8. Что означает type=7 в utmp и какие поля заполнены у такой записи?
9. Почему last не показывает способ аутентификации, а journalctl показывает?
10. Какой байт в сообщении агента определяет тип, и почему длина идёт первой?
11. Почему ssh-add -c — единственное ограничение, которое замечает владелец?
12. Почему аппаратный токен меняет модель угрозы для агента?

Лабораторная работа 2. Тень админа

• Раздел курса: апокриф 2 «История грехов и перехват агента SSH»

Введение

Работа состоит из восьми частей и повторяет порядок реального разбора: сначала собрать артефакты, потом выстроить хронологию, потом проверить, что из этого даёт доступ. Стенд разворачивается в отдельном каталоге и не трогает систему: домашний каталог учебного пользователя с историей, файлами редактора, клиентскими журналами и ключами, плюс запущенный ssh-agent с демонстрационным ключом.

Первые пять частей — про чтение. Читатель разбирает историю команд с метками времени, секции .viminfo, журналы клиентов, known_hosts и authorized_keys, затем переходит к меткам inode и журналам входов. Шестая и седьмая — про агент: протокол на уровне сообщений (список ключей и подпись), затем сокет, права и проброс. Восьмая — поиск ошибок в разборщике истории и обнаружение по журналам.

Стенд намеренно содержит ошибку конфигурации: сокет агента создаётся с правами 0666 в каталоге 0777. Это моделирует ситуацию, которую в реальной жизни создают неаккуратной настройкой, и позволяет показать перехват без root. На настоящей машине такие права — уже инцидент.

Цель работы

После выполнения работы получится:

• разворачивать стенд и объяснять, какие артефакты остаются после сессии;
• разбирать историю bash с метками #<эпоха> и объяснять, почему живая сессия не видна в файле;
• читать секции .viminfo и объяснять, что дают метки файлов и регистры;
• находить known_hosts, authorized_keys и ~/.ssh/config и читать ограничения на ключи;
• сопоставлять stat, историю и wtmp и строить хронологию сессии;
• читать utmp/wtmp через utmpdump и через getutxent;
• объяснять протокол агента на уровне сообщений 11/12 и 13/14 и писать клиента;
• показывать перехват агента через сокет и объяснять, почему ProxyJump его исключает;
• находить ошибки в разборщике истории и формулировать признаки перехвата для защитника.

Теоретический минимум

Нужны разделы «История команд: как bash её пишет и что она выдаёт», «Остальные артефакты», «Временные метки и восстановление хронологии», «utmp, wtmp, btmp» и «ssh-agent: протокол, сокет и проброс» темы 2. Дополнительно используются темы 1 (окружение), 4 (права), 7 (процессы и /proc) и 11 (SSH) основной программы.

Перечень оснащения

Linux (Ubuntu 24.04, Debian 12 или Arch), openssh-client, openssh-server (для проверки журналов), gcc, make, python3, util-linux, lsof, bpftrace (для продвинутой части).

sudo apt update && sudo apt install -y openssh-client gcc make python3 util-linux lsof bpftrace

Архив окружения lr-env содержит setup-env.sh, cleanup-env.sh, parse_artifacts.sh, hist_time.py, buggy_hist.py, agent_list.py, agent_sign.py, readutmp.c и Makefile. Распакуйте в ~/lab-apocrypha-02 и разверните стенд:

cd ~/lab-apocrypha-02
make env

[*] каталоги
[*] история команд с метками времени
[*] .viminfo: метки файлов и регистры
[*] журналы клиентов
[*] ssh: known_hosts, config, authorized_keys
[*] ключ и агент

[+] стенд готов
    домашний каталог: /home/alice/lab-apocrypha-02/target_home
    сокет агента:     /home/alice/lab-apocrypha-02/tmp/agent.sock
    переменная для работы: export SSH_AUTH_SOCK=/home/alice/lab-apocrypha-02/tmp/agent.sock

Экспортируйте переменную — она нужна для частей 6 и 7:

export SSH_AUTH_SOCK=$PWD/tmp/agent.sock

Порядок выполнения работы

Части идут от чтения к доступу: 1–2 — артефакты и история, 3 — редакторы и клиенты, 4 — метки времени, 5 — журналы входов, 6–7 — агент, 8 — ошибки и обнаружение. В каждой части сначала предсказание, потом команда, потом объяснение.

Правила: работать только в каталоге стенда, не трогать настоящий ~/.bash_history (для экспериментов с историей задавайте HISTFILE явно), не запускать ssh-agent поверх системного, после работы выполнить ./cleanup-env.sh. Сокет стенда с правами 0666 — учебная уязвимость, а не рекомендация.

Часть 1. Стенд и инвентаризация артефактов

Задание

1. Разверните стенд и посмотрите, какие файлы созданы.
2. Запустите ./parse_artifacts.sh target_home и разберите сводку.
3. Предскажите, в каких файлах есть секреты и сколько их.
4. Проверьте предсказание и объясните, почему в .mysql_history пароль есть, а в .bash_history — только один.

make env
ls -la target_home target_home/.ssh
./parse_artifacts.sh target_home

------------------------------------------------------------
ФАЙЛЫ И МЕТКИ
------------------------------------------------------------
  file                         size  mtime                ctime
  .bash_history                 289  2026-10-19 18:14:49  2026-10-19 18:14:49
  .viminfo                      422  2026-10-19 18:14:49  2026-10-19 18:14:49
  .mysql_history                322  2026-10-19 18:14:49  2026-10-19 18:14:49
  ...
------------------------------------------------------------
ПОИСК СЕКРЕТОВ
------------------------------------------------------------
  .bash_history            совпадений: 1
  .mysql_history           совпадений: 1
  .psql_history            совпадений: 1
  .python_history          совпадений: 1
  .netrc                   совпадений: 2
------------------------------------------------------------
SSH
------------------------------------------------------------
  хостов в known_hosts: 3
  захешированных строк: 0
  ключей с ограничениями: 2
  ключей без ограничений: 1

Что должно получиться

Объяснение: артефактов больше, чем «история и ключи» — есть журналы двух СУБД, Python, less, wget и .netrc с паролями в открытом виде. В known_hosts три хоста, хеширование выключено, поэтому имена видны. В authorized_keys три ключа, из них два с ограничениями (command=, from=) и один без — именно он даёт полный доступ.

Часть 2. История команд и метки времени

Задание

1. Предскажите, что покажет hist_time.py для target_home/.bash_history.
2. Запустите и проверьте.
3. Объясните, почему все команды имеют разные метки, а не одну.
4. Проведите эксперимент с histappend: откройте две оболочки с общим HISTFILE, выполните по команде, закройте в разном порядке — и посмотрите, чья история осталась.

./hist_time.py target_home/.bash_history
export HISTFILE=$PWD/tmp/hist_exp
export HISTTIMEFORMAT='%F %T '
bash --norc -i

2023-10-19 13:15:00 UTC  vim /etc/nginx/sites-available/default
2023-10-19 13:17:00 UTC  systemctl reload nginx
2023-10-19 13:18:30 UTC  cat /opt/backup/credentials.env
2023-10-19 13:22:00 UTC  mysql -u root -p'SuperSecretP@ss2026' -h 192.0.2.10
2023-10-19 13:28:20 UTC  ssh -A admin-deploy@db-primary.nsu.example

Что должно получиться

Разбор: метки разнесены на минуты, потому что команды вводились вручную; команда ssh -A — прямое указание на проброс агента, который разбирается в части 7; mysql -p'...' — пароль в аргументах, то есть он был виден и в ps, и в истории.

Эксперимент с histappend: без shopt -s histappend файл после закрытия второй оболочки содержит только её команды — первая история потеряна. С histappend остаются обе, но без указания, какая команда из какой сессии. Это объясняет, почему в реальной истории команды разных людей могут перемешиваться.

Часть 3. .viminfo, клиентские журналы и .netrc

Задание

1. Извлеките из .viminfo секцию меток файлов и секцию регистров.
2. Объясните, что даёт каждая секция для разведки.
3. Посмотрите .netrc и объясните, почему этот файл опаснее истории.
4. Проверьте authorized_keys на ограничения и объясните, какой ключ самый опасный.

sed -n '/# File marks:/,/^$/p' target_home/.viminfo
sed -n '/# Registers:/,/^$/p' target_home/.viminfo
cat target_home/.netrc
awk '{print $1, $2}' target_home/.ssh/authorized_keys | head -5

# File marks:
'0  14  0  /etc/nginx/sites-available/default
'1  1   0  /opt/backup/credentials.env
'2  82  12  /etc/postgresql/16/main/pg_hba.conf
'3  5   0  ~/scripts/deploy-api.sh

# Registers:
""1	LINE	0
	API_KEY="sec_984f7b2a9e1041cd"
	DB_PASSWORD="pg_cluster_secret_token"

machine ftp.nsu.example login backup password B@ckup_2026
machine vault.nsu.example login deploy password VaultDeploy_2026

Что должно получиться

Объяснение: метки файлов дают список открытых файлов (в том числе тех, о которых не писали в терминале), регистры — фрагменты скопированного текста, включая ключи. .netrc опаснее истории, потому что это не след, а действующая конфигурация: пароли в нём актуальны, пока их не сменили, и они лежат в открытом виде.

authorized_keys: ключ с command= ограничен одной командой, с from= — одним диапазоном адресов, третий — без ограничений, значит даёт полноценный вход. Именно его ищут первым.

Часть 4. Метки inode и relatime

Задание

1. Предскажите, какие из четырёх меток изменятся, если изменить права файла, не трогая содержимое.
2. Проверьте на копии файла.
3. Проверьте режим монтирования корня и объясните, почему atime нельзя считать доказательством чтения.
4. Найдите в стенде файл, у которого ctime новее mtime, и объясните, что это значит.

cp target_home/.bash_history tmp/probe.txt
stat -c 'atime=%x%nmtime=%y%nctime=%z%nbtime=%w' tmp/probe.txt
chmod 640 tmp/probe.txt
stat -c 'atime=%x%nmtime=%y%nctime=%z%nbtime=%w' tmp/probe.txt
findmnt -no OPTIONS / | tr ',' '\n' | grep -E 'atime|relatime|noatime'

atime=2026-10-19 18:14:52.104110212 +0300
mtime=2026-10-19 18:14:49.881002112 +0300
ctime=2026-10-19 18:14:52.104110212 +0300
btime=2026-10-19 18:14:49.881002112 +0300
atime=2026-10-19 18:14:52.104110212 +0300
mtime=2026-10-19 18:14:49.881002112 +0300
ctime=2026-10-19 18:14:52.887311004 +0300
btime=2026-10-19 18:14:49.881002112 +0300
relatime

Что должно получиться

Разбор: chmod изменил только ctime (и atime, потому что cp читал файл), mtime остался прежним, btime не изменился вообще. Отсюда правило: ctime > mtime — признак изменения метаданных после последней записи содержимого. Режим relatime означает, что atime обновляется не при каждом чтении, а по условию, поэтому «файл не читали» по atime — не факт.

Часть 5. Журналы входов: utmp, wtmp и logind

Задание

1. Прочитайте текущие сессии через readutmp и через utmpdump.
2. Объясните, что означает type=2 и почему в поле host у перезагрузки стоит версия ядра.
3. Сопоставьте last -F с loginctl list-sessions.
4. Объясните, что означает gone - no logout и какие причины могут к этому привести.

./readutmp | head -5
utmpdump /run/utmp | head -3
last -F -n 3
loginctl list-sessions

type=2 pid=0 line=~        user=reboot       host=7.2.4-zen2-1-zen     2026-10-19 14:27:48
type=7 pid=1501 line=tty1     user=noviui       host=                     2026-10-19 14:29:11
type=7 pid=1680 line=pts/0    user=noviui       host=:1                   2026-10-19 14:29:14

SESSION  UID USER   SEAT  LEADER CLASS   TTY  IDLE SINCE
      2 1000 noviui seat0 1428   user    tty1 no   -

Что должно получиться

Разбор: type=2 — BOOT_TIME, и поле host у неё содержит строку версии ядра, а не имя хоста; type=7 — USER_PROCESS, поле host показывает :1 для локальной графической сессии и пусто для консоли. loginctl даёт Remote=no и Leader — PID ведущего процесса, по которому видно, что именно открыло сессию.

gone - no logout означает, что запись о выходе не была создана: обрыв SSH, kill -9, закрытие терминала. Для разбора это сигнал, что окончание сессии надо восстанавливать по mtime артефактов, а не по wtmp.

Часть 6. Протокол агента: список и подпись

Задание

1. Запустите agent_list.py и объясните каждое число в разборе.
2. Запустите agent_sign.py и объясните, что вернул агент.
3. Сравните вывод с ssh-add -l и объясните, почему отпечатка в протоколе нет.
4. Предскажите, что вернёт agent_sign.py, если из агента удалить все ключи.

./agent_list.py
./agent_sign.py "nsu.example challenge"
ssh-add -l

ключей в агенте: 1
  ssh-ed25519  admin-deploy@nsu.example
данные: nsu.example challenge
тип подписи: ssh-ed25519
длина подписи: 83 байт

Что должно получиться

Разбор: ответ типа 12 содержит счётчик и для каждого ключа — блоб и комментарий; блоб начинается с length-prefixed строки ssh-ed25519. Ответ типа 14 содержит подпись в формате SSH: строка типа и строка байтов; для ed25519 длина 83 байта. Отпечатка SHA256:... в протоколе нет — его считает клиент из блоба, поэтому ssh-add -l и agent_list.py показывают разные вещи.

При удалении ключей (ssh-add -D) список вернёт ключей в агенте: 0, а agent_sign.py завершится с сообщением «в агенте нет ключей».

Часть 7. Сокет, права и перехват

Задание

1. Посмотрите права на сокет и каталог стенда.
2. Объясните, что означает 0666 на сокете и 0777 на каталоге.
3. Подключитесь к сокету «как чужой» — через явную переменную и через IdentityAgent.
4. Объясните, почему на реальной машине такие права — инцидент, а не настройка.
5. Проверьте, что даёт ProxyJump вместо -A: найдите в стенде конфиг и объясните, почему на бастионе не будет сокета.

ls -ld tmp tmp/agent.sock
SSH_AUTH_SOCK=$PWD/tmp/agent.sock ./agent_list.py
ssh -o IdentityAgent=$PWD/tmp/agent.sock -o IdentitiesOnly=no -G db-internal | head -5
grep -A3 'Host bastion' target_home/.ssh/config

drwxrwxrwx 1 alice alice 4096 окт 19 18:14 tmp
srw-rw-rw- 1 alice alice    0 окт 19 18:14 tmp/agent.sock
ключей в агенте: 1
  ssh-ed25519  admin-deploy@nsu.example
Host bastion
    HostName bastion.nsu.example
    User alice
    ForwardAgent no

Что должно получиться

Объяснение: 0666 на сокете означает, что подключиться может любой пользователь системы, а 0777 на каталоге — что сокет можно удалить и подменить. Агент при этом не проверяет клиента: он отдаёт список и подписывает данные любому, кто подключился.

ProxyJump в конфиге (Host db-internal → ProxyJump bastion) означает, что на бастионе сокет не создаётся: аутентификация идёт с рабочей станции через TCP-туннель. Проверить это на реальном бастионе можно командой find /tmp -name 'agent.*' -type s — пусто.

Часть 8. Найти и исправить ошибку в разборщике

Задание

1. Сравните вывод buggy_hist.py и hist_time.py.
2. Найдите три ошибки: одна в разборе строк, одна в часовом поясе, одна в состоянии.
3. Исправьте и проверьте на файле, где есть команда, начинающаяся с #.
4. Сформулируйте, почему такие ошибки опасны при разборе инцидента.

./buggy_hist.py target_home/.bash_history | head -4
./hist_time.py target_home/.bash_history | head -4
printf '#echo not-a-comment\n#1697723000\nid\n' > tmp/hist_edge
./buggy_hist.py tmp/hist_edge

2023-10-19 16:15:00  vim /etc/nginx/sites-available/default
2023-10-19 13:15:00 UTC  vim /etc/nginx/sites-available/default
Traceback (most recent call last):
  ...
ValueError: invalid literal for int() with base 10: 'echo not-a-comment'

Что должно получаться

Исправленный разборщик: проверяет line[1:].isdigit() перед преобразованием, использует timezone.utc и сбрасывает метку, когда встречает строку, которая не является меткой и не является командой. Проверка на tmp/hist_edge: команда #echo not-a-comment должна быть напечатана как команда, а не разобрана как метка.

Опасность ошибок: неверный часовой пояс сдвигает всю хронологию на несколько часов и ломает корреляцию с wtmp; разбор #-строк как меток теряет команды; несохранённое состояние приписывает команды чужому времени. В отчёте об инциденте такая ошибка стоит дороже, чем её исправление.

Продвинутая часть (необязательно)

Настроить обнаружение перехвата агента через eBPF: трейсер на sys_enter_connect с фильтром по AF_UNIX, вывод comm, pid и пути сокета. Проверить, что при agent_list.py в выводе появляется python3, а при ssh-add -l — ssh-add. Оценить, сколько ложных срабатываний даёт правило на рабочей машине.

Дополнительные задания

1. Хеширование known_hosts и его цена. Возьмите копию файла, включите хеширование и проверьте, что поиск по имени работает только через ssh-keygen -F:

cp target_home/.ssh/known_hosts tmp/kh
ssh-keygen -H -f tmp/kh
head -2 tmp/kh
ssh-keygen -F 192.0.2.10 -f tmp/kh
grep -c '192.0.2.10' tmp/kh || echo "имя в файле не найдено — хеш работает"

Ожидаемый результат: строки начинаются с |1|, grep имени не находит, ssh-keygen -F находит. Вывод: хеширование не защищает от перебора конкретного адреса, но убирает «список хостов одним взглядом».

2. Ограничение ключа через authorized_keys. В стенде есть ключ с command=. Проверьте, как это выглядит для клиента: соберите тестовый sshd на нестандартном порту с этим файлом (или разберите конфигурацию вручную) и объясните, что произойдёт при попытке выполнить id таким ключом. Ожидаемый ответ: выполнится только /usr/local/bin/backup.sh, аргументы клиента будут проигнорированы (или переданы в SSH_ORIGINAL_COMMAND, если скрипт их читает).

3. HISTFILE=/dev/null и set +o history. Проверьте оба способа отключить запись и объясните разницу: первый отключает файл, второй — ведение истории в памяти. Что останется в системе после сессии в каждом случае?

HISTFILE=/dev/null bash --norc -i
bash --norc -i   # внутри: set +o history

4. Обратная сборка wtmp. Выгрузите wtmp в текст, отредактируйте одну строку, соберите обратно в копию и проверьте, что last -f читает её:

utmpdump /var/log/wtmp > tmp/wtmp.txt 2>/dev/null || echo "нет прав на чтение wtmp"
head -2 tmp/wtmp.txt
utmpdump -r < tmp/wtmp.txt > tmp/wtmp.bin
last -f tmp/wtmp.bin -n 2

Это упражнение — подготовка к теме 06: подделка журналов возможна, но оставляет след в mtime файла и в журнале ротации.

Разбор типичных ошибок

История не сохранилась. Причины: оболочка убита сигналом, HISTFILE указывает не туда, HISTFILESIZE мал, histappend выключен и файл перезаписан другой сессией. Проверять надо все четыре.

Метки времени сдвинуты. Bash пишет эпоху в UTC, а date -d @... печатает в локальной зоне. Если сравнивать с last, который тоже печатает локальное время, сдвиг незаметен; если сравнивать с UTC-журналом — заметен. Всегда фиксируйте, в какой зоне считаете.

atime не обновился. Ожидаемо при relatime, noatime или чтении через page cache. Не делать выводов.

known_hosts «пустой» после grep. Файл захеширован. Использовать ssh-keygen -F.

ssh-add -l не видит агент. Причины: переменная не экспортирована, сокет удалён, агент не запущен, сокет принадлежит другому пользователю. Проверять по порядку: echo $SSH_AUTH_SOCK, ls -l, ssh-add -l.

Сокет есть, но подписи нет. Ключ мог быть выгружен по -t, заблокирован (ssh-add -x) или требовать подтверждения (-c), которое некому дать. В каждом случае ответ агента будет SSH_AGENT_FAILURE (5).

utmpdump не читает btmp. Права 0600 root:root. Нужен sudo; без него — «Отказано в доступе», и это норма, а не ошибка стенда.

Журнал работы

К журналу прикладываются: вывод parse_artifacts.sh, разбор истории с метками, вывод agent_list.py и agent_sign.py, исправленный buggy_hist.py и одна таблица «время — событие — источник» для стенда.

Контрольные вопросы

1. Почему живая сессия не видна в ~/.bash_history, и что это значит для разбора?
2. Чем HISTSIZE отличается от HISTFILESIZE, и что произойдёт при переполнении каждого?
3. Что делает shopt -s histappend и как это влияет на «чью историю» вы увидите?
4. Какие три секции .viminfo дают больше всего для разведки и почему?
5. Почему .netrc опаснее истории команд, даже если оба файла с правами 0600?
6. Что означает ctime > mtime и какие действия приводят к такому состоянию?
7. Почему atime нельзя использовать как доказательство чтения файла?
8. Что означает type=2 в utmp и почему в поле host стоит версия ядра?
9. Чем loginctl show-session -p Remote точнее, чем поле ut_host?
10. Как устроено сообщение протокола агента и почему первое поле — длина?
11. Почему в ответе агента нет отпечатка ключа, а ssh-add -l его показывает?
12. Что именно проверяет ядро при подключении к UNIX-сокету агента?
13. Почему ProxyJump исключает перехват, а ForwardAgent no — только уменьшает вероятность?
14. Какие три ошибки в разборщике истории искажают хронологию?

Уборка

./cleanup-env.sh

Скрипт останавливает агент, удаляет target_home/ и tmp/ и собранный readutmp. Если вы экспортировали SSH_AUTH_SOCK в текущей оболочке, снимите переменную (unset SSH_AUTH_SOCK), чтобы не обращаться к удалённому сокету.