Я являюсь администратором небольшого сервера Debian Lenny, и у меня возникает такая проблема: иногда, когда сеанс SSH пользователя закрывается, запись не удаляется из /var/run/utmp, в результате чего такие сообщения от finger:
grawity@sine ~$ finger finger: /dev//pts/31: No such file or directory Login Name Tty Idle Login Time Office Office Phone user1 (user) pts/1 1d Jul 15 19:12 (foo.uk) user2 (another user) pts/33 6:25 Jul 13 12:02 (bar:S.1) user2 (another user) *pts/34 6:31 Jul 13 17:00 (bar:S.0) grawity (me) pts/25 Jul 17 11:57 (78-56-197-6:S.0) grawity (me) pts/27 Jul 17 11:57 (78-56-197-6.static.zebra.lt) Segmentation fault grawity@sine ~$ _
... а иногда даже с ошибкой или двумя. Однажды в utmp даже было две записи, указывающие на один и тот же tty (но принадлежащие разным пользователям).
Есть идеи, почему это происходит?
Пока мне удается исправить utmp (с помощью какой-то утилиты, предназначенной для стирания логов Unix:>), но это явно не решение, не когда это происходит каждый день.
Редактировать: Этот вопрос не об исчезновении записей (пока я этого не видел), а об обратном: записи не удаляются при закрытии сеанса входа в систему.
нарушение целостности пальцев - действительно плохой знак. Я бы хоть бегло проверил на предмет взлома; хотя бы запустить chkrootkit и debsums например. Во-вторых, пробовали ли вы полностью очистить utmp с помощью rm или echo -n> utmp? Он может быть поврежден каким-то незаметным образом.
Наконец, делали ли вы что-нибудь с настройкой PAM в /etc/pam.d? Это может легко привести к тому, что выход из системы не будет записан.
Связаны ли ошибочные записи с конкретными пользователями или их действиями? Это просто обычные входы по ssh или вы используете X11? Не могли бы вы проверить, есть ли у этих «фантомных пользователей» какие-то процессы? Если вы являетесь пользователем root, просмотр их .bash_history даст хоть какое-то представление о том, что они делают.
Чтобы быть параноиком, я бы, наверное, также запустил fsck. Также неплохо было бы проверить наличие руткитов и т. Д.
Является ли владелец файла utmp root: utmp и разрешения 664?
Если с разрешениями все в порядке, и это общедоступный сервер и включен доступ по ssh на общедоступном интерфейсе, это может быть связано со взломом. Ни один злоумышленник не захочет, чтобы вы знали, что он вошел в систему, поэтому имеет смысл изменить файлы utmp, btmp и wtmp. Если это так, измените пароль root, найдите руткиты / открытые порты, установите очень строгий брандмауэр, отключите прямой вход root с помощью SSH, установите denyhosts и т. Д. Но это могло быть просто параноиком. Я только что проанализировал одну попытку взлома и сделал так, чтобы злоумышленники-наблюдатели удаляли / изменяли записи btmp и wtmp. Я думаю, они делают то же самое с записями utmp.