Re: address@hidden: Re: SSH revised]

[Marcus Brinkmann]

At Fri, 24 Mar 2006 13:24:56 +0100,
Lluis <address@hidden> wrote:
> so you propose the logger being like a capability board?

More like a queue.

> sorry if I don't 
> get the idea, but with this method, everyone looking at the board can see 
> its contents.

Of course not.  Some events are "global", and are received by
everybody.  Others are directed to a specific recipient.

> Of course, you can restrict "reads" to the board/stack/list 
> by only matching the recipient with the user identity (being able to use 
> the group identities for "multi-handlers").

Exactly.

> Once your user-side ssh server 
> gets to read a log-in message, it can fabricate a new container for the 
> capabilities you are configured to recieve as you previously configured.
> 
> This works, but, first, each user *must* (al long as I understand) have a 
> server running,

Yes, if they want to allow log-ins.  It won't be the only server that
users run ;)

> and, second, this logger board thingie is just a server 
> that handles a capability for a network connection (the socket recieveing 
> the connection, in fact handled by the system ssh server, posting it to the 
> logger).

The syslog server would be a generic mechanism to post system
capabilities to users.

> This logger is a capability croupier, making 1 to N connections, I mean, 
> sending the same message to the possible N listeners for that kind of event 
> and for that concrete recipient

The syslog server would be a server, implementing operations like
"post event" and "receive event".  There would be one capability type
to post events, which would be restricted to certain recipients (so
that users can communicate in a controlled fashion by sending a
limited number of events to each other, while the system can post an
arbitrary number of events to everybody) and one capability type to
receive messages (one for each possible recipient).

> ok, so:
> 
> - an ssh server S listens on socket T
> - S recieves a petition to login into Anna's account
> - S looks up Anna's associated identificator, A

Yeah.  I am not sure if A should be a globally unique ID or a
capability itself.

> - S posts (A,E,{T}) to the logger (being E an identificator of the event 
>   type)

Yes.

> - the logger sends a message to the registered clients on events for A

As a reply message to a "Get next event" operation initiated by A.

> - the user logger routes the event to clients registered for type E

> - the user side ssh server S' recieves T and starts any sort of 
>   authentication mechanism that it is able to handle
> - if the remote client successfully authenticates, S' creates a suitable 
>   environment for the remote client

Yes.
 
> and the "login" process for the client to the global logger can be a 
> registration of "classes", each class of event associated with an user 
> identification (to make all this process administrable through the 
> classical ways of user add and remove from groups)

I don't understand this.  What do you want to administrate?
 
> what I don't have clear is if that client-side handlers should be run 
> on-demand or started in a udev-like manner (I was thinking of those "funny" 
> things like persistence...mmm)

Implementation detail.  The system doesn't need to care.
 
> [...]
> > 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 
> 
> a local login could be handled by another client logger handler, giving a a 
> "full powered" environment (if you want it to give it to you)
> 
> what I don't like is differentiating on this level between local terminal 
> logins and remote ssh logins... both should be just an EV_LOGIN, with some 
> properties which differentiate their idiosyncrasies

The same logion event type can be used.  The difference is in the
content of the "directory" that contains the information about the
terminal, ie the terminal type (set of logical and physical devices).
The user will need drivers for any interesting combination (the system
can provide default drivers).
 
> > 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 
> 
> well, if the client logger is able to spawn a handler that spawns a new 
> environment/shell, then the system has to do nothing but the username 
> handling and routing

Well, and host authentication and transport layer management.

> > 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.
> 
> the problem I see in here, is, what happens when an invalid username is 
> given? is there a dummy ssh handler to avoid leaking information?

The list of user names is not secret.  If you really want, you could
make a dummy user that rejects all authentication attempts.
 
> > 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 don't completely understand what you try to say here, many things get 
> away from me :)

A terminal is a directory which contains capabilities to physical and
logical devices, and information about these devices.  The SSH
terminal would ocntain different devices than a physical terminal with
a video card and keyboard etc.
 
Thanks,
Marcus