[scponly] Troubles with scponly-4.8

[Gary Autiello]

Good morning Kaleb,

Ok so I think we figured it out finally.  It was definitely a problem with
the libraries for sure.  When you mentioned that there should be a link
between the lib64 and lib libraries, that struck an idea.  So basically I
copied a chrooted environment directly from our old box onto the new box.
Made a few tweaks and it worked!  So, the make jail script definitely
doesn't configure the library directories properly on a 64-bit system.  I'm
going to write my own script for creating a jailed user that should work
fine.

My last concern though now that I have the ability for the user to log in
is I don't see anything other than debugging info logging for scponly.  I
was under the impression that we could get sftp logging to work with
scponly.  Is there anything else we need to do other than configure with
the --enable-sftp-logging-compat option?  We have our subset setup in the
sshd_config log to log INFO to our local6 syslog.  However, we are only
seeing sftp logging for non-jailed users.

Thanks Kaleb!
______________________________________
Gary Autiello, Network +, MCITP
Network Administrator
Dominion Diagnostics, LLC
x886, 401-667-0886





From:	Kaleb Pederson <kaleb.pederson at gmail.com>
To:	Gary Autiello <gautiello at dominiondiagnostics.com>
Cc:	scponly at lists.ccs.neu.edu
Date:	10/28/2010 04:52 PM
Subject:	Re: Troubles with scponly-4.8



On Thursday, October 28, 2010 12:12:56 pm you wrote:
> Ok so I ran the ldconfig command and the output was:
>
> [root at garytest139 home]# ldconfig -r /apps/home/garytest/ -v

... snipping quite a bit

> ldconfig: /lib64/libcom_err.so.2 is not a symbolic link
> ldconfig: /usr/lib64/libz.so.1 is not a symbolic link
> ldconfig: /usr/lib64/libkrb5.so.3 is not a symbolic link
> ldconfig: /usr/lib64/libk5crypto.so.3 is not a symbolic link
> ldconfig: /usr/lib64/libgssapi_krb5.so.2 is not a symbolic link
> ldconfig: /usr/lib64/libkrb5support.so.0 is not a symbolic link

Remove each of the above files. They were copied into your chroot by the
jail script but they don't have the full versions on them.

> Further more, when I tried to connect and watched the secure log, I see
the
> following and no longer anything about the file/directory not existing:
...

> Oct 28 19:05:56 garytest139 scponly[5388]:
> running: /usr/libexec/openssh/sftp-server (username: garytest(813),
> IP/port: 192.168.9.11 38447 22)
> Oct 28 19:05:56 garytest139 scponly[5388]: about to exec
> "/usr/libexec/openssh/sftp-server" (username: garytest(813), IP/port:
> 192.168.9.11 38447 22)
> Oct 28 15:05:56 garytest139 sshd[5385]: pam_unix(sshd:session): session
> closed for user garytest

The sftp-server is now running, but it's missing pieces.

Looking at the 5575 log it looks like you're missing a number of NSS
pieces:

connect(3, {sa_family=AF_FILE, path="/var/run/nscd/socket"...}, 110) = -1
ENOENT (No such file or directory)
open("/lib64/tls/x86_64/libnss_compat.so.2", O_RDONLY) = -1 ENOENT (No such
file or directory)
open("/lib64/tls/libnss_compat.so.2", O_RDONLY) = -1 ENOENT (No such file
or directory)
open("/lib64/x86_64/libnss_compat.so.2", O_RDONLY) = -1 ENOENT (No such
file or directory)
open("/lib64/libnss_compat.so.2", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/usr/lib64/tls/x86_64/libnss_compat.so.2", O_RDONLY) = -1 ENOENT (No
such file or directory)
open("/usr/lib64/tls/libnss_compat.so.2", O_RDONLY) = -1 ENOENT (No such
file or directory)
open("/usr/lib64/x86_64/libnss_compat.so.2", O_RDONLY) = -1 ENOENT (No such
file or directory)
open("/usr/lib64/libnss_compat.so.2", O_RDONLY) = -1 ENOENT (No such file
or directory)

I.e. libnss_compat.so.2 isn't being found, although your earlier output
indicates it's at /lib/libnss_compat.so.2.  If your system is like
mine, /lib should be a symlink to /lib64.  If so, then delete /lib, symlink
it to /lib64, and then rerun cplibdeps so it copies the shared libraries
back over, and then re-run ldconfig so it regenerates the necessary
symlinks.

open("/lib64/libnss_files.so.2", O_RDONLY) = -1 ENOENT (No such file or
directory)

This doesn't show up as a dependency of sftp-server, but it's being sought
for, so maybe it should be copied into the chroot. Once the other stuff is
in place, it might not matter, but it won't hurt to copy it in (before you
rerun ldconfig).

These NSS problems eventually give us this:

write(2, "No user found for uid 813", 25) = -1 EPIPE (Broken pipe)

And that's where the sftp-server fails.  Note that you'll need to copy
in /etc/nsswitch.conf and perhaps a few other files as well. I usually
recommend a cron job for /etc/passwd (but not the shadow files) so that the
sftp-server can resolve uids.

Closer yet.

--Kaleb

CONFIDENTIALITY NOTICE: This e-mail, including attachments,
is for the sole use of the individual to whom it is addressed
This message is confidential and may contain information that
is privileged, confidential and is exempt from disclosure under
applicable law. Any unauthorized review, use, disclosure or
distribution is prohibited. If you have received this e-mail
in error, please notify the sender by reply e-mail and destroy
this message and its attachments

-------------- next part --------------
HTML attachment scrubbed and removed
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2C500404.jpg
Type: image/jpeg
Size: 5238 bytes
Desc: not available
Url : http://lists.ccs.neu.edu/pipermail/scponly/attachments/20101029/5c14b3d7/attachment.jpg 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
Url : http://lists.ccs.neu.edu/pipermail/scponly/attachments/20101029/5c14b3d7/attachment.gif