[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SSH revised

From: Marcus Brinkmann
Subject: Re: SSH revised
Date: Mon, 27 Mar 2006 21:45:45 +0200
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (Sanjō) APEL/10.6 Emacs/21.4 (i486-pc-linux-gnu) MULE/5.0 (SAKAKI)

At Thu, 23 Mar 2006 16:29:09 +0100,
Christian Helmuth <address@hidden> wrote:
> On Mon, Mar 20, 2006 at 11:16:49PM +0100, Marcus Brinkmann wrote:
> > Hi,
> [...]
> > The shell command requires capabilities (file system, etc) that are
> > not available to the ssh server, and should not be.  This raises the
> > issue if the ssh server should be split up into two parts, a system
> > part and a user part, or if there should be a system ssh server at
> > all.  There are a couple of potential models:
> > 
> > 1) Every user gets their own (virtual) domain and runs their own ssh
> >    server.  IPv6 is right around the corner, isn't it? :)
> >    Then you just use "ssh username.hostname.org" and that's it.
> > 
> > 2) Every user runs their own ssh server, but on a different port (ouch!).
> I think these do not match with MAC-alike system policies. If an
> administrator/owner wants to restrict the options a specific user has to
> enter the system via SSH, there must remain a small "system" ssh server
> part. An example could be the limitiaton to SSH2.

There are two responses to that.  The first is: Why would an
administrator want to do that?  And the second is: Given the answer to
the first question, is this something that we want to support?

There are three possible outcomes to this: (1) there is no consistent
argument why the admin would want to do that, or (2) there is a
consistent argument, but it is in conflict with ideological
assumptions we make, or (3) there is a consistent answer, and it does
not conflict with our ideological assumptions.

Only if the result is (3) it is worth considering to support this.
And even then it may be rejected because of cost-benefit analysis or
other factors.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]