Мне это кажется совершенно загадочным. Либо он должен использовать какое-то 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.

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

(1) База на OP last вывод

После входа в систему через ssh можно перейти по ssh на localhost и получить 0.0.0.0 в last -i на потом.

На основе первых четырех строк журнала OP

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-ключ на сервере для локального входа в систему?
• Проверьте или отправьте / var / log / secure того же периода времени. Это может дать подсказку.
• Проверьте скрипты, которые вы используете
• Проверьте псевдонимы оболочки, которые вы используете
• Проверьте свою историю команд

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

Сценарий 1 - sudo и терминал

1. Вход пользователя в X Window
2. Откройте окна терминала, сделайте xhost + localhost
3. su - UserB или sudo su - UserB затем откройте новый терминал (xterm, gnome-terminal и т. д.)
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.

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

(3) Взлом Bash History

Это будет работать, только если сеанс использует 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, в котором обычно гораздо больше места.

Это действительно большая пушка. При частоте встречаемости OP 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: Я попытался открыть несколько сеансов терминала и ssh. Непонятно (или непросто указать) что открыть новый оч. Тем не менее, он показывает все, что выполнялось в рамках этой точки / сеанса.

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

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

Почему last -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 или audit.

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

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)    

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

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

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 из обеих версий открываю новую партию. Ниже приводится тест.

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 открыл новый оч (2). Просто не обновлялось /var/log/wtmp.

CentOS 6

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

libutemper

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

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

Тест с 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

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

И да, 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

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

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

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

Вывод

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

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

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

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, актуальных ошибок нет. То же самое для initscripts (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. Это ошибочный аргумент ... если бы это было правдой, мой 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)  # <-----

Конечно, это было не так ...

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

Какой 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"

Шарон