[1253] in Release_7.7_team

home help back first fref pref prev next nref lref last post

Re: ssh and access_on

daemon@ATHENA.MIT.EDU (Greg Hudson)
Wed Apr 15 10:42:39 1998

To: Dan Winship <danw@MIT.EDU>
Cc: Jonathon Weiss <jweiss@MIT.EDU>, release-team@MIT.EDU
In-Reply-To: Your message of "Wed, 15 Apr 1998 00:10:29 EDT."
             <199804150410.AAA21554@antharia.MIT.EDU> 
Date: Wed, 15 Apr 1998 10:42:10 EDT
From: Greg Hudson <ghudson@MIT.EDU>

I was actually thinking about this last night in the context of
Aaron's recent mail to suggest.  To do a sipb-style remote access
scheme "the right way", we need to come up with a piece of
configuration information which determines whether sshd is "switched"
(which will be edited by "mkserv remote") and then we need to convince
access_on and access_off to somehow enable and disable sshd if it is
switched.  Lots of puzzle pieces.

It simplifies things a little bit if we make the possible values of
SSHD be "false", "true", and "switched", I guess.  Then we could let
access_on/access_off take care of starting and stopping sshd in the
"switched" case, and start it from the athena script in the "true"
case.  "mkserv remote" only has to edit rc.conf, which it's already
used to doing.

> Hm... we should have reactivate do a "rm -f /etc/ssh_*" because
> otherwise people are going to generate keys so people can ssh in and
> then not delete them afterwards and people will end up using keys
> generated by other people which are therefore insecure.

I assume you mean the public workstation cleanup?

home help back first fref pref prev next nref lref last post