Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Chrooted SFTP & logging problems

408 views
Skip to first unread message

Rob

unread,
Aug 13, 2008, 6:09:44 AM8/13/08
to
I realise there's been a few posts on this before - but nothing seems
to be working for me! I need to log file transfers etc. from sftp
within the chrooted environment but no dice so far.
My environment is Solaris 10 (x86) with SSH 5.1p1 & syslog-ng 1.6.11.

--- segment from sshd_config---
Subsystem sftp internal-sftp -f auth -l info

Match Group sftponly
ChrootDirectory /export/home/%u
X11Forwarding no
AllowTcpForwarding no
ForceCommand internal-sftp
---

In syslog-ng I have the following source statement:

source syslog {
internal();
sun-streams("/dev/log" door("/var/run/syslog_door"));
udp(ip(0.0.0.0) port(514));
unix-stream("/export/home/myuser/dev/log");
};

---
/export/home/myuser/dev exists and the log socket in there is created
by syslog-ng:

ls -l /export/home/myuser/dev/log
srw-rw-rw- 1 root myuser 0 Aug 13 09:42 /export/home/
myuser/dev/log


The chroot environment works fine and all is jailed correctly. But
logging stops beyond the initial login:

Aug 13 11:02:20 myserver sshd[9356]: [ID 800047 auth.info] Accepted
keyboard-interactive/pam for myuser from ww.xx.yy.zz port 57300 ssh2

and that's it. Any users not in group sftponly (i.e non-chroot) log
correctly like this:

Aug 13 11:03:34 myserver sshd[9387]: [ID 800047 auth.info] Accepted
keyboard-interactive/pam for nonchrootuser from ww.xx.yy.zz port 57306
ssh2
Aug 13 11:03:34 myserver sshd[9391]: [ID 800047 auth.info] subsystem
request for sftp
Aug 13 11:03:34 myserver internal-sftp[9392]: [ID 800047 auth.info]
session opened for local user nonchrootuser from [ww.xx.yy.zz]
Aug 13 11:03:36 myserver internal-sftp[9392]: [ID 800047 auth.info]
opendir "/export/home/nonchrootuser/"
Aug 13 11:03:36 myserver internal-sftp[9392]: [ID 800047 auth.info]
closedir "/export/home/nonchrootuser/"
...etc.


I wonder whether the ForceCommand statement needs arguments to
internal-sftp - but this doesn't appear to work - user authenticates
then is kicked out. I've tried placing the ForceCommand command in
double quotes, single quotes, escaped args etc. Permissions on the
home dirs & below appear OK (owner root, group myuser).

I'm not sure if this is a syslog-ng thing or ssh? I've tried looking
at what files are open with syslog-ng &/or ssh and recreated those in
the jail (i.e mknod on the chrooted /dev/null, /dev/sysmsg & a variety
of others).


Rob

unread,
Aug 18, 2008, 8:41:24 AM8/18/08
to
I've tried this also creating a second sun-streams source rather than
the unix-stream mentioned above - i.e:

