From owner-freebsd-security Mon Sep 14 10:32:48 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA09164 for freebsd-security-outgoing; Mon, 14 Sep 1998 10:32:48 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from dworkin.amber.org (dworkin.amber.org [209.31.146.74]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA09144 for ; Mon, 14 Sep 1998 10:32:38 -0700 (PDT) (envelope-from petrilli@dworkin.amber.org) Received: (from petrilli@localhost) by dworkin.amber.org (8.9.0/8.9.0) id NAA08920; Mon, 14 Sep 1998 13:32:21 -0400 (EDT) Message-ID: <19980914133221.57736@amber.org> Date: Mon, 14 Sep 1998 13:32:21 -0400 From: "Christopher G. Petrilli" To: freebsd-security@FreeBSD.ORG Subject: Re: sshd Mail-Followup-To: freebsd-security@FreeBSD.ORG References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: ; from Roger Marquis on Mon, Sep 14, 1998 at 09:02:30AM -0700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Sep 14, 1998 at 09:02:30AM -0700, Roger Marquis wrote: > On Mon, 14 Sep 1998, spork wrote: > > Number of times sshd died: 0 > > A common data point but there's also the shell that is spawned by sshd and > applications spawned by the shell. Any of those can hang a session > too. The most common problem I've seen is corrupt terminal definitions > that no combination of setenv, tset and reset will fix. Just a small data point as well, I've had sshd running on 4 different machines I own as the ONLY way to get into them (no inetd running on any of them), and guess what? I've never had a problem, ever in a sum-total of 3 1/2 machine years. Reliability is obviously not the reason to do this. > > > If you really need a backup access method, get a console server :) > > Have that too but there are many situations where it's not feasible. > > The real issue, it seems to me, is consistency. If ftp, telnet, rsh, > rlogin, etc. run from inetd then sshd should also. The original reason it > wasn't is the key generation delay, which isn't an issue on anything > faster than a 486/25. Then we should run xntpd out of inetd, do you run httpd out of inetd? :-) really, this is just silly... if at all possible ,get rid of inetd, it's a huge problem as it is, and it will just wholesale eliminate all the problems ;-) well, not all of themn, but a large chunk. Chris -- | Christopher Petrilli | petrilli@amber.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message