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。 以下是testing。

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

我正在跳过testing，因为我们已经知道script打开pty并注册wtmp。

libutemper

• 项目： http : //freecode.com/projects/libutempter
• 说明：libutempter为terminal仿真程序（如screen和xterm）提供了一个库接口，用于将用户会话logging到utmp和wtmp文件。

所以最主要的区别似乎是与额外的库（ libutempter.so.0 ）挂钩的CentOS script 。

testingUbuntu 12.04

用libutempter编译script

 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

运行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会创build带有空主机名的wtmp条目。 请看util-linux-2.20.1/term-utils/script.c中的以下代码块：Line util-linux-2.20.1/term-utils/script.c

 #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 

以上命令返回空结果。

结论

所以两个发行版之间的行为差​​异不是一个错误，而是一个select。 RedHat决定支持这个function，而Debian跳过了它。

这看起来令我感到非常困惑。 它应该使用一些DNS名称或IP地址。 我也检查了last.c文件，但我仍然无法find它为什么没有显示任何东西。 也许有一段时间，我可以找出关于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 } 

上下文中使用的两个全局variables是这些variables。

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

所以理论上应该使用DNS或IP。

我会看看如果我能进一步挖掘任何东西。 但是什么ewwhite问是有效的问题。

所以我最后在debugging器中跑，希望至less会给你一些问题的答案。 我的感觉是根本原因是更深。

为什么最后-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); } 

useip和useip （使用默认选项）都不会被标记。 这会导致逻辑从struct p->ut_host复制出来，根据man utmp包含远程login名，就像logging在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）通过DNSparsing。 在你的情况下，这个值也包含零。

dns_lookup大部分是窗口修饰和heusteric。 基本上重要的是函数getnameinfo 。 这是一个库调用，在这种情况下将尽最大努力解决存储在ut_addr_v6的二进制值。 当这个条目包含零（例如在你的情况），你实际上解决这个0.0.0.0就像你last -i输出发生了什么。

有什么（除了恶意活动）合理解释行为？

那么，它可能是一个错误或疏忽。 它不可能是恶意的，因为把任何跟踪作为攻击者而不是忽略源地址似乎是愚蠢的。

到目前为止，答案的焦点一直在看错地方。 last只是读取utmp或wtmp 。 然而， last一点是用它所拥有的数据做得最好。

你的根源在于utmp被写入的方式 ！

当一些应用程序直接写入utmp我想你的问题的根源在于sshd处理会话pipe理的方式。

除了bash历史logging以外，还有其他一些事情可以用来追踪这个问题吗？

utmp通常不是可写的，也不是。 utmp是由devise用于login和设置会话的应用程序编写的。 在你的情况是sshd 。

为什么sshd不正确地处理你的用户是非常奇怪的，因为它应该正确地复制你从中进入的主机名。 这是debugging工作应该集中的地方。 首先将sshd的debugging输出添加到日志中，然后查看是否有exception情况出现。

如果你想解决这个问题（或者甚至可能发现更多的问题），你可以使用pam_lastlog来pipe理utmp ，把它添加到/etc/pam.d/sshd的会话项中。

事实上，检查它是否已经存在是不会受到伤害的，因为pam_lastlog包含了一个nohost选项，它肯定会解释你正在经历的行为。

最后，你根本不能使用最后一个。 aulast通过审计子系统完成相同的工作。

可能值得一试，看看是否已经设法至less写出正确的地址。 如果没有，那么你的问题必须是sshd，因为sshd是通过不同的子系统（如utmp或audit）传递DNS名称。

（1）基于OP的last输出

通过SSHlogin后，可以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/19login是在pts/17login期内。

pts/17login是在pts/1login期内。

对于这个特定的情况，从逻辑上推测，从192.0.2.91（ pty/1 ）开始，然后在该ssh会话中，从本地login（ ssh localhost ）到服务器（ pts/17 ），然后再次pts/19 ）。

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

以下可能有助于指出原因

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

（2）额外的Secnario

情景1 – sudo和terminal

1. 用户AloginX Window
2. 打开terminal窗口，做xhost + localhost
3. su - UserB或sudo su - UserB然后打开一个新的terminal（xterm，gnome-terminal等）
4. UserB将在last -i显示为0.0.0.0

su - UserB将不会在最后login为UserBlogin，但是打开terminal将会。

scheme2 – login

1. SSH入服务器
2. 键入sudo login
3. login为你自己
4. 检查last和last -i

last显示login session主机名或IP。 last -i将login session IP为0.0.0.0。

 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的原因是因为这些logging的ut_host 实际上是空的。 对于完整的wtmp结构，请在任何linux系统上执行man wtmp 。

这里的两种情况表明，即使在某些情况下，标准包也是如此创build它们。

（3）Bash历史黑客

它只会在会话使用bash作为交互式shell的情况下工作。

.bashrc和.bash_profile只被bash 。

如果会话使用任何其他shell（sh，csh等）或直接执行程序，它们将不会自动获取，并且也不会有bash历史logging。

（4）stream程会计

由于OP没有提到secure文件，我会认为这是一个死胡同，它实际上提供了现在的提示。

如果以下假设是正确的

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

auth.log（debian）/ secure（CentOS）不起作用。 因为只有与authentication相关的动作被logging在其中。

