OpenBSD Journal

Ask undeadly: SSH client session multiplexing

Contributed by grey on from the taking advantage of newer features dept.

Michael Knudsen writes in with the following experiences and questions:

For about a month, the in-tree ssh client has supported session multiplexing, but I didn't get around to trying it until a few days ago. The result? Mind-bogglingly fast logons (since the connection is shared and already authenticated, _lots_ of things can be skipped). This makes remote CVS operations seem as fast as local ones.

Session multiplexing works a bit differently than I expected. I had expected ssh to fall back to TCP if the multiplexing socket didn't exist which it doesn't seem to do (I haven't found the way to do it yet), and this at first seemed to make it much less useful -- especially because you cannot start two clients trying to be ControlMaster (so putting `ControlMaster yes' in ~/.ssh/config doesn't work).

However, after playing around with it, I came across the idea of putting something like this in ~/.xsession:

   ssh -fMN host

The `host' entry in ~/.ssh/config was expanded with `ControlPath ~/.ssh/control.host'. I had preferred to put something like `ControlPath ~/.ssh/control.%H' in the `Host *' entry but this isn't possible in the current code and it would probably be annoying without fallback to TCP anyway.

Someone might argue that starting `ssh -fMN host' from ~/.xsession is a bad idea, securitywise. However, this is just about as insecure as using ssh-agent without specifying `-c' when ssh-add'ing keys, and one can always make a `host-control' entry in ~/.ssh/config which has `ControlMaster ask' instead (this uses $SSH_ASKPASS to get permission to allow the new session) and then leave out `-M' in the background ssh session.

This is my experience and setup. Now, my questions are:

   1) Are my security considerations correct?
   2) Has anyone found another (better?) setup?
   3) Has anyone found other uses than simply faster logons?

(Comments are closed)


