pts 登錄時“last”輸出中缺少 IP 資訊的原因?
我有五個 CentOS 6 linux 系統在工作,遇到了一個相當奇怪的問題,似乎只發生在我擁有的所有 linux 系統的使用者 ID
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 歷史黑客;但是,這並不能提供之前發生的事件的線索。所有系統都執行 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
**info(請注意,此自定義主機文件僅存在於有這些問題的其中一台機器上)[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
。中央作業系統 6
我正在跳過測試,因為我們已經知道
script
打開 pty 並使用 wtmp 註冊。放蕩不羈
- 項目: http: //freecode.com/projects/libuteempter
- 說明:libutempter 為 screen 和 xterm 等終端仿真器提供了一個庫介面,用於將使用者會話記錄到 utmp 和 wtmp 文件。
所以主要區別似乎是與
libutempter.so.0
CentOSscript
連結的額外庫()。使用 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
創建條目。在Line:245-247wtmp
中查看以下程式碼塊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
給.紅帽向後移植
有趣的是,upstream
util-linux-ng-2.17.2
居然不支持libutempter
. 似乎 Redhat 決定重新添加該支持。john@U64D211:~/tmp/util-linux-ng-2.17.2$ ./configure --help|grep utemp
上述命令返回空結果。
結論
因此,兩個發行版之間的行為差異不是錯誤,而是一種選擇。RedHat 決定支持該功能,而 Debian 跳過了它。