Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I would like to log SFTP commands to a separate file however it works only for root but not for chrooted user:

# cat /etc/ssh/sshd_config
...
Subsystem       sftp    internal-sftp -l INFO
Match Group user1
   ChrootDirectory /chroot
   ForceCommand internal-sftp -l INFO
   AllowTcpForwarding no
   X11Forwarding no

-

Default facility is AUTH according to man page

# cat /etc/rsyslog.d/sshd.conf
auth.* /var/log/sftp.log

-

tail -F /var/log/secure /var/log/sftp.log

==> /var/log/secure <==
Dec 27 12:35:09 lab sshd[43014]: Accepted publickey for root from 192.168.1.100 port 44706 ssh2
Dec 27 12:35:09 lab sshd[43014]: pam_unix(sshd:session): session opened for user root by (uid=0)
Dec 27 12:35:09 lab sshd[43014]: subsystem request for sftp

==> /var/log/sftp.log <==
Dec 27 12:35:09 lab internal-sftp[43016]: session opened for local user root from [192.168.1.100]
Dec 27 12:35:10 lab internal-sftp[43016]: opendir "/root/"
Dec 27 12:35:10 lab internal-sftp[43016]: closedir "/root/"
Dec 27 12:35:27 lab internal-sftp[43016]: session closed for local user root from [192.168.1.100]

==> /var/log/secure <==
Dec 27 12:35:27 lab sshd[43014]: Received disconnect from 192.168.1.100: 11: disconnected by user
Dec 27 12:35:27 lab sshd[43014]: pam_unix(sshd:session): session closed for user root
Dec 27 12:35:31 lab sshd[43017]: Accepted password for user1 from 192.168.1.100 port 44708 ssh2
Dec 27 12:35:31 lab sshd[43017]: pam_unix(sshd:session): session opened for user user1 by (uid=0)
Dec 27 12:35:31 lab sshd[43019]: subsystem request for sftp
Dec 27 12:35:31 lab sshd[43020]: session opened for local user user1 from [192.168.1.100]
Dec 27 12:35:31 lab sshd[43020]: opendir "/"
Dec 27 12:35:31 lab sshd[43020]: closedir "/"

EDIT: Mon Dec 30 11:40:18 GMT 2013

System: CentOS 6.5

I added the following options however events are still logged to the /var/log/secure log file:

# id user1
uid=501(user1) gid=501(user1) groups=501(user1)
# mkdir /chroot/dev
# cat /etc/rsyslog.d/sshd.conf
$AddUnixListenSocket /chroot/dev/log
auth.* /chroot/dev/sftp.log
# service rsyslog restart
Shutting down system logger:                               [  OK  ]
Starting system logger:                                    [  OK  ]
# ll /chroot/dev/
total 0
srw-rw-rw- 1 root   root   0 Dec 30 11:44 log
-rw------- 1 nobody nobody 0 Dec 30 11:39 sftp.log
share|improve this question
    
did you try using Match User user1? because you wrote Match Group but user1 isn't a group but is a user –  c4f4t0r Dec 30 '13 at 9:42
    
What is your definition for the group "user1"? –  Nils Dec 30 '13 at 9:58
    
Still doesn't work on CentOS 6.5 even after applying the "accepted" answer and all the comments. The sshd is still opening /dev/log before it does chroot. WTF... –  kubanczyk Jun 13 at 11:09

1 Answer 1

up vote 1 down vote accepted
+50

According to this link I believe you meet one of three criteria for having detailed logging of chrooted sftp users:

  • detailed logging must be configured in the sftpd config. You appear to have done so using the "ForceCommand internal-sftp -l INFO" directive.
  • a log file must be specified inside of the chrooted directory, as a chrooted user does not have permission to write to the /var/log directory.
  • a logging socket must be added to rsyslogd to facilitate logging to the new log file.

Comparing other links such as this generic instruction and this CentOS instruction it appears that the exact configuration varies slightly between distros with regards to preferred custom directory names for the logging path, the exact file where to place the logging socket config and the expression of the logging socket config.

[EDIT] Mon Dec 30 21:50:00 GMT 2013

I don't have access to a CentOS at the moment but found what appears to be an excellent guide in a link in the CentOS-page above. The link is broken but I could access the page through the Waybackmachine. But as the guide seems at risk of disappearing, I'm now going to blatantly copy the parts relevant to your questions in a magnificent quote below. Hopefully it will help you, but as said at the moment I have no means of testing on the distro you use.

