ssh subsystem internal-sftp chroot and logging

[Stoyan M Angelov]

hi all,

i have several "sftp only" chrooted accounts configured using hp's secure shell "Subsystem internal-sftp" feature.
the accounts are working fine, however i can not get logging to work and show details about transferred files (e.g. "xferlog like" logs).

i am using the latest version of secure shell (A.05.60.003) on hp-ux 11.31, ia64. the release notes mention a document called "How to Configure SFTP Logging in a Chrooted Environment" but i am unable to access it and it probably refers to the "Subsystem sftp /opt/ssh/libexec/sftp-server" + run-the-chroot-script setup method.

i have tried setting the parameters below - close, but no cigar:
Subsystem sftp internal-sftp -l VERBOSE -f LOCAL4
...
Match User someuser
ForceCommand internal-sftp -l VERBOSE -f LOCAL4

is there any way to get "xferlog like" logging while using "subsystem internal-sftp" chrooting?

[Earl_Crowder]

http://bizsupport2.austin.hp.com/bc/docs/support/SupportManual/c02549272/c02549272.pdf

"Users of chroot-ed HP-UX Secure Shell environments must be aware that a
subset of messages written by the sshd daemon will not show up in syslog."

This likely includes any file tranfer messages.

[Don Mallory · Accepted solution]

Hi Stoyan,

Unfortunately, you are being bitten by the challenges of a chrooted environment.

Your chrooted space cannot send the syslog events to the syslog daemon, because it exists outside the chrooted environment. The logs you are looking for live inside said chrooted environment because they are being generated fromt the sshd daemone living in that space (at that time).

You could build out a full chrooted space including a syslogd daemon and all the dependancies to support it, pointint to a separate set of logs, but this would have to be done per user, and there's a high likelihood that it would conflict with the host syslog daemon (although I'm not sure about this), and the logs would have to live within the same chrooted space. As well, you will find that to get syslogd working, you are going to need a lot of OS files to support it.

This would be one of the places that the GNU sysklogd (Linux syslogd) has done a better job. It allows you to add additional "sockets", which could be as simple as a /sftpchroot/usera/dev/syslog device file that would then append right back into the OS syslog daemon.

The downfall of this is that there's a limit to the options line length (you get about 8), or you use one and put all the users in a shared /sftpchroot dir. The downfall being that you would have to all them to know of each other's existence.

An option around this might be using rsyslog or syslog-ng, but unfortunately, I haven't had time to investigate either of these yet.

Best regards,
Don

[Stoyan M Angelov]

hi Don,

thanks for your thorough answer! i was able to make sftp logging work by building a chrooted space for syslogd as you suggested.

it works fine but i though that using "Subsystem sftp internal-sftp" there is some tricky way that makes it possible to skip the creation of all the (per-user) chroot environments and running their respective syslogd daemons.

thanks again for your help - it is much appreciated!


greetings,

Stoyan

[grahamswilson]

Not sure if its too late for points on this, but I've been through this exact same thing and found a great solution on a web site somewhere...(so I take no credit for it!)...

The trick is simply use the standard "Subsystem internal-sftp" feature as you orginally mentioned...then create a "fake" log somewhere like this :-

mknod /fake/dev/log p

Then for each user, mount "lofs" the directory above into the users chroot'ed directory - e.g.

mount -F lofs /fake/dev /home/username/dev

(Of course, make a /home/username/dev directory first.)

Thus it then looks like there is a "/dev/log" logfile when the user enters their SFTP jail.

Now what I think was the clever piece - run the following on the server :-

nohup cat /fake/dev/log > /dev/log &

So in other words, it looks to the system like there is a /dev/log file in the users chrooted area, and anything that goes into that is then simply "copied" to the real /dev/log...and it is then avaiable in the normal syslog!

(I didn't bother going through the permissions, but obviously you can make things locked down...)

I hope I've explained this OK - it works really really well and was very easy to implement and made things much easier...

[Stoyan M Angelov]

Earl and Don - thanks for your answers!

hi Graham,

that's and interesting suggestion for "centralizing" all the chrooted users logs - thanks!
however this does not unclutter the users environment from all the syslogd required libraries and all the per-user syslogd daemons that need to run.


greetings,

Stoyan

[grahamswilson]

Hi Stoyan,

ah - but it does! That what I really liked about this solution. You do NOT need to run any other syslogd requirements such as libraries and any per-user syslog daemons when using this concept in this way.

You literally don't need to run anything else except the magic "cat" line in my previous post...i.e. literally only one additional process which can easily be started at boot.

When I came accross the solution I thought it was too good to be true...and it is :)

[Stoyan M Angelov]

hi Graham,

my bad please excuse me - i spoke too soon :) your method works like a charm and that is exactly what i was looking for! i only had to change the "magic cat" a little bit:

nohup cat /fake/dev/log > /dev/log 2>&1 &

this is way cool - thank you!


cheers,

Stoyan