У меня работает пять Linux-систем CentOS 6, и я столкнулся с довольно странной проблемой, которая, кажется, возникает только с моим идентификатором пользователя во всех системах Linux, которые у меня есть ... Это пример проблемы из записей, которые я исключил из lastкоманды ... ,

mpenning pts/19                        Fri Nov 16 10:32 - 10:35  (00:03)
mpenning pts/17                        Fri Nov 16 10:21 - 10:42  (00:21)
bill     pts/15       sol-bill.local   Fri Nov 16 10:19 - 10:36  (00:16)
mpenning pts/1        192.0.2.91       Fri Nov 16 10:17 - 10:49 (12+00:31)
kkim14   pts/14       192.0.2.225      Thu Nov 15 18:02 - 15:17 (4+21:15)
gduarte  pts/10       192.0.2.135      Thu Nov 15 12:33 - 08:10 (11+19:36)
gduarte  pts/9        192.0.2.135      Thu Nov 15 12:31 - 08:10 (11+19:38)
kkim14   pts/0        :0.0             Thu Nov 15 12:27 - 15:17 (5+02:49)
gduarte  pts/6        192.0.2.135      Thu Nov 15 11:44 - 08:10 (11+20:25)
kkim14   pts/13       192.0.2.225      Thu Nov 15 09:56 - 15:17 (5+05:20)
kkim14   pts/12       192.0.2.225      Thu Nov 15 08:28 - 15:17 (5+06:49)
kkim14   pts/11       192.0.2.225      Thu Nov 15 08:26 - 15:17 (5+06:50)
dspencer pts/8        192.0.2.130      Wed Nov 14 18:24   still logged in
mpenning pts/18       alpha-console-1. Mon Nov 12 14:41 - 14:46  (00:04)

Вы можете видеть две из моих записей входа в систему pts выше, с которыми не связан IP-адрес источника. У моих компьютеров CentOS шесть других пользователей, которые совместно используют системы. Примерно 10% моих логинов видят эту проблему, но никакие другие имена пользователей не проявляют такого поведения . Нет /var/log/secureзаписей для записей без исходного IP-адреса.

Вопросов

Учитывая вид сценариев, которые я держу в этих системах (которые контролируют большую часть нашей сетевой инфраструктуры), я немного испуган этим и хотел бы понять, что может привести к тому, что мои логины будут иногда пропускать адреса источника.

• Почему last -iпоказывать 0.0.0.0для pts строки записей (см. Также этот ответ )
• Есть ли что-нибудь (кроме злонамеренной деятельности), которое разумно объясняет поведение?
• Кроме метки времени в истории bash, есть ли другие способы, которые я могу сделать, чтобы отследить проблему?

информационный

С тех пор, как это начало происходить, я включил bashотметку времени в истории (то есть HISTTIMEFORMAT="%y-%m-%d %T "в .bash_profile), а также добавил несколько других взломов истории bash ; однако, это не дает подсказки к тому, что произошло во время предыдущих случаев.

Все системы работают под управлением CentOS 6.3 ...

[mpenning@typo ~]$ uname -a
Linux typo.local 2.6.32-279.9.1.el6.x86_64 #1 SMP Tue Sep 25 21:43:11 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
[mpenning@typo ~]$

РЕДАКТИРОВАТЬ

Если я использую last -i mpenning, я вижу записи, как это ...

mpenning pts/19       0.0.0.0          Fri Nov 16 10:32 - 10:35  (00:03)
mpenning pts/17       0.0.0.0          Fri Nov 16 10:21 - 10:42  (00:21)

Примечание для тех, кто пытается ответить: я не вошел в систему с помощью screenкоманды или GUI . Все мои логины из SSH; Чтобы получить награду, вы должны привести официальные ссылки, чтобы объяснитьlast -i 0.0.0.0 записи, полученные только через SSH.

РЕДАКТИРОВАТЬ 2 (для вопросов Ewwhite)

/etc/resolv.conf(обратите внимание, что я использовал .localaddrs в lastвыводе выше, чтобы скрыть информацию моей компании)

[mpenning@sasmars network]$ cat /etc/resolv.conf
nameserver 192.0.2.40
nameserver 192.0.2.60
domain mycompany.com
search mycompany.com
[mpenning@sasmars network]$

/etc/hosts info (обратите внимание, что этот настроенный файл hosts существует только на одном из компьютеров, на котором возникли эти проблемы)

[mpenning@sasmars network]$ cat /etc/hosts
127.0.0.1       localhost.localdomain localhost
192.0.2.44      sasmars.mycompany.com sasmars
::1             localhost6.localdomain6 localhost6

