主页 / server / 问题 / 455069
Accepted
Mike Pennington
Asked: 2012-12-05 12:46:48 +0800 CST

pts 登录的“last”输出中缺少 IP 信息的原因？

  • 772

我有五个 CentOS 6 linux 系统在工作，并且遇到了一个相当奇怪的问题，它似乎只发生在我拥有的所有 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显示pts 行条目（另请参阅0.0.0.0此答案）
  • 有什么（恶意活动除外）可以合理地解释这种行为吗？
  • 除了 bash 历史时间戳之外，我还能做其他事情来追踪问题吗？

信息性的

由于这开始发生，我启用了bash历史时间戳（即HISTTIMEFORMAT="%y-%m-%d %T "in .bash_profile）并且还添加了一些其他的 bash 历史 hacks；然而，这并没有提供关于之前发生的事情的线索。

所有系统都运行 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（请注意，我在上面.local的输出中使用了 addrslast来隐藏我公司的信息）

[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信息（请注意，此自定义主机文件仅存在于出现这些问题的其中一台机器上）

[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)

最终决议

请参阅下面的答案

linux

14 个回答

  1. 这对我来说绝对令人费解。它应该使用一些 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。

    我会看看我是否可以进一步挖掘任何东西。但是 ewwhite 问的是有效问题。

    • 12

  2. (1) 基于OPlast输出

    通过 ssh 登录后，可以 ssh 到本地主机并获取 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 从 192.0.2.91( pty/1) 进行 ssh，然后在该 ssh 会话中，在本地 ( ssh localhost) 再次 ( ) 登录到服务器pts/17，然后再次 ( pts/19)。

    请检查这种重叠是否与其他事件发生。

    以下可能有助于查明原因

    • 你使用ssh密钥吗？如果是这样，在服务器上，您是否设置了 ssh-key 以在本地登录？
    • 检查或发布同一时间范围的 /var/log/secure。它可能会提供一些提示。
    • 检查您使用的脚本
    • 检查您使用的 shell 别名
    • 检查你的命令历史

    (2) 附加场景

    场景 1 - sudo 和终端

    1. UserA 登录 X 窗口
    2. 打开一个终端窗口，做xhost + localhost
    3. su - UserB或者sudo su - UserB打开一个新终端（xterm、gnome-terminal 等）
    4. UserB将显示为 0.0.0.0last -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用作交互式 shell 时才有效。

    .bashrc并且.bash_profile只被使用bash。

    如果会话使用任何其他 shell（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 会话。目前尚不清楚（或不容易确定）是什么打开了一个新的 pts。但是，它确实显示了在该 pts/会话中运行的所有内容。

    PS2：Mike 的一篇关于使用 acct 的博文。

    • 8

  3. 所以我在调试器中运行到最后，希望它至少能给你一些问题的答案。我的感觉是根本原因更深。

    为什么 last -i 为 pts 行条目显示 0.0.0.0

    最好的解释方法是当你没有通过 -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。这将传递要通过 DNS 解析的条目 (p->ut_addr_v6)。在您的情况下，此值也包含零。

    Most of dns_lookup is window dressing and heusteric. Basically what matters is the function getnameinfo. This is a library call which in this case will try its best to resolve the binary value stored in the ut_addr_v6. When this entry contains zeroes (such as in your case) you are actually resolving this to 0.0.0.0 as is what happens with your last -i output.

    Is there anything (other than malicious activity) that would reasonably explain the behavior?

    Well, its probably a bug or oversight. Its unlikely to be malicious since it seems stupid to leave any trace as an attacker rather than omitting a source address.

    The focus of answers so far have been looking at the wrong place. last just reads utmp or wtmp. However last is doing its best with the data it has.

    Your root cause lies somewhere in the manner to which utmp is being written to!

    While a few applications directly write into utmp I guess the source of your problems lie in the way sshd is handling the session management.

    Other than bash history timestamping, are there other things I can do to track the issue down?

    utmp is not typically writable and is not meant to be. utmp is written by applications designed to log you in and setup your session. In your case that is sshd.

    Why sshd is not handling your user properly is very strange as it should be properly copying in the hostname you came in from. This is where debugging efforts should probably be focused. Start with adding debug output of sshd to your logs and see if anything anomalous comes up.

    If you want to work around the problem (or, maybe even possibly discover more about the issue) you can use pam_lastlog to manage utmp by adding it to the session entry to /etc/pam.d/sshd.

    As a matter of fact it wont hurt to check if it is already there -- because pam_lastlog contains a nohost option which would definitely explain your behaviour you are experiencing.

    Finally, you could not use last at all. aulast does the same job via the audit subsystem.

    Might be worth a try to see if that has managed to at least write the correct address. If it hasn't then your problem must be with sshd as sshd is passing the DNS names around different subsystems like utmp or audit.

    • 8

  4. 当您登录到机器时，这些可能是最后一个命令中的几个条目。

    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)

    当您通过按 CTRL+ALT+F1-6 通过终端或控制台登录时，带有 tty* 的第一个条目出现。从它使用的终端上看，它非常清楚。

    当您登录机器​​并在 GUI 中打开终端窗口时，通常会出现第二个条目。即使您在同一个终端窗口中打开一个新选项卡，也会有一个条目。

    当您通过 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 中的终端窗口，另一种是屏幕会话。

    希望这有帮助。

    • 5
  5. Best Answer

    script behavior differences between RedHat and Debian

    Linked Libraries

    CentOS 6.3 - script (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 - script (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

    Base on upstream source code, script from both versions do open new pty. Following is test.

    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 did open a new pts(2). It just did not update /var/log/wtmp.

    CentOS 6

    I am skipping the test as we already know that script do open pty and register with wtmp.

    libutemper

    • Project: http://freecode.com/projects/libutempter
    • Description: libutempter provides a library interface for terminal emulators such as screen and xterm to record user sessions to utmp and wtmp files.

    So the main difference seems to be the extra library(libutempter.so.0) CentOS script linked with.

    Test with Ubuntu 12.04

    Compiling script with 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)

    Testing

    Before running 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

    Within 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

    After script end

    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

    The root cause of emtpy hostname

    And yes, script.c do create the wtmp entry with empty hostname. Look at following code block in util-linux-2.20.1/term-utils/script.c Line:245-247

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

    Base on libutempter-1.1.5/utempter.h

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

    So script.c is actually passing empty hostname into utempter_add_record.

    RedHat Backport

    The interesting thing is, upstream util-linux-ng-2.17.2 actually does not support libutempter. Seems Redhat decided to added that support back.

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

    The above command return empty result.

    Conclusion

    So the difference in behavior between the two distros is not a bug, but a choice. RedHat decided to support that feature, while Debian skipped it.

    • 4

  6. 我检查了 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) 也一样。

    如果您可以强制发生这种情况，请使用来自相同源计算机的不同用户帐户进行尝试。但我没有看到任何迹象表明这是一个操作系统问题。

    • 3

  7. 如果不调试 last.c，我认为我们不会在这方面走得太远，但这应该不会太难，因为它很容易编译......

    不过，一种可能性是使用utmpdump命令转储 /var/log/wtmp 文件并查看原始记录，这可能会给您带来一些启示。如果没有，请发布一些相关输出

    utmpdump /var/log/wtmp

    这样我们就可以重新创建您的 wtmp 的本地副本以进行调试

    utmpdump -r <dumpfile >wtmp
    • 3

  8. FINAL RESOLUTION

    I already awarded the bonus, so this is purely for future googlers with the same question.

    The reason this only appears in ~10% of my logins is because when I make major changes to our routers or switches, I use script foo.log so I have a complete terminal log of the change. For reasons I still don't understand, CentOS creates a pts entry when you use the script command... I will demonstrate the output of last -i before and after running 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]$

    This behavior seems to be unique to CentOS 6... we have some CentOS 4.7 machines in the lab that don't put a blank entry in wtmp... Debian / Gentoo machines don't exhibit this behavior either. Our linux-admins are scratching their heads why CentOS would intentionally add another pts entry when you execute script... I suspect this is a RHEL bug.

    EDIT: I filed this problem as RHEL Bug id 892134

    NOTE

    Some people have erroneously assumed I put script in my ~/.bashrc or ~/.bash_profile. This is a flawed argument... if that was true, my wtmp should have a 0.0.0.0 entry after every one of my ssh logins...

    [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)  # <-----

    Of course, that was not the case...

    • 3

  9. 伪终端从属 (pts) 连接是 SSH 或 telnet 连接，这意味着与系统的间接连接。所有这些连接都可以连接到一个 shell，它允许您向计算机发出命令。因此，当您从 gui 打开系统上的终端时，它会打开源 ip 为 0.0.0.0 的 pts。从您提供的信息看来，它的发生似乎是因为脚本在此服务器上运行或调度，它使用 ssh 或 telnet 服务或本地 pts 在终端中抛出输出。

    • 2

  10. 您使用哪个 ssh 客户端？一些 ssh 客户端可以在一个连接上多路复用多个终端，我注意到你所有没有 IP 的会话都属于较长的会话，这些会话确实有记录的 IP。

    我不能在这里用 ssh 复制这种行为。

    • 2

相关问题