Re: SSH revised

[Marcus Brinkmann]

At Thu, 23 Mar 2006 21:43:34 +0000,
Sam Mason <address@hidden> wrote:
> 
> On Mon, Mar 20, 2006 at 11:16:49PM +0100, Marcus Brinkmann wrote:
> > Let me give you my abstract models for terminals to have a solid
> > comparison: A terminal is a set of physical and logical devices.  At
> > log in, a capability to a directory (containing capabilities to these
> > devices and some extra info) is provided to the user's account, where
> > it will be attached to a session.  At log out, the terminal capability
> > is revoked by the system, the hardware is reset, and the next user can
> > log in (I left out a couple of details that are easy to work out).
> 
> This seem's like a general problem.  Somehow we need to allow something
> from outside the system (the network in this case) to contact some central
> service (the SSH server) and expect to come back with information from
> a specific user.
> 
> Because you haven't gone into specifics, this is sort of how I imagine
> the login process working:
> 
>   1. the system (or maybe some user code) recieves a request to login
>   to the system.  Some credentials (username/password) are supplied that
>   identify a particular account as being the one to login to.
> 
>   2. this authentication code would then create a directory containing
>   information about the login, including capabilities to the terminal
>   (or GUI, or what ever the user is using) that the user logged-in from.
> 
>   3. this directory would be passed to some agent that the user had
>   previously registered with the system to allow login's to occur
> 
>   4. the user's agent would then be able to construct an appropiate
>   environment and execute an appropiate shell

This is pretty accurate.  However, we also consider a variation.  In
the variation, in step 1 _only_ the username is supplied to the
system.  The system does not do authentication.  Then step 2 and 3
happen.  Before step 4, the user code would do the authentication
itself.

> This relies on each user registering some login agent with each
> authentication process in the system (i.e. local terminal login, SSH
> login, etc.) before logins to the user's account can happen.

Not really.  First, we do not need to send the capability to the user,
the user can ask for it with a blocking fetch operation.  This means
that we do not need to register user capabilities, but that we can
advocate system capabilities to the user.  Also, there only needs to
be one such capability.  There needs to be something that multiplexes
the terminals to the users, of course.  I thought about this and came
to the conclusion that a system log mechanism could be used for this,
if we add capability support to the logger.  Ie, you don't log
strings, but you log "capabilities".  Terminal log-ons would be logged
in their own category, and be addressed to the user as the recipient.
The capability that the system logs is the directory created in your
step 2.  The same mechanism can be used for other events that are
generated by the system and reported to the user (software updates,
hotplug events on a terminal the user is currently using etc).

The user will run a syslog daemon that retrieves system log messages,
and dispatches them to the appropriate handlers based on the category.
A terminal log on event would be forwarded to the user's session
manager (which would invoke the help of an authentication daemon etc).
The user's session manager would be responsible for attaching the
terminal to an existing session or to create a new one.

> This raises
> the question of what to do with an account that severs all ties with
> the outside world -- which could very well be a very useful thing to do!

You can't log on to that account using the terminals, then, of course.

You could still communicate to that account via other capabilities, if
they exist.

> Back to the main question.  If I've got the process above correct, why
> can't the SSH server just construct a similar object to the one created by
> a normal terminal login and give it to the user's login agent?  assuming
> the user has registered its login agent with the SSH server of course.

The basic mechanism must be the same, as there should only be one
mechanism for this.  So, in the end, it will boil down to "one
capability" that is provided by the system to the user.  However, I
think for SSH this capability will not represent a transparent pseudo
terminal, but something more complex.  The reason is that the SSH
protocol is not just for PTY creation.  So, in order to support other
functions of SSH, you need to separate the protocol handling into a
system layer and a user layer.  The interface between the system and
the user needs to reflec this.  Ie, the system needs to pass off the
SSH connection, with some of its state, to the user.  It was not clear
to me that this is possible, although Niels mail told us that it is.
In particular, if we want to do the variation above, the username
needs to be received by the system code, but the credential
verification needs to be done by the user.  So, the split may happen
at an inconvenient place, and certainly long before the pty creation
step.

In other words: Terminals consist of physical or logical devices that
the user needs to know how to use.  For SSH, there will be some funny
logical device, that is not a PTY, but represents an existing SSH
connection, with channels and what not.

> > I think that approach 1 may actually be the right one---it easily
> > generalizes to all sort of internet services.  For example, personal
> > web pages could be available under username.hostname.org and not under
> > hostname.org/~username/.  Of course, uhm, the lack of IP addresses in
> > IPv4 is a bit of an obstacle, to say the least.
> 
> I think you may get a lot of friction with existing users who say you
> should be able to do what's always been done.  I'm happy to be wrong
> about this though.

"You have to break eggs to make an omelett."  But well, we can't
change the internet, of course, so we have to build on the basis of
what is there with regards to IP service addressing.
 
Thanks,
Marcus