RE: [saag] draft-kwatsen-reverse-ssh-01 submission for review

[Jeffrey Hutzelman <jhutz%cmu.edu@localhost>]

On Tue, 2011-07-05 at 15:32 -0700, Kent Watsen wrote:
> Allowing the SSH server open channels on the client has a lot of merit.
> 
> In trying to extend the generic SSH server (listening to port 22),
>  would the client start an application-specific subsystem having the
>  business logic knowing, for instance, how many channels to open, etc? 

Either the client would have to do something explicit, like starting a
shell or a subsystem, or the server would have to recognize that client
(say, based on the username it sent or how it authenticated or both) and
do something appropriate.



>  This solution would likely require a PAM module auth the client (i.e.
>  the device) in the app's database, since its surely not a system-level
>  user.  This solution would use more system resources (processes,
>  domain sockets, etc.) than our current implementation.

Now you're talking about implementation details.  The SSH protocol
doesn't know anything about PAM or "system users" or such things.




> A less resource intensive option would be for the "server" to be the
>  application itself, linked to a SSH server library.   Of course, this
>  server wouldn't be able to listen on port 22, since it wouldn't be
>  generic.

You could do that, too.


> Would not being generic defeat the purpose of trying to do
>  this inside the SSH protocol?

You mean, as opposed to trying to make the SSH protocol turn around and
operate in reverse halfway through, wedge authentication mechanisms into
the wrong role, etc?  No, I don't think so.  Even if you run the
application on its own port, you still have a much cleaner protocol this
way.





> In both cases, the solution would rely on the developers of the various
>  SSH apps and libraries to support this ability.  This might be
>  difficult sell given the use-case is somewhat limited to network
>  management; not that it couldn't be used for other purposes,

Frankly, you will probably have a hard time getting upstream OpenSSH to
accept patches to implement this or any other approach.  They're _very_
conservative about changes.  On the other hand, I would expect an SSH
server library already to provide most of what you need.  Servers
already have to be able to open channels for things like TCP port
forwarding.


Incidentally, if you're a little bit less picky about how much
flexibility you allow, there may be approaches you can implement today
without any changes to client or server software.  For example:

1) The client (device) connects to the SSH server in the usual fashion.
   It then starts a subsystem which is your field setup application.
   On the client side, the subsystem's channel is connected to a shell:

   ssh -s <server> fieldsvc | sh

   ... except that you need to connect both the shell's stdin and stdout

2) On the client, start something that listens on some local port (
   loopback interface only) and connects each new client to a shell.
   Start an SSH connection with port forwarding back to that port,
   and run the provisioning app on the server as a command or subsystem:

   ssh -R 0:127.0.0.1:rawshell -s <server> fieldsvc

   again, it's a little more complicated, because you need to collect
   the port number allocated by the server and somehow feed it to the
   fieldsvc subsystem (perhaps on stdin?)
  

>  I just
>  can think of any other.  Assuming we're able to update the SSH
>  implementations, we'd then have to convince all the devices to use
>  this new version of the SSH client - the role-out could take awhile...

Well, obviously if you have things in the field already using the
"reverse SSH" approach, you'll have to support them for a while.  That's
going to be true no matter how this ends up, and is simply part of the
cost of shipping something before relevant standards work is finished.

-- Jeff