[scponly] Troubles with scponly-4.8
Gary Autiello
gautiello at dominiondiagnostics.com
Mon Nov 1 13:39:49 EDT 2010
Hi Kaleb,
Please see the following screen shots for each numbered item:
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
# Logging
# obsoletes QuietMode and FascistLogging
SyslogFacility LOCAL6
LogLevel INFO
Subsystem sftp /usr/libexec/openssh/sftp-server -f LOCAL6 -l INFO
4) This has been configured by doing echo 1 >
/usr/local/etc/scponly/debuglevel
5) I'm not sure what you mean by this or how to do this.
Here is a screen shot of the ls -l of the chroot:
Here is some output of the /var/log/secure file that shows the scponly
debug set to 1:
I've attached a strace file for your viewing. I basically connected from
another server, and did some basic SFTP commands like cd and ls. Thanks
again!
(See attached file: strace_log.txt.17204)(See attached file:
strace_log.txt.17276)(See attached file: strace_log.txt.17275)
______________________________________
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 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
Inactive hide details for Kaleb Pederson ---10/29/2010 12:48:52 PM---On
Friday, October 29, 2010 06:29:16 am Gary Autiello wrotKaleb 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
-------------- next part --------------
HTML attachment scrubbed and removed
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2E238857.gif
Type: image/gif
Size: 17037 bytes
Desc: not available
Url : http://lists.ccs.neu.edu/pipermail/scponly/attachments/20101101/690046d3/attachment-0005.gif
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2E599363.gif
Type: image/gif
Size: 10962 bytes
Desc: not available
Url : http://lists.ccs.neu.edu/pipermail/scponly/attachments/20101101/690046d3/attachment-0006.gif
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2E405633.gif
Type: image/gif
Size: 8520 bytes
Desc: not available
Url : http://lists.ccs.neu.edu/pipermail/scponly/attachments/20101101/690046d3/attachment-0007.gif
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2E263381.gif
Type: image/gif
Size: 29809 bytes
Desc: not available
Url : http://lists.ccs.neu.edu/pipermail/scponly/attachments/20101101/690046d3/attachment-0008.gif
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2E816288.jpg
Type: image/jpeg
Size: 5238 bytes
Desc: not available
Url : http://lists.ccs.neu.edu/pipermail/scponly/attachments/20101101/690046d3/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/690046d3/attachment-0009.gif
-------------- next part --------------
A non-text attachment was scrubbed...
Name: strace_log.txt.17204
Type: application/octet-stream
Size: 3773 bytes
Desc: not available
Url : http://lists.ccs.neu.edu/pipermail/scponly/attachments/20101101/690046d3/attachment-0003.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: strace_log.txt.17276
Type: application/octet-stream
Size: 126490 bytes
Desc: not available
Url : http://lists.ccs.neu.edu/pipermail/scponly/attachments/20101101/690046d3/attachment-0004.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: strace_log.txt.17275
Type: application/octet-stream
Size: 21639 bytes
Desc: not available
Url : http://lists.ccs.neu.edu/pipermail/scponly/attachments/20101101/690046d3/attachment-0005.obj
More information about the scponly
mailing list