## Temporary kludge until I add reverse hostname mappings...
## Firewalls
192.0.2.254     a2-inet-fw1
192.0.2.253     a2-inet-fw2
192.0.2.254     a2-wan-fw1
192.0.2.253     a2-wan-fw2
192.0.2.201     a2-fab-fw1
192.0.2.202     a2-fab-fw2
192.0.2.203     t1-eds-fw1
192.0.2.42      sasvpn
192.0.2.246     sasasa1
192.0.2.10      sasoutfw1
## Wireless
192.0.2.6       saswcs1
192.0.2.2       l2wlc3
192.0.2.4       l2wlc4
192.0.2.12      f2wlc5
192.0.2.16      f2wlc6
192.0.2.14      f2wlc1
192.0.2.8       f2wlc2
[mpenning@sasmars network]$

sftpВыход из /var/log/secure*

Dec 26 10:36:37 sasmars sshd[26016]: pam_sm_authenticate: called (pam_tacplus v1.3.7)
Dec 26 10:36:37 sasmars sshd[26016]: pam_sm_authenticate: user [mpenning] obtained
Dec 26 10:36:37 sasmars sshd[26016]: tacacs_get_password: called
Dec 26 10:36:37 sasmars sshd[26016]: tacacs_get_password: obtained password
Dec 26 10:36:37 sasmars sshd[26016]: pam_sm_authenticate: password obtained
Dec 26 10:36:37 sasmars sshd[26016]: pam_sm_authenticate: tty [ssh] obtained
Dec 26 10:36:37 sasmars sshd[26016]: pam_sm_authenticate: rhost [192.0.2.91] obtained
Dec 26 10:36:37 sasmars sshd[26016]: pam_sm_authenticate: trying srv 0
Dec 26 10:36:38 sasmars sshd[26016]: Accepted password for mpenning from 192.0.2.91 port 55118 ssh2
Dec 26 10:36:38 sasmars sshd[26016]: pam_sm_setcred: called (pam_tacplus v1.3.7)
Dec 26 10:36:38 sasmars sshd[26016]: pam_unix(sshd:session): session opened for user mpenning by (uid=0)
Dec 26 10:36:38 sasmars sshd[26018]: pam_sm_setcred: called (pam_tacplus v1.3.7)
Dec 26 10:36:38 sasmars sshd[26018]: subsystem request for sftp
Dec 26 10:37:20 sasmars sshd[26016]: pam_unix(sshd:session): session closed for user mpenning
Dec 26 10:37:20 sasmars sshd[26016]: pam_sm_setcred: called (pam_tacplus v1.3.7)

ЗАКЛЮЧИТЕЛЬНОЕ РЕШЕНИЕ

Смотрите мой ответ ниже

script различия в поведении между RedHat и Debian

Связанные библиотеки

CentOS 6.3 - скрипт (util-linux-ng 2.17.2)

#ldd /usr/bin/script

linux-vdso.so.1 =>  (0x00007fff077ff000)
libutil.so.1 => /lib64/libutil.so.1 (0x00007f309f5d1000)
libutempter.so.0 => /usr/lib64/libutempter.so.0 (0x00007f309f3cf000)
libc.so.6 => /lib64/libc.so.6 (0x00007f309f03b000)
/lib64/ld-linux-x86-64.so.2 (0x00007f309f7e1000)

Ubuntu 12.04 - скрипт (util-linux 2.20.1)

#ldd /usr/bin/script

linux-vdso.so.1 =>  (0x00007fff375ff000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007fc0d7ab0000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc0d76f1000)
/lib64/ld-linux-x86-64.so.2 (0x00007fc0d7cdc000)

PTY

Основываясь на исходном исходном коде , scriptиз обеих версий откройте новый pty. Следующее - тест.

Ubuntu 12.04

john@U64D211:~/tmp$ ls /dev/pts
0  1  5  8  ptmx
john@U64D211:~/tmp$ script
Script started, file is typescript
john@U64D211:~/tmp$ ls /dev/pts
0  1  2  5  8  ptmx
john@U64D211:~/tmp$ last -i
john     pts/0        0.0.0.0          Sat Jan  5 09:09   still logged in   
reboot   system boot  0.0.0.0          Sat Jan  5 09:08 - 09:52  (00:44)    
john     pts/0        0.0.0.0          Thu Jan  3 00:50 - 01:42  (00:52)    
reboot   system boot  0.0.0.0          Thu Jan  3 00:48 - 01:43  (00:54)    

wtmp begins Tue Jan  1 20:48:28 2013
john@U64D211:~/tmp$ exit
exit
Script done, file is typescript
john@U64D211:~/tmp$ ls /dev/pts
0  1  5  8  ptmx
john@U64D211:~/tmp$ 

Ubuntu 12.04 scriptоткрыла новый pts (2). Это просто не обновлялось/var/log/wtmp .

CentOS 6

Я пропускаю тест, поскольку мы уже знаем, что scriptоткрываем pty и регистрируемся в wtmp.

libutemper