It appears you have done some things differently, so fingers crossed you will strike gold below.

--Start quote from bigmite.com in Waybackmachine--


Chroot Configuration

In this example I am going to set up a group of users that require SFTP access only (no SSH) and are going to copy files to a filesystem on a SFTP server. The location of the filesystem is going to be /sftp and users will reside in seperate folders under here.

Initially a new group should be created, here called “sftpuser”. Each user that requires SFTP access will be placed in this group.

The sshd_config (on debian in /etc/ssh) should be edited and the following added on the end:-

Match group sftpuser
 ChrootDirectory /sftp/%u
 X11Forwarding no
 AllowTcpForwarding no
 ForceCommand internal-sftp -l VERBOSE -f LOCAL6

This does the following:-

  1. Forces all users connecting via ssh on port 22 to have sftp only
  2. Runs their sftp session in a chroot jail in directory /sftp/$USER
  3. Prevents them TCP of X11 forwarding connections
  4. Runs the internal sftp server getting it to log verbose and to syslog channel name LOCAL6

Now a user should be created, without creating a home directory and in the default group sftpuser. On ubuntu you can enter:-

(Line break added by me for readability! /E)

adduser --home / --gecos "First Test SFTP User" --group sftpuser --no-create-home
--shell /bin/false testuser1

The reason the home directory is set to / is that the sftp will chroot to /sftp/testuser1. Next the users home directory will need creating:-

mkdir /sftp/testuser1
chmod 755 /sftp/testuser1
mkdir /sftp/tstuser1/in
mkdir /sftp/testuser1/out
chown testuser1 /sftp/testuse1/in

Note that the directory structure and permissions that you set may differ depending on your requirements. The users password should be set, and sshd restarted (on debian service ssh restart).

Now it should be possible to sftp files to the host using the command line sftp tool, but it should not be possible to ssh to the server as user testuser1.

Logging

You will see verbose sftp logging being produced in the /var/logmessages for each chroot’ed user, where by default this should go to the daemon.log. The reason for this is that the chroot’ed sftp process can not open /dev/log as this is not within the chrooted filesystem.

There are two fixes to this problem, depending on the filesystem configuration.

If the users sftp directory /sftp/user is on the root filesystem

You can create a hard link to mimic the device:-

mkdir /sftp/testuser1/dev
chmod 755 /sftp/testuser1/dev
ln /dev/log /sftp/testuser1/dev/log

If the users sftp directory is NOT on the root filesystem

First syslog or rsyslog will need use an additonal logging socket within the users filesystem. For my example /sftp is a seperate sftp filesystem.

For Redhat

On redhat syslog is used, so I altered /etc/sysconfif/syslog so that the line:-

SYSLOGD_OPTIONS="-m 0"

reads:-

SYSLOGD_OPTIONS="-m 0 -a /sftp/sftp.log.socket

Finally the syslog daemon needs to be told to log messages for LOCAL6 to the /var/log/sftp.log file, so the following was added to /etc/syslog.conf:-

# For SFTP logging
local6.*                        /var/log/sftp.log

and syslog was restarted.

For Ubuntu Lucid

On Ubuntu lucid I created /etc/rsyslog.d/sshd.conf containing:-

# Create an additional socket for some of the sshd chrooted users.
$AddUnixListenSocket /sftp/sftp.log.socket
# Log internal-sftp in a separate file
:programname, isequal, "internal-sftp" -/var/log/sftp.log
:programname, isequal, "internal-sftp" ~

… and restarted rsyslogd.

Creating log devices for users

Now for each user a /dev/log device needs creating:-

mkdir /sftp/testuser1/dev
chmod 755 /sftp/testuser1/dev
ln /sftp/sftp.log.socket /sftp/testuser1/dev/log

--End quote--

share|improve this answer
    
Hi, thanks for your reply. I've made the recommended changes however it still doesn't work (please see my edit - EDIT: Mon Dec 30 11:40:18 GMT 2013). –  HTF Dec 30 '13 at 11:47
    
Unfortunately none of these configuration options work for me but thanks for your effort. –  HTF Dec 31 '13 at 9:57
    
Thanks! I tried answering as I have the very same task to solve in my backlog, albeit for BSD. I will return to this question when I do and give it a tried and tested shot. –  ErikE Dec 31 '13 at 10:25

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.