sun-streams("/export/home/myuser/dev/log" door("/export/home/myuser/
var/run/syslog_door"));

I had to create /export/home/myuser/dev/log using mknod (using same
major/minor numbers as the real /dev/log). The door file was created
automatically. Still no joy.

François Garillot

unread,
Aug 19, 2008, 12:39:50 PM8/19/08
to
Rob prated on Sha'ban 10, 1429:

> I realise there's been a few posts on this before - but nothing seems
> to be working for me! I need to log file transfers etc. from sftp
> within the chrooted environment but no dice so far.
> My environment is Solaris 10 (x86) with SSH 5.1p1 & syslog-ng 1.6.11.
>
> --- segment from sshd_config---
> Subsystem sftp internal-sftp -f auth -l info
>
> Match Group sftponly
> ChrootDirectory /export/home/%u
> X11Forwarding no
> AllowTcpForwarding no
> ForceCommand internal-sftp

I think I'm running into the same problem. I notice you are using the
ForceCommand directive. For me, suppressing it restores logging, which
would indicate an ssh problem. Is it the same for you ?

Apparently, some people have also encountered this issue with syslogd:

http://lists.mindrot.org/pipermail/openssh-unix-dev/2008-June/026526.html
http://lists.mindrot.org/pipermail/openssh-unix-dev/2008-June/026557.html

--
FG

François Garillot

unread,
Aug 19, 2008, 12:54:17 PM8/19/08
to
François Garillot asserted on Day 2 of week 34 of 2008:

See also the very recent patch proposal for passing arguments to
ForceCommand:

http://lists.mindrot.org/pipermail/openssh-unix-dev/2008-August/026776.html

--
FG

Rob

unread,
Aug 20, 2008, 4:54:37 AM8/20/08
to
On Aug 19, 5:39 pm, francois.garillot_NO@SPAM_free.fr (François
> http://lists.mindrot.org/pipermail/openssh-unix-dev/2008-June/026526....http://lists.mindrot.org/pipermail/openssh-unix-dev/2008-June/026557....
>
> --
> FG

Hi - no I don't see the same problem. I've just tried again
commenting out ForceCommand - it works exactly as with it uncommented.
Are you using Solaris? I'm wondering whether I'm encountering issues
with the syslog-ng config (I need to run syslog-ng instead of regular
syslogd due to some extra features it gives me) which is just
confusing the issue. I'll check out the links - thanks!

Rob

unread,
Aug 20, 2008, 5:53:51 AM8/20/08
to
I tried one of the suggested patches to session.c which allows
arguments to the 'ForceCommand internal-sftp'.
This fixes the problem of getting kicked out of sftp after login then
the 'ForceCommand internal-sftp' has arguments specified. I'm still
not getting the required logging though.

I then tried removing the ChrootDirectory from the Match directive to
see whether the 'ForceCommand internal-sftp' arguments were actually
working. They are! Remove the arguments and login as the Match
user, no logging, add the arguments and login as the Match user,
arguments are recognised! This is a step forward as this now tells me
it's my syslog-ng config that's at fault now.

I'll try and fix the syslog-ng config and do some more tests. I get
the impression that maybe your chroot syslogging is working OK, but
you need the patch. I used this one:

http://lists.mindrot.org/pipermail/openssh-unix-dev/2008-August/026781.html

My cut and paste of the patch into a patch file meant the context diff
file was a bit corrupted so I added the changes by hand (hacky).

Rob

unread,
Aug 21, 2008, 6:33:06 AM8/21/08
to
Got it - I needed to the patch to openssh 5.1p1 (which'll hopefully
rolled into future versions) to enable parameters to the 'ForceCommand
internal-sftp' in the link mentioned earlier:

http://lists.mindrot.org/pipermail/openssh-unix-dev/2008-August/026781.html

And on Solaris 10 x86 using syslog-ng, all I needed was the existence
of the /dev/conslog device file in the chroot jail (writeable by the
chroot user as well).
Perms are quite tricky too.

Create the device file:
% ls -lL /dev/conslog
crw-rw-rw- 1 root sys 21, 0 Jun 5 14:36 /dev/conslog
% mkdir /export/home/chrootuser/dev
% mknod /export/home/chrootuser/dev/conslog c 21 0

Set perms:
% chown root:chrootusergroup /export/home/chrootuser /export/home/
chrootuser/dev /export/home/chrootuser/dev/conslog
% chmod 710 /export/home/chrootuser /export/home/chrootuser/dev
% chmod 660 /export/home/chrootuser/dev/log

Now my main problem is the start directory. Because the top of the
jail needs to be mode 750 (I may be able to do away with this by not
using strict modes in ssh) I need to set a start directory for the
sftp user. This will hide the dev directory as well. Figuring how to
do this.


Rob

unread,
Aug 21, 2008, 7:02:14 AM8/21/08
to
To set a start directory, just set the home directory of the
chrootuser in /etc/passwd to the value it would be when the user is in
the chroot jail:

e.g:

% mkdir /export/home/chrootuser/home
% chown root:chrootuser /export/home/chrootuser/home
% chmod 770 /export/home/chrootuser/home # so chrootuser can actually
write to it

Set the homedir in /etc/passwd:
chrootuser:x:60011:1003:Test SFTP User:/home:/bin/false

One more thing. The mode on the top level of the jail in my post
before is incorrect - this should be set to 750, not 710. This means
chrootuser can go up one level and see the dev & home folders but
can't write anything except to the home folder. There may be potential
for writing to /dev/conslog in the jail and inserting duff log entries
- but they'd need to know the file was called /dev/conslog (you can't
'ls' on this to figure it's there) and also be able to write.
Potentially you could upload a file with syslog instructions in it?)
This is a possible vulnerability but this must be common to most
chroot environments which require a log device of some description.

0 new messages