SFTP Not functioning with chrooted accounts on CentOS 6

[websavers]

I've seen the KB article and threads about this issue with Ubuntu. The issue does not appear to be related in that the binaries and libraries for sftp-server are in place and seemingly correct on CentOS 6. I'm running Plesk 11.5.

Upon attempting to connect, Transmit (my SFTP/FTP client) indicates "The username or password was not accepted by the server"

It connects and works fine if I change the shell to /bin/bash without the chroot. It also works fine via FTP with TLS. I can also connect using the very same details via SSH and it works fine.

The log at /var/log/secure says:

sshd[1212]: Accepted password for jordan from 142.68.8.20 port 61346 ssh2
sshd[1212]: pam_unix(sshd:session): session opened for user jordan by (uid=0)
sshd[1449]: subsystem request for sftp
sshd[1449]: Received disconnect from 142.68.8.20: 11: disconnected by user
sshd[1212]: pam_unix(sshd:session): session closed for user jordan

It appears that as soon as my logged in user requests sftp, it disconnects me... likely due to some sort of failure to access the sftp subsystem. Yet the libnss shared objects are found within /lib and /lib64 of the chroot and /usr/libexec/openssh contains the sftp-server binary!

If I try to manually run ./sftp-server from that location via SSH in the chrooted account, I get:

Couldn't open /dev/null: Permission denied

Yet the permissions of sftp-server and all required libraries match exactly those on another server with an identical set-up and that server works perfectly fine for SFTP!

Any ideas on how I can resolve this?

SSHD Level 3 Debug log as follows:

Apr 4 17:56:24 vanilla sshd[7700]: subsystem request for sftp
Apr 4 17:56:24 vanilla sshd[7700]: debug1: subsystem: exec() /usr/libexec/openssh/sftp-server
Apr 4 17:56:24 vanilla sshd[7700]: debug3: mm_audit_run_command entering command /usr/libexec/openssh/sftp-server
Apr 4 17:56:24 vanilla sshd[7700]: debug3: mm_request_send entering: type 62
Apr 4 17:56:24 vanilla sshd[7508]: debug3: monitor_read: checking request 62
Apr 4 17:56:24 vanilla sshd[7508]: debug3: mm_answer_audit_command entering
Apr 4 17:56:24 vanilla sshd[7508]: debug2: session_new: allocate (allocated 0 max 10)
Apr 4 17:56:24 vanilla sshd[7508]: debug3: session_unused: session id 0 unused
Apr 4 17:56:24 vanilla sshd[7508]: debug1: session_new: session 0
Apr 4 17:56:24 vanilla sshd[7700]: debug3: mm_request_receive_expect entering: type 63
Apr 4 17:56:24 vanilla sshd[7700]: debug3: mm_request_receive entering
Apr 4 17:56:24 vanilla sshd[7508]: debug3: mm_request_send entering: type 63
Apr 4 17:56:24 vanilla sshd[7508]: debug3: mm_request_receive entering
Apr 4 17:56:24 vanilla sshd[7700]: debug2: fd 3 setting TCP_NODELAY
Apr 4 17:56:24 vanilla sshd[7700]: debug2: fd 9 setting O_NONBLOCK
Apr 4 17:56:24 vanilla sshd[7700]: debug2: fd 8 setting O_NONBLOCK
Apr 4 17:56:24 vanilla sshd[7700]: debug2: fd 11 setting O_NONBLOCK
Apr 4 17:56:24 vanilla sshd[7700]: debug3: Wrote 80 bytes for a total of 2021
Apr 4 17:56:24 vanilla sshd[7701]: debug3: channel 0: close_fds r -1 w -1 e -1 c -1
Apr 4 17:56:24 vanilla sshd[7700]: debug2: channel 0: read 43 from efd 11
Apr 4 17:56:24 vanilla sshd[7700]: debug3: channel 0: discard efd
Apr 4 17:56:24 vanilla sshd[7700]: debug2: channel 0: read<=0 rfd 9 len 0
Apr 4 17:56:24 vanilla sshd[7700]: debug2: channel 0: read failed
Apr 4 17:56:24 vanilla sshd[7700]: debug2: channel 0: close_read
Apr 4 17:56:24 vanilla sshd[7700]: debug2: channel 0: input open -> drain
Apr 4 17:56:24 vanilla sshd[7700]: debug2: channel 0: ibuf empty
Apr 4 17:56:24 vanilla sshd[7700]: debug2: channel 0: send eof
Apr 4 17:56:24 vanilla sshd[7700]: debug2: channel 0: input drain -> closed
Apr 4 17:56:24 vanilla sshd[7700]: debug3: Wrote 32 bytes for a total of 2053
Apr 4 17:56:24 vanilla sshd[7700]: debug1: Received SIGCHLD.

What I don't understand is whether the SIGCHLD is interrupting the SFTP process or whether the SFTP process is failing to load and thus sending a SIGCHLD. Either way I still don't understand why it's failing.