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 _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
