[scponly] Troubles with scponly-4.8

[Kaleb Pederson]

On Friday, October 29, 2010 06:29:16 am Gary Autiello wrote:
> 
> 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.

If your old system wasn't 64-bit, I wouldn't trust it completely, although it could serve as a good template for the files that are necessary. If you create the symlink between the lib and lib64 directories, cplibdeps should safely update the libraries.

Every time there's a critical update (e.g. a vulnerability in sftp-server) to one of the applications you've copied to your chroot, you'll need to re-run cplibdeps for that application and then ldconfig in order to bring everything back up to date.

> 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?

That option was for the earlier "sftp-logging patch" that is no longer relevant. I'd recommend that you reconfigure without that option. I'm going to remove that option in the next release of scponly (probably within the next couple of months as soon as I can test one recent change).

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

sftp-server's logging functionality relies on /dev/log being present within the chroot. You'll need to configure your syslog daemon to create a /path/to/chroot/dev/log socket at the time your syslog daemon is started.  Within standard syslog, you can do this with the '-a /path/to/dev/log' option.  With syslog-ng you can create another source with that as the path. In general, exactly how varies based on your syslog daemon.

> Thanks Kaleb!

Any time.

--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
>