[scponly] Troubles with scponly-4.8

[Kaleb Pederson]

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