• Проект: http://freecode.com/projects/libutempter
• Описание: libutempter предоставляет интерфейс библиотеки для эмуляторов терминала, таких как screen и xterm, для записи пользовательских сессий в файлы utmp и wtmp.

Таким образом, основным отличием является дополнительная библиотека ( libutempter.so.0), scriptс которой связан CentOS .

Тест с Ubuntu 12.04

Компиляция scriptс помощью libutempter

john@U64D211:~/tmp/util-linux-2.20.1$ sudo apt-get install libutempter-dev
john@U64D211:~/tmp/util-linux-2.20.1$ ./configure --with-utempter
john@U64D211:~/tmp/util-linux-2.20.1$ make
john@U64D211:~/tmp/util-linux-2.20.1$ cd term-utils/
john@U64D211:~/tmp/util-linux-2.20.1/term-utils$ ldd ./script
linux-vdso.so.1 =>  (0x00007fff54dff000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f289e635000)
libutempter.so.0 => /usr/lib/libutempter.so.0 (0x00007f289e432000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f289e072000)
/lib64/ld-linux-x86-64.so.2 (0x00007f289e861000)

тестирование

Перед запуском script

john@U64D211:~/tmp/util-linux-2.20.1/term-utils$ ls /dev/pts
0  1  5  8  ptmx
john@U64D211:~/tmp/util-linux-2.20.1/term-utils$ last -i
john     pts/0        0.0.0.0          Sat Jan  5 09:09   still logged in   
reboot   system boot  0.0.0.0          Sat Jan  5 09:08 - 10:37  (01:28)    
john     pts/0        0.0.0.0          Thu Jan  3 00:50 - 01:42  (00:52)    
reboot   system boot  0.0.0.0          Thu Jan  3 00:48 - 01:43  (00:54)    

wtmp begins Tue Jan  1 20:48:28 2013

В script

john@U64D211:~/tmp/util-linux-2.20.1/term-utils$ ./script
Script started, file is typescript
john@U64D211:~/tmp/util-linux-2.20.1/term-utils$ ls /dev/pts
0  1  2  5  8  ptmx
john@U64D211:~/tmp/util-linux-2.20.1/term-utils$ last -i
john     pts/2        0.0.0.0          Sat Jan  5 10:37   still logged in   
john     pts/0        0.0.0.0          Sat Jan  5 09:09   still logged in   
reboot   system boot  0.0.0.0          Sat Jan  5 09:08 - 10:37  (01:29)    
john     pts/0        0.0.0.0          Thu Jan  3 00:50 - 01:42  (00:52)    
reboot   system boot  0.0.0.0          Thu Jan  3 00:48 - 01:43  (00:54)    

wtmp begins Tue Jan  1 20:48:28 2013
john@U64D211:~/tmp/util-linux-2.20.1/term-utils$ exit
exit
Script done, file is typescript

После scriptокончания

john@U64D211:~/tmp/util-linux-2.20.1/term-utils$ ls /dev/pts
0  1  5  8  ptmx
john@U64D211:~/tmp/util-linux-2.20.1/term-utils$ last -i
john     pts/2        0.0.0.0          Sat Jan  5 10:37 - 10:37  (00:00)    
john     pts/0        0.0.0.0          Sat Jan  5 09:09   still logged in   
reboot   system boot  0.0.0.0          Sat Jan  5 09:08 - 10:37  (01:29)    
john     pts/0        0.0.0.0          Thu Jan  3 00:50 - 01:42  (00:52)    
reboot   system boot  0.0.0.0          Thu Jan  3 00:48 - 01:43  (00:54)    

wtmp begins Tue Jan  1 20:48:28 2013
john@U64D211:~/tmp/util-linux-2.20.1/term-utils$ last
john     pts/2                         Sat Jan  5 10:37 - 10:37  (00:00)    
john     pts/0        :0               Sat Jan  5 09:09   still logged in   
reboot   system boot  3.2.0-35-generic Sat Jan  5 09:08 - 10:38  (01:30)    
john     pts/0        :0               Thu Jan  3 00:50 - 01:42  (00:52)    
reboot   system boot  3.2.0-35-generic Thu Jan  3 00:48 - 01:43  (00:54)    

wtmp begins Tue Jan  1 20:48:28 2013

Основная причина имени хоста emtpy

И да, script.cсоздайте wtmpзапись с пустым именем хоста. Посмотрите на следующий блок кода в util-linux-2.20.1/term-utils/script.cстроке: 245-247

#ifdef HAVE_LIBUTEMPTER
    utempter_add_record(master, NULL);
#endif

Основывается на libutempter-1.1.5/utempter.h

extern int utempter_add_record (int master_fd, const char *hostname);

Так script.cчто фактически передает пустое имя хоста вutempter_add_record .

RedHat Backport

