SSH revised

[Marcus Brinkmann]

Hi,

Niels: I hope you don't mind that I suck you in to a Hurd design
question, but it's ssh related and that makes you my perfect target :)

I am stretching my neck out there, because I am as much a non-expert
on SSH and internetting as there can be.  I am counting on you guys!

I was thinking about how SSH would be done in an operating system
where the system does not retain full access to the user's computing
environment.  In particular, the SSH protocol goes from host based
authentication to starting user commands without a blink, and that's a
couple of leaps over barriers that we have introduced which may
provide a stumbling block to implementing ssh.

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

I did not say where the user authentication happens.  We (Bas, Olaf
and I) have developed some ideas to do the authentication not in
system code, but in user code.  More on this another time (it's a
separate discussion).  But in the case of SSH, it doesn't really
matter.  Even if the authentication is done by the system, there is
still some part of the SSH protocol that the system can not do for the
user, for example executing a shell command.

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

3) There is a system ssh server, but it only implements the lower
   levels of the ssh protocol.  The higher levels are implemented by a
   corresponding program in the user's session.  When the ssh server
   accepts a connection, after (or even before) authenticating the
   user, the connection is passed as a logical terminal device to the
   user's session (compare with the physical terminal approach), and
   the user knows how to pick it up from there.

   Is this even implementable within the restrictions of the SSH
   protocol?  If yes, where are the sensible cutting points?  Before
   user auth?  After user auth?

4) ... ?

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.

Approach 3 seems to be a compromise.  It sounds tricky to get right,
but it provides a hint to a solution in the case where approach 1
would not work, for example because you need to do the host
authentication with the _host_, and not with the user account, or
where the operating system needs to provide some other capabilities
beyond the network connection.  It also fits "better" with the
traditional Unix model of internetworking.

Your ideas are appreciated,
Marcus