[scponly] Troubles with scponly-4.8

Mon Nov 1 16:28:28 EDT 2010

Hey Kaleb,

The first sftp-client I was using was from a 32-bit RHEL4 machine with the
following package:

openssh-clients-3.9p1-8.RHEL4.17.1

I went ahead and tried to connect to the scponly server using a newer
64-bit RHEL5 server with the installed package:

openssh-clients-4.3p2-36.el5_4.3

As far as the lastest sftp-server component, I'm using the following
package on the SFTP server where scponly is installed:

openssh-server-5.2p1-1

Attached are the new strace logs from the newer sftp-client connection.

Thanks again,

(See attached file: strace_log.txt.22585)(See attached file:
strace_log.txt.22586)(See attached file: strace_log.txt.22546)
______________________________________
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:	Joe Morin <jmorin at dominiondiagnostics.com>,
            scponly at lists.ccs.neu.edu
Date:	11/01/2010 04:09 PM
Subject:	Re: Troubles with scponly-4.8

Gary,

I'm not seeing any logging requests from the sftp-client.  Are you
using the latest sftp-client from your new 64-bit install or the older
one that you copied over?  You'll want to make sure you're using the
latest sftp-server which supports the extra logging features.

If so, please add a '-s 1024' to the strace command line and resend.

--Kaleb

On Mon, Nov 1, 2010 at 10:39 AM, Gary Autiello
<gautiello at dominiondiagnostics.com> wrote:
>
> Hi Kaleb,
>
> Please see the following screen shots for each numbered item:
>
> Kaleb Pederson ---11/01/2010 12:35:13 PM---Gary, Here's all the steps
needed to capture logging information from the sftp
>
> From: Kaleb Pederson <kaleb.pederson at gmail.com>
> To: Gary Autiello <gautiello at dominiondiagnostics.com>
> Cc: Joe Morin <jmorin at dominiondiagnostics.com>, scponly at lists.ccs.neu.edu
> Date: 11/01/2010 12:35 PM
> Subject: Re: Troubles with scponly-4.8
> ________________________________
>
>
> Gary,
>
> Here's all the steps needed to capture logging information from the sftp
client within a chrooted environment in case things didn't happen in the
right order:
>
> 1) Configure syslog using -a /path/to/chroot/dev/log so that it knows to
create the /dev/log within the chroot.
> 2) Restart syslog daemon and verify that /path/to/chroot/dev/log is
created
> 3) Configure OpenSSH's SyslogFacility and LogLevel so that the
sftp-server is started with those additional arguments
> 4) Set /etc/debuglevel to 1 and verify that when a connection is made
sftp-server is started with the additional facility and level arguments
> 5) Verify that the syslog has been configured to capture the facility and
log levels to the desired log file(s).
>
> If the above has all been done, then everything should work. If it
doesn't, here's what I would need to see:
>
> a) An `ls -l` showing that /dev/log exists within the chroot
> b) The scponly debug output (set to level 1) that shows that the
sftp-server was started with the additional logging flags.
>
> If those two things are happening it's likely one of two problems:
>
> i) The /dev/log is stale and is no longer being listened to
> ii) The syslog daemon isn't correctly configured to log to the desired
file(s)
>
> If you're still at wits end after all the above, then go through the
strace steps and attach.  I can then verify parts (a) and (b) above.
>
> If anybody else feels I missed anything, please let me know.
>
> Thanks.
>
> --Kaleb
>
>
>
> On Mon, Nov 1, 2010 at 8:57 AM, Gary Autiello
<gautiello at dominiondiagnostics.com> wrote:
>
> Hey Kaleb,
>
> I'm still having no luck with getting information from scponly jailed
environments logged via sftp-server. I have tried many suggestions
including creating a /dev/log within the chrooted user's environment as
well as making sure syslogd starts up with a
"-a /path/to/users/chroot/dev/log". In my sshd_conf file I have the
Subsystem setup to show:
>
> Subsystem sftp /usr/libexec/openssh/sftp-server -f LOCAL6 -l INFO
>
> I also have the two logging options setup in the sshd_conf file:
>
> # Logging
> # obsoletes QuietMode and FascistLogging
> SyslogFacility LOCAL6
> LogLevel INFO
>
> LOCAL6 is a listener for syslog that I setup to log all sftp info
to /var/log/sftp/sftp.log. All non jailed users get information logged
perfectly. The only information for jailed accounts that I see get logged
is:
>
> Nov 1 07:57:05 garytest139 sshd[13973]: Accepted password for garytest
from 192.168.1.43 port 57711 ssh2
> Nov 1 07:57:05 garytest139 sshd[13975]: subsystem request for sftp
>
> That is all that gets logged. Any ideas?
>
> Thanks!
>
> ______________________________________
> Gary Autiello, Network +, MCITP
> Network Administrator
> Dominion Diagnostics, LLC
> x886, 401-667-0886
>
>
>
> Kaleb Pederson ---10/29/2010 12:48:52 PM---On Friday, October 29, 2010
06:29:16 am Gary Autiello wrote: >
>
> From: Kaleb Pederson <kaleb.pederson at gmail.com>
> To: Gary Autiello <gautiello at dominiondiagnostics.com>
> Cc: scponly at lists.ccs.neu.edu, Joe Morin <jmorin at dominiondiagnostics.com>
> Date: 10/29/2010 12:48 PM
>
> Subject: Re: Troubles with scponly-4.8
>
> ________________________________
>
>
> 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
> >
>
>
> 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
>
> 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

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: 25162278.jpg
Type: image/jpeg
Size: 5238 bytes
Desc: not available
Url : http://lists.ccs.neu.edu/pipermail/scponly/attachments/20101101/ccbc7656/attachment-0001.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/20101101/ccbc7656/attachment-0001.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: strace_log.txt.22585
Type: application/octet-stream
Size: 47738 bytes
Desc: not available
Url : http://lists.ccs.neu.edu/pipermail/scponly/attachments/20101101/ccbc7656/attachment-0003.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: strace_log.txt.22586
Type: application/octet-stream
Size: 159538 bytes
Desc: not available
Url : http://lists.ccs.neu.edu/pipermail/scponly/attachments/20101101/ccbc7656/attachment-0004.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: strace_log.txt.22546
Type: application/octet-stream
Size: 3675 bytes
Desc: not available
Url : http://lists.ccs.neu.edu/pipermail/scponly/attachments/20101101/ccbc7656/attachment-0005.obj 