Re: SSH revised

[Sam Mason]

On Thu, Mar 23, 2006 at 11:39:01PM +0100, Marcus Brinkmann wrote:
> 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.

I'd be slightly worried about this; if I misspelled my username,
wouldn't my password be sent to some random users password logger?

I'm aware that it also places limits on authentication mechanisms, but
I'm having trouble reconciling these arguments.

> > 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.

OK, the mechanics don't bother me much at the moment.  But some user's
process would have to contact some central process for any login to occur.

> 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.

neat

> 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.

That's overloading the "logger" term for me a bit, but it's an
interesting idea.

> > 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.

I was more interested in determining when a process had lost all
communication with the outside world and should be killed off.  I guess
this should be the admin's job though.

> > 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.

Not sure how I forgot about that as I use port forwarding and scp and
suchlike all the time.  Yes, it is quite a bit more complicated isn't
it.  The login part is looking easier and easier in comparison to the
rest.

> 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.

Strange, I don't think I got Niels email.  

> 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.

Baring my concerns above, I agree.

> 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.

are you suggesting that this "logical device" is only to be used in the
context of SSH connections? or would it make sense to try and generalise
this a bit?  i.e. the other end of the connection wants to set up a new
PTY, a new incoming/outgoing port, wants access to your file system!

That's all starting to sound a bit frightening and I guess we just want
a way of passing the unencrypted packets to user space and back. . .
Humm, I think the SSH server has just become fully trusted!  or can you
use the containment bits of coyotos to verify that it is only going to
be sending your data encrypted to the correct socket?

> "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.

It's going to be a fun one to work out!


  Sam