Date: Sat, 12 Sep 1998 18:19:26 -0700 (PDT) From: Michael Sinatra <msinatra@uclink4.berkeley.edu> To: Roger Marquis <marquis@roble.com> Cc: freebsd-security@FreeBSD.ORG Subject: Re: sshd Message-ID: <Pine.ULT.4.02A.9809121806220.21822-100000@iridium.cchem.berkeley.edu> In-Reply-To: <Pine.SUN.3.96.980911195617.10501D-100000@roble.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 11 Sep 1998, Roger Marquis wrote:
> The 2.2.6 man pages incorrectly identify /etc as the location of
> hosts.{allow,deny}. FWIW, /etc is the default location on every
> *other* Unix operating system.
It goes without saying that the type of Unix system has nothing to do with
it--you can change the default location when you compile tcpd by changing
HOSTS_ALLOW and HOSTS_DENY.
When I first ran into this bug (back
> around 1.0.5) we had to `strings tcpd` to find where the access files
> were expected to be. This is one of the many FreeBSD ports that (IMHO)
> offer no advantages over the original package.
Is it supposed to offer any advantages other than being able to cd into
the ports directory and simply type 'make' and have the system fetch the
distribution and do everything for you, *and* be reasonably well-assured
that the beast is going to compile? That is a pretty huge advantage for
an overworked sysadmin like myself.
<SIDETRACK>
I gave a talk a few weeks ago to UCB sysadmins on all of the
different unixish options on intel hardware, and I demonstrated how
/usr/ports works in FreeBSD. Everyone thought it was really cool, and
needless to say, the freebie 2.2.6 cds that I had went like hotcakes.
</SIDETRACK>
> The recommended sshd startup method used to be /etc/rc*(/*), probably
> for historical reasons. It may still be a good idea on slow CPUs,
> where it can take a while to generate a session key, or where
> inetd.conf isn't running, however, in my experience, sshd is much more
> reliably run from inetd.
Hmmm. I have never had any problems running it standalone. I have
noticed that the connections are slow to make during key regeneration on
slow machines, but no "unreliability."
Michael Sinatra
Unix Guy
College of Chemistry
UC Berkeley
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.ULT.4.02A.9809121806220.21822-100000>