如何找出以 root 身份登录的用户?

Aar*_*lla 7 ssh root user logging

我们有几台服务器,由一大群管理员管理。他们通常以服务用户的身份登录(比如hudson),然后切换root到进行一些小的修复。这意味着我们通常无法映射对一个人所做的更改。

有没有人有 Unix/Linux 的脚本可以告诉我哪个用户以 root 身份登录?可以从本地 LAN 上的所有计算机登录。无法以 root 身份从 LAN 外部进行远程访问;管理员必须首先使用 LAN 用户登录,然后才能将自己提升为 root(他们都使用 SSH)。

我想要的是一个脚本,它遵循远程登录(在本地 LAN 中)并在一段时间内打印用户名。您可以假设该脚本可以通过 ssh 以 root 身份登录到本地 LAN 上的任何计算机,而无需输入密码。

背景:我有一个脚本可以保存由 root 编辑的所有文件的备份副本。问题是找出谁真正做出了改变。

安全不是问题;这不是寻找可能已经清除的黑客wtmp,而是找出谁犯了错误以提供反馈。

[编辑]一些提示:该命令last有助于:

> last -t 20101029174200 root
root     pts/26       :0.0             Wed Oct 20 15:36 - 15:03  (23:27)    

wtmp begins Fri Oct  1 16:34:36 2010
Run Code Online (Sandbox Code Playgroud)

所以root是通过pts/26. 还有谁坐在那个伪 TTY 上?

> last -t 20101029174200 pts/26
adigulla pts/26       :0               Mon Oct 25 09:45   still logged in   
adigulla pts/26       :0               Fri Oct 22 14:00 - 17:29  (03:29)    
adigulla pts/26       :0               Thu Oct 21 15:04 - 16:05  (01:01)    
root     pts/26       :0.0             Wed Oct 20 15:36 - 15:03  (23:27)    
adigulla pts/26       :0.0             Fri Oct 15 15:57 - 15:57  (00:00)    

wtmp begins Fri Oct  1 16:34:36 2010
Run Code Online (Sandbox Code Playgroud)

嗯……一定是我。所以我可以在本地机器上跟踪用户的变化。如果我登录到远程机器:

$ last -1 hudson 
hudson   pts/0        192.168.0.51     Fri Oct 29 17:52   still logged in   
Run Code Online (Sandbox Code Playgroud)

所以我得到了我来自哪里的 PTY 和 IP 地址。如何建立从lastfor输出hudson到用户 on 的连接192.168.0.51

[EDIT2]另请注意,我们通常使用ssh、 不sudo或更改用户su。这允许单点登录并避免告诉管理员任何密码。如果我们想授予/撤销对某些内容的访问权限,我们只需从服务帐户中添加/删除公钥。我也知道 ssh 记录到 syslog 但消息没有告诉我哪个用户切换到 root:

sshd[7460]: Accepted publickey for root from ::1 port 36689 ssh2
Run Code Online (Sandbox Code Playgroud)

Red*_*ick 3

我认为向错误以 root 身份登录的管理员提供反馈的最佳方法是禁用 root 登录,同时仍然允许 su 和 sudo。或者让 root 的 .profile 显示合适的反馈消息,然后选择退出。

如果管理员以外的任何人错误地以 root 身份登录,那么您至少需要更改 root 的密码:-)


好的,您已经修改了问题以澄清您想要实现的目标。您需要最大限度地减少允许登录的服务数量,并确保所有服务都记录成功登录。SSH 通过系统日志记录成功登录。

如果您有多个人以“hudson”身份登录,您需要阻止这种情况。它应该是一个站点策略,用于管理使用唯一用户 ID 的每次登录。

您需要确保调整日志文件轮换,以便您可以在需要的任何时间段搜索较旧的日志。

您当然可以有一个由 cron 安排的脚本,每天从 syslog 进行 grep 登录,并且还检查关键配置文件的时间戳。

此外,还有很多用于监视配置文件更改的工具。许多 Unix 系统都有一个可以启用的审计子系统,这也可以提供帮助。

就我个人而言,我认为在发生错误时提供反馈的最佳方式不是寻找某人来指责,而是向整个团队解释问题,解释为什么改变是错误的,并征求防止错误的想法。