Интересно то, что upstream на util-linux-ng-2.17.2самом деле не поддерживает libutempter. Кажется, Redhat решил добавить эту поддержку обратно.

john@U64D211:~/tmp/util-linux-ng-2.17.2$ ./configure --help|grep utemp

Приведенная выше команда возвращает пустой результат.

Вывод

Таким образом, разница в поведении между двумя дистрибутивами - это не ошибка, а выбор. RedHat решил поддержать эту функцию, в то время как Debian ее пропустил.

Это выглядит абсолютно загадочным для меня. Либо он должен использовать DNS-имя или IP-адрес. Я также проверил last.cфайл, но до сих пор не могу найти, почему он ничего не показывает. Вероятно, по прошествии некоторого времени я смогу разобраться в части о 0.0.0.0.

int dns_lookup(char *result, int size, int useip, int32_t *a)
307 {
308     struct sockaddr_in  sin;
309     struct sockaddr_in6 sin6;
310     struct sockaddr     *sa;
311     int         salen, flags;
312     int         mapped = 0;
313 
314     flags = useip ? NI_NUMERICHOST : 0;
315 
316     /*
317      *  IPv4 or IPv6 ?
318      *  1. If last 3 4bytes are 0, must be IPv4
319      *  2. If IPv6 in IPv4, handle as IPv4
320      *  3. Anything else is IPv6
321      *
322      *  Ugly.
323      */
324     if (a[0] == 0 && a[1] == 0 && a[2] == htonl (0xffff))
325         mapped = 1;
326 
327     if (mapped || (a[1] == 0 && a[2] == 0 && a[3] == 0)) {
328         /* IPv4 */
329         sin.sin_family = AF_INET;
330         sin.sin_port = 0;
331         sin.sin_addr.s_addr = mapped ? a[3] : a[0];
332         sa = (struct sockaddr *)&sin;
333         salen = sizeof(sin);
334     } else {
335         /* IPv6 */
336         memset(&sin6, 0, sizeof(sin6));
337         sin6.sin6_family = AF_INET6;
338         sin6.sin6_port = 0;
339         memcpy(sin6.sin6_addr.s6_addr, a, 16);
340         sa = (struct sockaddr *)&sin6;
341         salen = sizeof(sin6);
342     }
343 
344     return getnameinfo(sa, salen, result, size, NULL, 0, flags);
345 }

Вот две глобальные переменные, используемые в контексте:

int usedns = 0;     /* Use DNS to lookup the hostname. */
72 int useip = 0;       /* Print IP address in number format */

Таким образом, теоретически, он должен использовать DNS или IP.

Я посмотрю, смогу ли я копать что-нибудь дальше. Но то, что спросили, это правильные вопросы.

Так что я побежал последним в отладчике, который, надеюсь, даст вам хотя бы немного ответов на ваш вопрос. Мое чувство коренная причина, хотя глубже.

Почему последний -i показывает 0.0.0.0 для записей строки pts

Лучший способ объяснить это то, что происходит, когда вы не передаете -i.

Причина этого в этом разделе кода last.c

if (usedns || useip)
  r = dns_lookup(domain, sizeof(domain), useip, p->ut_addr_v6);
if (r < 0) {
   len = UT_HOSTSIZE;
   if (len >= sizeof(domain)) len = sizeof(domain) - 1;
   domain[0] = 0;
   strncat(domain, p->ut_host, len);
}

Оба usednsи useip(с использованием параметров по умолчанию) не помечены. Это заставляет логику копировать из структуры, p->ut_hostкоторая в соответствии с man utmpименем удаленного входа в систему записывается тем, что записано в utmp.

char ut_host[UT_HOSTSIZE]; /* Hostname for remote login, or
                              kernel version for run-level
                              messages */

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

В этом случае last -iвызывается dns_lookup. Это передаст запись (p-> ut_addr_v6) для разрешения через DNS. В вашем случае это значение также содержит нули.

Большая часть dns_lookup- оформление витрин и шутка. В основном важна функция getnameinfo. Это библиотечный вызов, который в этом случае будет стараться разрешить двоичное значение, хранящееся в ut_addr_v6. Когда эта запись содержит нули (например, в вашем случае), вы фактически решаете это так, 0.0.0.0как это происходит с вашимlast -i выводом.

Есть ли что-нибудь (кроме злонамеренной деятельности), которое разумно объясняет поведение?

Ну, это, наверное, ошибка или недосмотр. Его вряд ли вредоносные , так как это кажется глупым , чтобы оставить любого след в качестве злоумышленника, а не опуская адрес источника.

До сих пор в центре внимания находились не в том месте. lastпросто читает utmpили wtmp. тем не мениеlast делает все возможное с данными, которые он имеет.

Ваша первопричина лежит где-то так utmp, как написано !

Хотя некоторые приложения пишут напрямую, utmpя полагаю, что источником ваших проблем sshdявляется управление сессией.