Comments
  1. By djm@ (203.217.30.81) on

    I'm glad that this is getting some attention - it could use some real testing between now and the next release.

    As for your questions:

    1. With regards to security, the code enforces that only the user who initiated the connection or root can open a new multiplexed session over said connection. I'd recommend ControlMaster=ask for most uses though - OTOH the non-confirmed mode would be useful for things like distcc that need to open many little connections.

    2. My setup has a bunch of aliases in ~/.ssh/config. E.g.

    Host somehost-m    Hostname somehost    ControlMaster ask    ControlPath ~/.ssh/ctl-somehostHost somehost-s    ControlMaster no    ControlPath ~/.ssh/ctl-somehost

    I can then initiate one connection using "ssh somehost-m" and fire off multiplexed connections using "ssh somehost-s" at will.

    Perhaps we could implement fallback-to-new-connection and %h hostname expansion in ControlPath, but the priority right now ensuring that what we already have works right :)

    3. Other uses: what finally got me to write this was a request from a distcc developer who wanted a way to speed up multiple short requests. Anything that has a similar usage pattern could benefit from this. 3d render farms is an example that immediately comes to mind.

    Comments
    1. By djm@ (203.217.30.81) on

      This is what the example was supposed to look like (it looks like undeadly has a bug that corrupts <pre> tags on preview)

      Host somehost-m
          Hostname somehost
          ControlMaster ask
          ControlPath ~/.ssh/ctl-somehost
      Host somehost-s
          ControlMaster no
          ControlPath ~/.ssh/ctl-somehost
      

    2. By Michael Knudsen (82.150.71.100) e@mongers.org on

      The reason I'd like tcp-fallback or having ssh ignore existing ControlMaster sockets is so I don't need to worry about establishing the master session first. I'm lazy so I prefer things to work transparently. :)

      I've used the current implementation for nearly a week now, and I've encountered two issues:

         1) The escape key only works in the ControlMaster session (I'm not sure
         that this is a bug -- it might be a protocol design consequence)
         2) If somehow messing up the config file so you accidentally specify
         the wrong socket, you'll connect to the wrong host without any warning.
         This is a small issue and could probably be used for some things.
      

      I hadn't thought of using it with distcc but I can imagine that one will see quite a speedup here.

      One thing I think should be added is the possibility to cancel or shut down sessions from the ~C escape key menu. Something like `ssh> kill n' where n is the session number would be really nice -- especially since the escape key doesn't work in non-master sessions.

      Oh, another feature request: I'd like to have `configuration forwarding' (possibly including ~/.ssh/known_hosts) so I can do stuff such as `scp host1:file host2:' without having to define host2 in host1:.ssh/config but I'm not sure how easy this would be to implement.

  2. By Anthony (68.145.111.152) on

    I've got a bunch of scripts that use ssh with private-key authentication to get results from and to other computers on my LAN. This would speed that up a lot. Unless I'm very much mistaken, all you'd need to do is set up a backgrounded ssh connection at the beginning of the script, remember the PID, have really cheap connections for the duration of the script, then kill the PID at the end (and in any places where you exit with an error). Fantastic.

  3. By cyc (62.206.217.131) on

    This thing seems very intresting for mrtg jobs via ssh

  4. By Michael (163.252.218.56) on

    Hey everybody,

    In what kind of situation would this be used? I think I'm having trouble understanding exactly what is meant by 'multiplexing sessions'.

    Brief explanation, anyone?


    --Michael

    Comments
    1. By Anonymous Coward (64.91.149.209) on

      not to sound like a jerk or anything, but google "openssh session multiplexing"
      After a successful authentication over the SSH transport layer, multiple channels are opened by multiplexing[1] the single connection between the two systems. Each of these channels handles communication for a different terminal session, forwarded X11 information, or any other separate service seeking to use the SSH connection. 
      
      Both clients and servers can create a new channel, with each channel being assigned a different number at each end. When one side attempts to open a new channel, that side's number for the channel is sent along with the request. This information is stored by the other side and used to direct a particular type of service's communication to that channel. This is done so that different types of sessions will not affect one another and channels can be closed without disrupting the primary SSH connection between the two systems. 
      
      Channels also support flow-control, which allows them to send and receive data in an orderly fashion. In this way, data is not sent over the channel until the host receives a message that the channel is able to receive it. 
      
      Channels are particularly useful with X11 forwarding and TCP/IP port forwarding with SSH. Separate channels can be configured differently, perhaps to use a different maximum packet size or to transfer a particular type of data. This allows SSH to be flexible in handling different types of remote connections, such as dial-up over public networks or high speed LAN links, without having to change the basic infrastructure of the protocol. The client and server negotiate the configuration of each channel within the SSH connection for the user automatically.

      Comments
      1. By Anonymous Coward (66.93.216.162) on

        right but things like multiplexing for ssh or port forwarding have existed for quite some time and I've used them. What was added or am I missing something here?

        Comments
        1. By Anonymous Coward (209.162.235.146) on

          Is there any special reason you can't just read the post? Session multiplexing was just added about a month ago.

    2. By Anonymous Coward (64.91.149.209) on

      not to sound like a jerk or anything, but google "openssh session multiplexing"
      After a successful authentication over the SSH transport layer, multiple channels are opened by multiplexing[1] the single connection between the two systems. Each of these channels handles communication for a different terminal session, forwarded X11 information, or any other separate service seeking to use the SSH connection. 
      
      Both clients and servers can create a new channel, with each channel being assigned a different number at each end. When one side attempts to open a new channel, that side's number for the channel is sent along with the request. This information is stored by the other side and used to direct a particular type of service's communication to that channel. This is done so that different types of sessions will not affect one another and channels can be closed without disrupting the primary SSH connection between the two systems. 
      
      Channels also support flow-control, which allows them to send and receive data in an orderly fashion. In this way, data is not sent over the channel until the host receives a message that the channel is able to receive it. 
      
      Channels are particularly useful with X11 forwarding and TCP/IP port forwarding with SSH. Separate channels can be configured differently, perhaps to use a different maximum packet size or to transfer a particular type of data. This allows SSH to be flexible in handling different types of remote connections, such as dial-up over public networks or high speed LAN links, without having to change the basic infrastructure of the protocol. The client and server negotiate the configuration of each channel within the SSH connection for the user automatically.

    3. By Anonymous Coward (64.91.149.209) on

      not to sound like a jerk or anything, but google "openssh session multiplexing"
      After a successful authentication over the SSH transport layer, multiple channels are opened by multiplexing[1] the single connection between the two systems. Each of these channels handles communication for a different terminal session, forwarded X11 information, or any other separate service seeking to use the SSH connection. 
      
      Both clients and servers can create a new channel, with each channel being assigned a different number at each end. When one side attempts to open a new channel, that side's number for the channel is sent along with the request. This information is stored by the other side and used to direct a particular type of service's communication to that channel. This is done so that different types of sessions will not affect one another and channels can be closed without disrupting the primary SSH connection between the two systems. 
      
      Channels also support flow-control, which allows them to send and receive data in an orderly fashion. In this way, data is not sent over the channel until the host receives a message that the channel is able to receive it. 
      
      Channels are particularly useful with X11 forwarding and TCP/IP port forwarding with SSH. Separate channels can be configured differently, perhaps to use a different maximum packet size or to transfer a particular type of data. This allows SSH to be flexible in handling different types of remote connections, such as dial-up over public networks or high speed LAN links, without having to change the basic infrastructure of the protocol. The client and server negotiate the configuration of each channel within the SSH connection for the user automatically.

  5. By Ron Chen (171.71.139.102) rchen8868@yahoo.com on

    Is this feature available in OpenSSH? Thanks

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]