Re: SSH revised

[Niels Möller]

Marcus Brinkmann <address@hidden> writes:

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

No problem.

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

Let me start with this question, since I'm trying to do that with a
future version of lshd. The SSH server can be cut up into three parts,
along protocol boundaries. I'll restrict this discussion to the server
side.

1. SSH transport layer. Responsible for key exchange, encryption and
   host authentication. Needed privileges: Right to listen on the ssh
   port (22). Access to server's private host key. In lshd-ng, it runs
   at root.

2. SSH user authentication. Responsible for user authentication,
   obviously. Needed privileges: Access to everything user-database
   related (/etc/shadow, $HOME/.ssh/authorized-keys, etc), depending
   on which user autentication methods are used, and the ability to
   change uid to the right user after successful authentication. In
   lshg-ng, it runs at root, and calls setuid and exec on success. It
   sets up environment variables and changes cwd to the user's home
   directory, but it does *not* create any "session" or terminal.

   The protocol allows a client to try to authenticate as "nisse", and
   on failure, try again this time using the name "marcus". IIRC,
   servers aren't strictly required to allow this, but I think it
   still makes it undesirable to run the user authentication process
   as an ordinary user process (unless it's a personal ssh server with
   only a single valid user name).

3. SSH connection protocol. Handles multiplexing of multiple ssh
   channels (session channels, various forwarded channels, etc), and
   session creation. Needed privileges: Right to bind sockets (if
   tcp-forwarding is enabled), and all rights needed to create a
   session (related ssh protocol messages: CHANNEL_OPEN "session",
   CHANNEL_REQUEST "pty", CHANNEL_REQUEST "shell", ...).

   In lshd-ng, it runs with privileges of the authenticated user.
   Which creates some difficulties with things like utmp (ordinary
   users have no write access), and with pty creation (if one has old
   fashioned pty:s and no /dev/ptmx, one needs root privileges to
   change the ownership of the slave pty). But I think this is the
   right thing to organize the ssh-server, so I use a separate helper
   process (running as root, spawned by the user authentication
   program) to get around these problems.

The privilege separation in openssh works quite differently, but I'm
not familiar with it, so you might want to look at that too.

It's important to keep in mind that one ssh connection after user
authentication can correspond to an *arbitrary* number of sessions.
And not all sessions will have a pty attached; those that lack a pty
can't be "sessions" in the traditional posix way, but they can be
compared to a user "logged in" at an ftp server.

> I think that approach 1 may actually be the right one---it easily
> generalizes to all sort of internet services.

Interesting idea. One counter example might be an IMAP server that
provides not only a personal mailbox and folders but also some shared
folders. And incoming smtp, with some mail aliases that goes to
multiple users.

> Approach 3 seems to be a compromise.  It sounds tricky to get right,

Right, if you start with a "monolithic" ssh-server, it's a non-trivial
piece of work to cut it up in the appropriate pieces.

> It also fits "better" with the traditional Unix model of
> internetworking.

That's why I'm trying to do that. And to cut down the amount of code
that runs with root privileges.

Regards,
/Niels