Кроме метки времени в истории bash, есть ли другие способы, которые я могу сделать, чтобы отследить проблему?

utmpобычно не доступен для записи и не предназначен для этого. utmpнаписано приложениями, предназначенными для входа в систему и настройки сеанса. В вашем случае это так sshd.

Почему sshd не обрабатывает вашего пользователя должным образом, очень странно, так как он должен правильно копировать имя хоста, с которого вы пришли. Вот где усилия по отладке, вероятно, должны быть сосредоточены. Начните с добавления отладочных выходных данных sshd в ваши журналы и посмотрите, не возникнет ли что-то аномальное.

Если вы хотите обойти проблему (или, возможно, даже узнать больше о проблеме), вы можете использовать pam_lastlogдля управления utmp, добавив ее в сеанс запись в /etc/pam.d/sshd.

На самом деле не мешало бы проверить, существует ли он уже там - потому что pam_lastlogсодержит nohostопцию, которая определенно объясняет ваше поведение, которое вы испытываете.

Наконец, вы не могли использовать последний вообще. aulastвыполняет ту же работу через подсистему аудита.

Возможно, стоит попробовать проверить, удалось ли хотя бы написать правильный адрес. Если это не так, то ваша проблема должна быть с sshd, так как sshd передает DNS-имена различным подсистемам, таким как utmp или аудит.

(1) База на lastвыходе ОП

После входа в систему через ssh можно войти в ssh на локальный хост и получить 0.0.0.0 last -iдля последующего использования.

База на первых четырех строках журнала ОП

mpenning pts/19                        Fri Nov 16 10:32 - 10:35  (00:03)
mpenning pts/17                        Fri Nov 16 10:21 - 10:42  (00:21)
bill     pts/15       sol-bill.local   Fri Nov 16 10:19 - 10:36  (00:16)
mpenning pts/1        192.0.2.91       Fri Nov 16 10:17 - 10:49 (12+00:31)

pts/19вход был в течение pts/17периода входа.

pts/17вход был в течение pts/1 периода входа.

Для этого конкретного случая логично предположить, что OP ssh из 192.0.2.91 ( pty/1), затем в этом сеансе ssh, ssh localhostснова локально ( ) войти на сервер ( pts/17) и снова (pts/19 ).

Пожалуйста, проверьте, не происходит ли это совпадение с другим случаем.

Следующее может помочь определить причину

• Вы используете SSH-ключ? Если да, то на сервере вы настроили ssh-key для локального входа?
• Проверьте или отправьте / var / log / secure того же периода времени. Это может дать намек.
• Проверьте скрипты, которые вы используете
• Проверьте псевдонимы оболочки, которые вы используете
• Проверьте историю команд

(2) Дополнительный Secnario

Сценарий 1 - судо и терминал

1. UserA логин X Window
2. Откройте окно терминала, сделайте xhost + localhost
3. su - UserBили sudo su - UserBзатем откройте новый терминал (xterm, gnome-терминал и т. д.)
4. UserB будет отображаться как 0.0.0.0 в last -i

su - UserBне будет зарегистрирован как UserBлогин в последнем, но открытие терминала будет.

Сценарий 2 - вход

1. SSH на сервер
2. тип sudo login
3. войдите под своим именем
4. проверить lastиlast -i

lastне показывать имя хоста или IP для login session. last -iбудет IP 0.0.0.0 для login session.

john@U64D211:~$ last -5
john     pts/0                         Sun Dec 23 20:50   still logged in   
john     pts/0                         Sun Dec 23 20:50 - 20:50  (00:00)    
john     pts/0        :0               Sun Dec 23 20:50 - 20:50  (00:00)    
reboot   system boot  3.2.0-35-generic Sun Dec 23 20:49 - 20:50  (00:01)    
john     pts/2        js.example.com   Sun Dec 23 17:14 - crash  (03:34)    

wtmp begins Sat Dec  1 06:30:46 2012
john@U64D211:~$ last -5i
john     pts/0        0.0.0.0          Sun Dec 23 20:50   still logged in   
john     pts/0        0.0.0.0          Sun Dec 23 20:50 - 20:50  (00:00)    
john     pts/0        0.0.0.0          Sun Dec 23 20:50 - 20:50  (00:00)    
reboot   system boot  0.0.0.0          Sun Dec 23 20:49 - 20:50  (00:01)    
john     pts/2        192.168.1.90     Sun Dec 23 17:14 - crash  (03:34)    

wtmp begins Sat Dec  1 06:30:46 2012

В ответе Mife уже указан блок кода last.c. Причина lastотображения пустого имени хоста / IP заключается в том, что ut_hostэти записи фактически пусты. Для полной структуры wtmp, сделайте man wtmpна любой системе Linux.

2 сценария показывают, что даже стандартные пакеты в определенных ситуациях создают их как таковые.

