Solved Logging in chroot directory for SFTP

yocalebo

yocalebo

Hello all,

I'm having issues logging in a chroot environment and I can't seem to figure it out. I've got the chroot environment set up correctly and logging in works as expected. However, I'm only receiving log messages for sshd and not the internal-sftp subsystem. I've read the man pages on syslogd(8) and it specifies that it has to have a /dev/log socket set up in the chroot folder. So here is what I've done.

Code: 
Match Group group1
  PasswordAuthentication yes
  ChrootDirectory /sftp/chroot
  ForceCommand internal-sftp
  AllowTcpForwarding no
  AllowAgentForwarding no
  PermitTunnel no
  PermitTTY no
  X11Forwarding no

Code: 
root@ftp:/ #mkdir /sftp/chroot/dev
root@ftp:/ #chmod 755 /sftp/chroot/dev
root@ftp:/ #touch /sftp/chroot/dev/log

Code: 
root@ftp:/ # vi /etc/rc.conf
syslogd_flags="-s -l /sftp/chroot/dev/log"

After I did this, I restarted all necessary services (sshd, syslogd) but when I cat /sftp/chroot/dev/log, I'm presented with this error message.

Code: 
root@ftp:/ # cat /sftp/chroot/dev/log
cat: /sftp/chroot/dev/log: Protocol wrong type for socket

I'm still able to successfully connect to the server but when I look at auth.log it is just logging the sshd subsytem and not the internal-sftp subsystem. Any hints or suggestions from the community? I feel like I'm missing something very simple. Thanks in advance! FreeBSD is awesome!
 
Oh, I see. Once I change permissions to 755 on /sftp/chroot/dev directory, syslogd(8) should (in theory) have access to that directory and can create the log file. I'll try it out and let you know.

Thanks for the help!
 
Thanks for the help! Made some progress but still not working. After the change, syslogd(8) created the log file in /sftp/chroot/dev/. However, when I cat /sftp/chroot/dev/log, I'm still getting this error message.

Code: 
root@ftp # cat /sftp/chroot/dev/log
cat: /sftp/chroot/dev/log: Protocol wrong type for socket.
 
Okay, I understand that makes sense, now. I was getting suspicious. Anyways, I've left /etc/syslog.conf at it's default but when I log in with a test user, this is all I see in the /var/log/auth.log file. It just seems to be showing accepted connections.

Code: 
root@ftp: # cat/var/log/auth.log
Jul 20 16:18:09 ftp sshd[72118]: Accepted keyboard-interactive/pam for test from 10.2.128.160 port 22633 ssh2

I even uploaded a file and deleted it but am still not seeing anything in the log files to correlate that.
 
If the given link does not help, I can take a look a document at work, where our procedure to enable full logging is documented and described.

So please give a feedback if it is neccessary.
Regards
Markus
 
tobik said:
Does this help? https://en.wikibooks.org/wiki/OpenSSH/Logging#Logging_SFTP_File_Transfers
Click to expand...
Actually, that helped me out tremendously. However, I read the "Logging SFTP File Transfers" section and the "Logging Chrooted SFTP" sections. When I read the "Logging Chrooted SFTP" section that's where I noticed that a /dev/log node needed to exist in the chrooted directory.

It says:
Code: 
Logging the built-in sftp-subsystem inside a chroot jail needs a /dev/log node to exist inside the jail. This can be done by having the system logger such as syslogd add additional log sockets when starting up. On some systems that is as simple as adding more flags, like "-u -a /chroot/dev/log", in /etc/rc.conf.local or whatever the equivalent startup script may be.

So when I setup the /dev/log node in the chrooted directory, syslogd creates the log file as expected but auth.log is only showing log entries for the sshd subsystem and not the internal-sftp subsystem.

I went ahead and changed this:

Code: 
Match Group group1
PasswordAuthentication yes
ChrootDirectory /sftp/chroot
ForceCommand internal-sftp
AllowTcpForwarding no
AllowAgentForwarding no
PermitTunnel no
PermitTTY no
X11Forwarding no

Code: 
Match Group group1
PasswordAuthentication yes
ChrootDirectory /sftp/chroot
ForceCommand internal-sftp -l INFO
AllowTcpForwarding no
AllowAgentForwarding no
PermitTunnel no
PermitTTY no
X11Forwarding no

However, that still didn't seem to fix it. Thanks for the wiki article!
 