wtmp / utmp在数据结构方面有局限性，也是死路一条。 没有关于创build它们的信息。

这给我们留下了一个select， 进程会计 。 这是一个大枪，必须谨慎使用。

1. 也许违反公司政策
2. 共享系统上的其他用户可能对其启用不满意/不舒服
3. 日志文件可以使用大量的磁盘空间。 密切关注文件大小的增长速度。

根据这个post ，psacct包的版本应该是6.3.2-56或更高。

如果要使用它，并且/var/log空间有限，请将acct日志文件更改为/home下的一个目录（仅限根目录），这通常会占用更多的空间。

这真是大枪。 OP 10％发生率，一周内应该有结果。 如果在这段时间里，空的进入显示在last但没有任何logging，这是一个谜 ，并需要一些激烈的行动 。

以下是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：我试图打开几个terminal和SSH会话。 目前还不清楚（或者不容易指出）是什么开一个新的pts。 但是，它确实显示了在pts / session中运行的所有内容。

PS2：关于Mike使用acct的博客文章。

login到计算机时，最后一条命令中的条目可能很less。

 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通过terminal或控制台login时，tty *的第一个条目出现。 从它使用的terminal来看，它非常清楚。

login到计算机并在GUI中打开terminal窗口时，通常会显示第二个条目。 即使您在同一个terminal窗口中打开一个新的Tab，也会有一个条目。

第三种types的入口是在通过SSHlogin后打开一个屏幕会话。 这也将创build一个入口，没有任何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中的terminal窗口，另一种是屏幕会话。

希望这可以帮助。

我不认为我们会去debugginglast.c，但这不应该太难，因为它编译容易…

一种可能性是使用utmpdump命令转储/ var / log / wtmp文件，并查看原始logging，这可能会为您带来一些启示 。 如果不是请张贴一些相关的输出

 utmpdump /var/log/wtmp 

所以我们可以重新创buildwtmp的本地副本来进行debugging

 utmpdump -r <dumpfile >wtmp 

我检查了12个多用户基于CentOS和RHEL 6.3的应用程序服务器。 没有performance出这种行为。 last输出4-5周后没有缺失的项目。

我认为看到你的/etc/hosts文件条目以确保它符合这种格式是很重要的。

另外，你在做什么DNSparsing？ 你可以发布你的/etc/resolv.conf吗？

表示0.0.0.0代表本地连接的其他响应是正确的。 典型的例子是重新启动和控制台login事件：

  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) 

由于这似乎只发生在命名用户，是否有任何改变有东西是来源或运行在他们的login脚本？ 你有没有改变~/.bashrc或~/.bash_profile从默认？ 环境中是否还有其他特殊的login脚本？

– 编辑 –

我仍然无法以任何方式重现这一点。 不过，我看看两个关键组件。 last命令是稳定的，并且长时间没有改变。 查看sysvinit-tools的更新日志，没有相关的错误。 同样的initscripts （wtmp）。

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

最终决议

我已经授予奖金，所以这是纯粹的未来谷歌具有相同的问题。

这只是出现在我login的〜10％的原因是因为当我对路由器或交换机进行重大更改时，我使用script foo.log因此我有一个完整的terminallogin日志。 由于我仍然不明白的原因，当你使用script命令时，CentOS会创build一个pts条目…我将演示运行script之前和之后的last -i的输出…

 [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机器，它们不会在wtmpinput空白条目… Debian / Gentoo机器也不会出现这种行为。 我们的linuxpipe理员正在摸索为什么CentOS会在你执行script时候有意添加另一个pts条目…我怀疑这是一个RHEL错误。

编辑 ：我提出这个问题作为RHEL错误编号892134

注意

有些人错误地认为我把script放在~/.bashrc或~/.bash_profile 。 这是一个有缺陷的论点…如果这是真的，我的wtmp应该有一个0.0.0.0条目后，我的每一个SSHlogin…

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

Pseudo Terminal Slave (pts) connections are SSH or telnet connections that means indirect connections to the system. All of these connections can connect to a shell which will allow you to issue commands to the computer. So when you open up a terminal on your system from gui, it opens up a pts with source ip 0.0.0.0. From the information provided by you, it seems that it happening because of script running on this server or scheduled, which is using ssh or telnet service or local pts to throw output in terminal.

Which ssh client do you use? Some ssh clients can multiplex multiple terminals over one connection and I notice all your sessions without IP fall within longer sessions which do have a logged IP.

I can't duplicate this behaviour with ssh here.

Perhaps your IP address resolves to a blank string on one of your DNS servers, probably the secondary if it happens only 10 per cent of the time (or just possibly a hosts file if these are distributed from a central repository). That would account for the missing (or white space) entry and be consistent with Soham's reading of the source.

"0.0.0.0" means that's a local user (not a remote login), probably invoked by application eg cronjob.

It happens because you use local system and 0.0.0.0 means ip address of all interfaces. If you think that maybe somebody hacked you try to setup full logging of shell including commands via ssh – http://blog.pointsoftware.ch/index.php/howto-bash-audit-command-logger/

I solved it by adding a script to ~/.bashrc the script finds the last telnet connection source IP address, Then you can add the IP to a log file or do whatever you need..

 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" 

沙龙