(3) Взломать историю Bash

Это будет работать только в том случае, если сеанс используется в bashкачестве интерактивной оболочки.

.bashrcи .bash_profileиспользуются только bash.

Они не будут получены автоматически, если сессия использует какую-либо другую оболочку (sh, csh и т. Д.) Или выполнит программу напрямую, и истории bash также не будет.

(4) Процесс учета

Поскольку OP ничего не упоминает о secureфайле, я предполагаю, что это тупик, и теперь он фактически дает подсказку.

Если следующее предположение верно

`last` 0.0.0.0 entries are actually created with in OP own session

auth.log (debian) / secure (CentOS) не поможет. Поскольку в нем записано только действие, связанное с аутентификацией.

wtmp / utmp, с ограничением в их структуре данных, также является тупиком. Нет информации о том, что их создало.

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

1. Может быть, против политики компании
2. Другие пользователи в общей системе могут быть недовольны / неудобны, если она включена
3. Файл журнала может занимать много места на диске. Следите за скоростью роста размера файла.

Версия пакета psacct должна быть 6.3.2-56 или выше, согласно этому посту .

Если он должен использоваться и /var/logимеет ограниченное пространство, измените файл журнала acct на каталог (доступ только для пользователя root) /home, в котором обычно гораздо больше места.

Это действительно большой пистолет. При ОП 10% частота должна быть в течение недели. Если в течение этого периода пустая запись появится в lastжурнале действий, но ничего не появится, это станет загадочной ситуацией и потребует каких-то решительных действий .

Ниже приведен пример вывода lastcomm

lesspipe               john     pts/8      0.02 secs Mon Dec 24 17:10
lesspipe          F    john     pts/8      0.00 secs Mon Dec 24 17:10
dirname                john     pts/8      0.00 secs Mon Dec 24 17:10
basename               john     pts/8      0.00 secs Mon Dec 24 17:10
kworker/1:2       F    root     __         0.00 secs Mon Dec 24 16:54
tty                    john     pts/6      0.01 secs Mon Dec 24 17:09
tty                    john     pts/4      0.01 secs Mon Dec 24 17:09
cron              F    root     __         0.05 secs Mon Dec 24 17:09
sh               S     root     __         0.01 secs Mon Dec 24 17:09
find                   root     __         0.01 secs Mon Dec 24 17:09
maxlifetime            root     __         0.00 secs Mon Dec 24 17:09
php5                   root     __         0.23 secs Mon Dec 24 17:09
which                  root     __         0.00 secs Mon Dec 24 17:09
lastcomm               root     pts/0      0.01 secs Mon Dec 24 17:08
tty                    john     pts/1      0.01 secs Mon Dec 24 17:08
dconf worker         X john     __         5.46 secs Mon Dec 24 16:58
lastcomm               root     pts/7      0.04 secs Mon Dec 24 17:05
mesg             S     root     pts/7      0.00 secs Mon Dec 24 17:05
bash              F    root     pts/7      0.00 secs Mon Dec 24 17:05
dircolors              root     pts/7      0.00 secs Mon Dec 24 17:05

Вы также можете использовать «dump-acct», чтобы показать больше информации.

PS1: я пытался открыть несколько терминалов и ссх сессии. Непонятно (или не просто указать точку), что открывают новые очки. Тем не менее, он показывает все, что выполнялось в этом сеансе.

PS2: сообщение в блоге об использовании acct Майком.

Когда вы входите в систему, это может быть несколько записей в последней команде.

geekride   tty2                        Fri Dec 21 15:45 - 15:45  (00:00)    
geekride   pts/1                       Fri Dec 21 13:45   still logged in   
geekride   pts/1        :pts/0:S.0     Thu Dec  6 12:49 - 00:40  (11:50)    
geekride   pts/1        10.31.33.47    Thu Dec  6 12:49 - 00:40  (11:50)    

Первая запись с tty * появляется, когда вы входите через терминал или консоль, нажимая CTRL + ALT + F1-6. Это довольно ясно из терминала, который он использует.

Вторая запись обычно появляется, когда вы входите в систему и открываете окно терминала в графическом интерфейсе. Также будет запись, даже если вы откроете новую вкладку в том же окне терминала.

Третий тип ввода происходит, когда вы открываете сеанс экрана после входа в систему через SSH. Это также создаст запись там и без какого-либо IP-адреса.

Четвертая запись вполне нормальна, и все это понимают.

Если вы сделаете last -iсо следующими записями, вы увидите что-то вроде этого:

geekride   tty2         0.0.0.0        Fri Dec 21 15:45 - 15:45  (00:00)    
geekride   pts/9        0.0.0.0        Fri Dec 21 13:45   still logged in   
geekride   pts/1        0.0.0.0        Thu Dec  6 12:49 - 00:40  (11:50)    

