关于rsyslog无法记录chroot用户日志问题小记-Rain's Blog

以下内容的记录环境为Debian12/OpenSSH_9.2p1 Debian-2, OpenSSL 3.0.9 30 May 2023

起因

因为我经常使用markdown来写一些笔记，然而众所周知的原因markdown的图片是以链接引入的方式引用的，如果你想比较好的分享只能上传图床，思索半天决定使用闲置的腾讯云SG轻量+SFTP+Nginx的方式

但在基本业务部署完成后测试时，遇到了PicList无法删除云端文件的问题，于是尝试寻找日志排查问题。

根据网上的资料，首先尝试修改/etc/ssh/sshd_config，在指令后均加上-l INFO后重启sshd服务

# Subsystem sftp        /usr/lib/openssh/sftp-server
Subsystem sftp internal-sftp -l INFO -f local5
Match Group sftp
ChrootDirectory /data/wwwroot/html/%u
ForceCommand internal-sftp -l INFO -f local5
AllowTcpForwarding no
X11Forwarding no

然后观察/var/log/auth.log,结果仅查看到了用户登录的记录，详细的日志却完全没有，提示生成了一个子线程，然后其他日志就完全没了

2023-09-28T10:44:01.400700+08:00 TX-SG-01 systemd-logind[947]: New session 4077 of user piclist.
2023-09-28T10:44:01.414461+08:00 TX-SG-01 sshd[701494]: pam_env(sshd:session): deprecated reading of user environment enabled
2023-09-28T10:44:01.414608+08:00 TX-SG-01 sshd[701494]: User child is on pid 701504

仔细研究了半天，发现似乎是一个远古问题，由于涉及到了Linux本身的权限逻辑，所以一直没有很好的解决方案

大体上的原因是如果你启用了ChrootDirectory,那么sFTP将会调用chroot功能来进行多用户间的文件权限隔离，而chroot本质上是类似于沙箱的环境，这个环境会阻止非管理员权限用户对其主目录外的文件进行修改，那么就会造成处于chroot非管理员下的用户无法写入日志到系统日志中，是的你没看错，只要你启用了ChrootDirectory参数，那么除了管理员角色，其他用户的操作日志将完全无法记录，或许这是为了安全性而做的设计，但对于运维来说这就是个超级大麻烦，出问题时没有日志等于抓瞎无从下手。

解决方法

以下操作均以root权限进行

首先，为你的chroot目录下的每个普通用户的根目录下创建两个文件夹

mkdir -m2755 /your_chroot/one_user/dev
mkdir -m2755 /your_chroot/one_user/bin

然后，复制一份/bin/logger到每个普通用户根目录下的bin目录

cp /bin/logger mkdir /your_chroot/one_user/bin

最后，创建文件/etc/rsyslog.d/sftp.conf

# create additional sockets for the sftp chrooted users
module(load="imuxsock")
input(type="imuxsock" Socket=" /your_chroot/one_user/dev/log" CreatePath="on")
#input(type="imuxsock" Socket="/your_chroot/second_user/dev/log" CreatePath="on")

# log internal-sftp activity to sftp.log
if $programname == 'internal-sftp' then /var/log/sftp.log
& stop

到此对于文件的修改已经完成，重启sshd和rsyslog服务即可生效

service sshd restart
service rsyslog restart

如果在重启后，rsyslog有提示 'imuxsock' already in this config的字样，那么请将第一行module(load="imuxsock")注释掉即可解决

这个方法其实就是给chroot制作了一份镜像位置，由于chroot下普通用户的根目录就相当于系统的根目录，那么只需要做一个对应的路径就可以了。

另外这个方法虽然可以解决日志记录的问题，但也同样因为chroot的隔离环境，普通用户是无法访问到系统的时间的，那么记录的日志时间戳可能会存在一些问题，解决方案也很简单，拷贝一份系统的localtime即可

mkdir /your_chroot/one_user/etc
cp -af /etc/localtime /your_chroot/one_user/etc

总结

这算是一个远古遗留问题，在中文互联网上似乎没人对此有过详细的解释，最终还是Google英文关键词才找到的解决方案，问题其实很明显，解决方案也十分的简单，主要还是没想到原因,用了这么久Linux才碰到chroot

参考资料

文章版权由CC-BY-NC-SA 4.0协议分发共享

THE END