On Tue, Nov 04, 2025 at 12:33:51PM +0000, P T via IBM TechXchange Community wrote:
> Make sftp logging works also when chrooted. Currently the logging breaks when sftp chroot. At least this is documented:
>
> On some systems, sftp-server must be able to access /dev/log
> for logging to work, and use of sftp-server in a chroot
> configuration therefore requires that syslogd(8) establish a
> logging socket inside the chroot directory.
You can make SFTPD log transfers in a chroot. You have to create a log
device in your chroot, and enable it with syslogd.
In /etc/ssh/sshd_config, replace:
Subsystem sftp /usr/sbin/sftp-server
with:
Subsystem sftp internal-sftp -f AUTH -l VERBOSE -u 002
You need to update the match command for specific users, or consider
running an SFTP only sshd on another port (my preference).
Add these to /etc/ssh/sshd_config and customize the match:
Match User !root
ChrootDirectory /sftproot/
ForceCommand internal-sftp -f AUTH -l VERBOSE -u 002
Create your sftproot:
mkdir -p /sftproot/dev
chown root:system /sftproot/dev
chmod 755 /sftproot/dev
chown root:system /sftproot
chmod 755 /sftproot
mknod /sftproot/dev/null c 2 2
chmod 666 /sftproot/dev/null
Update syslog to open a log device:
chssys -s syslogd -a "-r -R -n -A /sftproot/dev/log"
stopsrc -s syslogd
startsrc -s syslogd
The /sftproot/dev/log device is created by syslogd when it starts.
Now all sftp commands, including up and download should be logged to
syslog.
Thanks.
------------------------------------------------------------------
Russell Adams
Russell.Adams@AdamsSystems.nlPrincipal Consultant Adams Systems Consultancy
https://adamssystems.nl/
Original Message:
Sent: 11/4/2025 7:34:00 AM
From: P T
Subject: RE: OpenSSH 9.9: oslevel invocation causes login delays
If I had to propose sshd improvements, that would be:
- Make EFS and Audit support optional through config switches. There is another bug we noticed on the current version: PrintLastLog switch has been (silently) removed! The last login information is always fetched/printed, on ssh and sftp connections! I suppose, it is audit related.
- Let the parent sshd process determine the OS version once and pass it (trough environment) to the sessions.
- There are other ways to get the AIX version, for example the
tunsave script uses whatkernel from rsct and then parses bos.<kernel type> package info.
- Run the HW/OS checking after the user authentification
- Make sftp logging works also when chrooted. Currently the logging breaks when sftp chroot. At least this is documented:
On some systems, sftp-server must be able to access /dev/log
for logging to work, and use of sftp-server in a chroot
configuration therefore requires that syslogd(8) establish a
logging socket inside the chroot directory.
Best regards,
P. Tanovski
------------------------------
P T
------------------------------
Original Message:
Sent: Tue November 04, 2025 04:07 AM
From: José Pina Coelho
Subject: OpenSSH 9.9: oslevel invocation causes login delays
Ok, this has turned the "bad" dial all the way to 11...
On 7.3.3.1, just the main process "oslevel -r" forks 15 times, "oslevel -s" forks 23 times, then each process produces some output to be consumed by the original process...
One of those forks does an execve("/usr/bin/oslevel",...), so it seems to me that the oslevel code is exec'ing itself to get information it shouldn't need to exec itself for...
If like me you think sanity if overrated, you might feel tempted to "truss -af oslevel -r"...
302 kfork()
167 execve
100 getuidx
100 getgidx
...
Now multiply the effect by thousands of connections from an Ansible Tower or similar...
Just the noise of trusted execution logging and AIX syscall audit is enough justification for oslevel to be made SETUID and cache it's (complete) results.
Edit: Of course it's a shell script... one that's in dire need of optimization (many calls to awk could be merged, uniq right after sort, grep|grep|awk)