Я почти уверен, что ваш случай подходит к любому из двух случаев: один с окном терминала в GUI, а другой с сеансом экрана.

Надеюсь, что это помогло.

Я не думаю, что мы доберемся до этого без отладки last.c, но это не должно быть слишком сложно, так как он легко компилируется ...

Одна из возможностей, однако, - выгрузить файл / var / log / wtmp с помощью команды utmpdump и взглянуть на необработанные записи, которые могут пролить свет на вас. Если нет, пожалуйста, опубликуйте соответствующий вывод

utmpdump /var/log/wtmp 

так что мы можем воссоздать локальные копии вашего wtmp для отладки с

utmpdump -r <dumpfile >wtmp

Я проверил 12 многопользовательских серверов приложений CentOS и RHEL 6.3. Никто не проявлял такого поведения. В lastвыходных не было пропущенных записей, начиная с 4-5 недель.

Я думаю, что было бы важно увидеть /etc/hostsзапись вашего файла, чтобы убедиться, что она соответствует этому формату .

Кроме того, что вы делаете для разрешения DNS? Вы можете опубликовать свой /etc/resolv.conf?

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

 reboot   system boot  0.0.0.0          Sat Dec  8 06:12 - 05:57 (12+23:45)  
 reboot   system boot  0.0.0.0          Sat Dec  8 05:25 - 06:09  (00:44)    
 reboot   system boot  0.0.0.0          Fri Nov 30 14:28 - 05:22 (7+14:54)   
 root     tty1         0.0.0.0          Fri Nov 30 13:52 - 13:55  (00:03)    
 reboot   system boot  0.0.0.0          Fri Nov 30 13:51 - 14:25  (00:34)    

Так как это происходит только с именованными пользователями, есть ли какое-то изменение, что происходит что-то необычное или запускается в их сценариях входа? Вы изменили ~/.bashrcили ~/.bash_profileпо умолчанию? Существуют ли другие специальные сценарии входа в среду?

--Редактировать--

Я все еще не могу воспроизвести это каким-либо образом. Я смотрю на два критических компонента, хотя. Команда lastстабильна и не менялась долгое время. Если посмотреть на журнал изменений для sysvinit-tools , то здесь нет соответствующих ошибок. То же самое для начальных букв (wtmp).

Если вы можете заставить это произойти, попробуйте это с другой учетной записью пользователя из тех же исходных компьютеров. Но я не вижу никаких признаков того, что это проблема ОС.

ЗАКЛЮЧИТЕЛЬНОЕ РЕШЕНИЕ

Я уже присудил бонус, так что это чисто для будущих гуглеров с таким же вопросом.

Причина, по которой это появляется только в ~ 10% моих входов в систему, заключается в том, что когда я делаю серьезные изменения в наших маршрутизаторах или коммутаторах, я использую их, script foo.logпоэтому у меня есть полный журнал изменений терминала. По причинам, которые я до сих пор не понимаю, CentOS создает ptsзапись, когда вы используете scriptкоманду ... Я продемонстрирую вывод last -iдо и после запуска script...

[mpenning@sasmars net]$ last -i | head
kkim14   pts/13       192.0.2.225   Wed Jan  2 09:43   still logged in
kkim14   pts/12       192.0.2.225   Wed Jan  2 09:43   still logged in
kkim14   pts/10       192.0.2.225   Wed Jan  2 09:43   still logged in
kkim14   pts/9        192.0.2.225   Wed Jan  2 09:43   still logged in
kkim14   pts/5        192.0.2.225   Wed Jan  2 09:43   still logged in
mpenning pts/17       192.0.2.29    Mon Dec 31 16:45 - 16:49  (00:03)
gduarte  pts/16       192.0.2.135   Thu Dec 27 10:54   still logged in
gduarte  pts/14       192.0.2.135   Thu Dec 27 10:44   still logged in
dspencer pts/14       192.0.2.4     Thu Dec 27 09:56 - 09:57  (00:01)
mpenning pts/14       192.0.2.91    Thu Dec 27 08:31 - 08:32  (00:00)
[mpenning@sasmars net]$ script ~/something_random.log
Script started, file is /home/mpenning/something_random.log
[mpenning@sasmars net]$ date
Thu Jan  3 16:14:19 CST 2013 # <--------------------------------------------------
[mpenning@sasmars net]$ exit
exit
Script done, file is /home/mpenning/something_random.log
[mpenning@sasmars net]$ last -i | head
mpenning pts/15       0.0.0.0          Thu Jan  3 16:14 - 16:14  (00:00) # <------
kkim14   pts/13       192.0.2.225   Wed Jan  2 09:43   still logged in
kkim14   pts/12       192.0.2.225   Wed Jan  2 09:43   still logged in
kkim14   pts/10       192.0.2.225   Wed Jan  2 09:43   still logged in
kkim14   pts/9        192.0.2.225   Wed Jan  2 09:43   still logged in
kkim14   pts/5        192.0.2.225   Wed Jan  2 09:43   still logged in
mpenning pts/17       192.0.2.29    Mon Dec 31 16:45 - 16:49  (00:03)
gduarte  pts/16       192.0.2.135   Thu Dec 27 10:54   still logged in
gduarte  pts/14       192.0.2.135   Thu Dec 27 10:44   still logged in
dspencer pts/14       192.0.2.4     Thu Dec 27 09:56 - 09:57  (00:01)
[mpenning@sasmars net]$ cat /etc/redhat-release
CentOS release 6.3 (Final)
[mpenning@sasmars net]$

