Кто заходил на машину: журналы входов
Где смотреть успешные и неудачные входы, как читать last, lastb и journalctl, как отследить действия через sudo и настроить хранение журналов.
Обновлено 23 августа 2026 г.
Каждый вход на машину оставляет след. Умение прочитать эти следы за пять минут отличает спокойный разбор инцидента от догадок.
Быстрый обзор
last -a -n 20
lastb -a -n 20
lastlog
who
w
last показывает успешные входы с адресами, lastb — неудачные попытки, lastlog — когда каждый пользователь заходил в последний раз. who и w показывают, кто на машине прямо сейчас.
Если в lastlog у системного пользователя вроде www-data появилась дата входа — это серьёзный повод для разбора.
Журнал systemd
journalctl -u ssh -n 100
journalctl -u ssh --since "2026-08-20" --until "2026-08-21"
journalctl _COMM=sshd | grep "Accepted"
journalctl _COMM=sshd | grep "Failed password" | tail -50
Ключевые строки:
| Строка | Значение |
|---|---|
Accepted publickey for artem | Успешный вход по ключу |
Accepted password for root | Успешный вход по паролю — повод задуматься |
Failed password for invalid user admin | Перебор несуществующих имён, фоновый шум |
Disconnected from authenticating user | Попытка оборвана |
На Debian и Ubuntu те же события дублируются в /var/log/auth.log, на AlmaLinux — в /var/log/secure.
grep "Accepted" /var/log/auth.log
grep -c "Failed password" /var/log/auth.log
Сотни неудачных попыток в сутки на публичном адресе — норма. Ненормально другое: успешный вход с адреса, которого вы не знаете. Против шума помогает fail2ban.
Что делали после входа
journalctl -t sudo -n 100
grep sudo /var/log/auth.log
cat /home/artem/.bash_history
История команд ненадёжна: её легко очистить, и она не пишется при неинтерактивных сессиях. Журнал sudo куда честнее — он ведётся системой, а не оболочкой. Ещё один довод в пользу схемы «обычный пользователь плюс sudo», описанной в статье пользователи и sudo.
Полноценный аудит на уровне ядра:
apt install -y auditd
auditctl -w /etc/passwd -p wa -k passwd_changes
ausearch -k passwd_changes
Хранение
По умолчанию журнал systemd может жить в памяти и теряться при перезагрузке. Для разбора инцидентов это плохо. Файл /etc/systemd/journald.conf:
[Journal]
Storage=persistent
SystemMaxUse=500M
MaxRetentionSec=1month
systemctl restart systemd-journald
journalctl --disk-usage
Ограничение по объёму обязательно: журнал, съевший диск, останавливает службы.
Частые ошибки
| Ошибка | Последствие | Решение |
|---|---|---|
| Журнал не сохраняется между перезагрузками | Следы теряются | Storage=persistent |
Опираются только на .bash_history | Данные легко подделать | Смотреть журнал sudo и auditd |
| Не ограничили размер журнала | Забился диск | SystemMaxUse |
| Считают шум перебора взломом | Ложная тревога | Смотреть Accepted, а не Failed |
Если нашли успешный вход с чужого адреса, журналы на самой машине уже нельзя считать надёжными: тот, кто вошёл, мог их поправить. Действуйте по статье признаки взлома и исходите из того, что машину придётся переустанавливать.