storvi_net said:
If the given link does not help, I can take a look a document at work, where our procedure to enable full logging is documented and described.

So please give a feedback if it is neccessary.
Regards
Markus
Click to expand...

I'm completely stumped on this logging issue. If you could provide the documentation that your company uses, without you getting in trouble, I'd greatly appreciate that!
 
Please try this:

Create directories:
/sftpchroot (root:root 755)
/sftpchroot/home (root:root 755)
/sftpchroot/home/username (root:root 755)
/sftpchroot/home/username/dev (root:root 711)
/sftpchroot/home/username/incoming (username:root 750)
/sftpchroot/keys (root:sftponly 710)
/sftpchroot/keys/username (root:sftponly 710)

Create file
/sftpchroot/keys/username/autorized_keys_for_sftp

We use a separate instance just for SFTP (beside the default one, but you can try to adjust your main config to your need:
sshd_config:
Code: 
ListenAddress aaa.bbb.ccc.dddd
Port 22

Protocol 2
SyslogFacility AUTH
LogLevel VERBOSE
AuthorizedKeysFile /sftpchroot/keys/%u/authorized_keys_for_sftp
LoginGraceTime 30s
PermitRootLogin no
StrictModes yes
MaxAuthTries 2
MaxSessions 10
PasswordAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
AllowAgentForwarding no
AllowTcpForwarding no
GatewayPorts no
X11Forwarding no
PermitTunnel no
ClientAliveInterval 20
ClientAliveCountMax 3
UsePrivilegeSeparation yes

Banner /opt/app/openssh5/etc/banner_sftp-test
# override default of no subsystems
Subsystem sftp internal-sftp -l VERBOSE –f AUTH

# These lines must appear at the *end* of sshd_config
Match Group sftponly
ForceCommand internal-sftp –l VERBOSE –f AUTH
ChrootDirectory /sftpchroot/home/%u
AllowTcpForwarding no
AllowAgentForwarding no
PasswordAuthentication no
PermitRootLogin no
X11Forwarding no

Copy the ssh-key to /sftpchroot/keys/username/authorized_keys_for_sftp
Code: 
from=”ip-of-client”,command="internal-sftp -l VERBOSE –f AUTH",no-agent- forwarding,no-pty,no-user-rc,
no-X11-forwarding,no-port-forwarding ssh-rsa AAAB3NzaC1yc2EAAAABIwAAA...

Now it could be tricky.
Under Linux we use "bind-mounts" to link the /dev/log and the user-log.

Probably it works with the nullfs-part of FreeBSD - this is on you to test:
touch /sftpchroot/home/username/dev/log
chown root:root /sftpchroot/home/username/dev/log
chmod 644 /sftpchroot/home/username/dev/log
mount_nullfs /dev/log /sftpchroot/home/username/dev/log

It this works, you have to take care about the initscript, that for every user such a mount is available (if the syslog is restarted they must be unmounted/mounted...).
 
Thanks for the info. Let me see if I can modify these to my server and I'll let you know how it goes!

I'm using the mount_nullfs(8) command currently in another aspect on the system but I didn't think about using it for this. I'll try this and let you know!
 
I got it to work! (With the help of you guys, of course). Here is what I did to get logging setup.

Make the directories as follows:
Code: 
/sftp (root:wheel 755)
/sftp/chroot (root:wheel 755)
/sftp/chroot/home (root:wheel 755)
/sftp/chroot/home/user1 (root:wheel
/sftp/chroot/home/user1/dev (root:wheel 755)

Edit rc.conf and add the following:
Code: 
syslogd_flags="-s -l /sftp/chroot/home/user1/dev/log"

Edit /etc/ssh/sshd_config and add the following:
Code: 
.....
# override default of no subsystems
#Subsystem     sftp     /usr/libexec/sftp-server
Subsystem     sftp     internal-sftp -l INFO -f AUTH
.....
Match Group *groupname*
  PasswordAuthentication yes
  ChrootDirectory /sftp/chroot/home
  ForceCommand internal-sftp -l INFO -f AUTH
  AllowTcpForwarding no
  AllowAgentForwarding no
  PermitTunnel no
  PermitTTY no
  X11Forwarding no

Restart necessary services:
service syslogd restart
service sshd restart

Login in with a user that has all the necessary permissions and you should now be seeing logging information for that user in /var/log/auth.log!

Thanks for all the help! Consider this resolved!
 
You must log in or register to reply here.
Back
Top