Такое поведение кажется уникальным для CentOS 6 ... у нас в лаборатории есть машины CentOS 4.7, которые не помещают пустую запись в wtmp... Машины Debian / Gentoo также не демонстрируют такое поведение. Наши администраторы linux ломают голову над тем, почему CentOS намеренно добавляет другую ptsзапись при запуске script... Я подозреваю, что это ошибка RHEL.

РЕДАКТИРОВАТЬ : я подал эту проблему как идентификатор ошибки RHEL 892134

НОТА

Некоторые люди ошибочно предположили, что я положил scriptв свой ~/.bashrcили ~/.bash_profile. Это некорректный аргумент ... если бы это было правдой, my wtmpдолжен иметь 0.0.0.0запись после каждого из моих логинов ssh ...

[mpenning@sasmars net]$ last -i | head
kkim14   pts/13       192.0.2.225   Wed Jan  2 09:43   still logged in
kkim14   pts/12       192.0.2.225   Wed Jan  2 09:43   still logged in
kkim14   pts/10       192.0.2.225   Wed Jan  2 09:43   still logged in
kkim14   pts/9        192.0.2.225   Wed Jan  2 09:43   still logged in
kkim14   pts/5        192.0.2.225   Wed Jan  2 09:43   still logged in
mpenning pts/18       0.0.0.0       Mon Dec 31 16:45 - 16:49  (00:03)  # <-----
mpenning pts/17       192.0.2.29    Mon Dec 31 16:45 - 16:49  (00:03)  # <-----
gduarte  pts/16       192.0.2.135   Thu Dec 27 10:54   still logged in
gduarte  pts/14       192.0.2.135   Thu Dec 27 10:44   still logged in
dspencer pts/14       192.0.2.4     Thu Dec 27 09:56 - 09:57  (00:01)
mpenning pts/15       0.0.0.0       Thu Dec 27 08:31 - 08:32  (00:00)  # <-----
mpenning pts/14       192.0.2.91    Thu Dec 27 08:31 - 08:32  (00:00)  # <-----

Конечно, это был не тот случай ...

Соединения псевдотерминала Slave (pts) - это соединения SSH или telnet, что означает косвенные соединения с системой. Все эти соединения могут подключаться к оболочке, которая позволит вам подавать команды на компьютер. Поэтому, когда вы открываете терминал в вашей системе из графического интерфейса, он открывает pts с исходным IP-адресом 0.0.0.0. Из предоставленной вами информации кажется, что это происходит из-за запуска сценария на этом сервере или по расписанию, который использует службу ssh или telnet или локальные точки для выдачи вывода в терминал.

Какой SSH-клиент вы используете? Некоторые клиенты ssh могут мультиплексировать несколько терминалов по одному соединению, и я замечаю, что все ваши сеансы без IP попадают в более длинные сеансы, которые имеют зарегистрированный IP.

Я не могу продублировать это поведение с помощью ssh.

Возможно, ваш IP-адрес преобразуется в пустую строку на одном из ваших DNS-серверов, возможно, вторичную, если это происходит только в 10% случаев (или, возможно, просто в файл hosts, если они распространяются из центрального хранилища). Это объясняет отсутствующую (или пробел) запись и согласуется с прочтением Сохемом источника.

«0.0.0.0» означает, что это локальный пользователь (не удаленный вход в систему), вероятно, вызванный приложением, например, cronjob.

Это происходит потому, что вы используете локальную систему, а 0.0.0.0 означает IP-адрес всех интерфейсов. Если вы думаете, что, возможно, кто-то взломал, вы попытаетесь настроить полную регистрацию оболочки, включая команды через ssh - http://blog.pointsoftware.ch/index.php/howto-bash-audit-command-logger/

Я решил это, добавив скрипт в ~ / .bashrc, скрипт находит последний IP-адрес источника соединения telnet, затем вы можете добавить IP в файл журнала или сделать все, что вам нужно ..

client_ip=$(echo $(netstat -nae | grep $(netstat -nae | grep 23 | awk  '{print $8}' | sort -n | tail -n1) | awk '{print $5}') | awk -F':' '{print $1}' )

echo "client_ip=$client_ip"

Sharon