From owner-freebsd-security Mon Sep 14 09:02:57 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA24325 for freebsd-security-outgoing; Mon, 14 Sep 1998 09:02:57 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from roble.com (roble.com [207.5.40.50]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA24319 for ; Mon, 14 Sep 1998 09:02:51 -0700 (PDT) (envelope-from sendmail@roble.com) Received: from localhost (localhost [127.0.0.1]) by roble.com (Roble) with SMTP id JAA27503 for ; Mon, 14 Sep 1998 09:02:30 -0700 (PDT) Date: Mon, 14 Sep 1998 09:02:30 -0700 (PDT) From: Roger Marquis To: freebsd-security@FreeBSD.ORG Subject: Re: sshd In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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. > 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. Roger Marquis Roble Systems Consulting http://www.roble.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message