--- 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).
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.
> 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
> 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
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
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!
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).
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.
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.