SSH Connection Sharing, C++ Visibility, Share Libraries, and GCC Attributes. OH MY!

Whew, what an evening. It started off simple enough. After dinner I just sat down and my good friend and co-worker Chris IMed me about something or another. We were making small talk until I remembered I wanted to share with him the new SSH Connection Sharing support introduced in OpenSSH 4.0. What is it?

From the ssh_config man page, the “ControlMaster” option “Enables the sharing of multiple sessions over a single network connection.” I configured it on my system simply enough. I added an entry to my ~/.ssh/config file for each host which I connect to often enough to warrant using this feature. In my case, that is only one host. I added this the aforementioned file:

ControlPath /tmp/ssh_little_jrwren

Now I can start a ControlMaster by invoking ssh -M. I can keep it around forever (or until killed) by invoking ssh -MNf. Now each time I ssh to, there is no delay. There is no TCP/IP session to open up, there is no key exchange, there is no SSH negotiation, all that is already done and waiting. I immediately get my remote bash prompt! Totally awesome feature.

Unfortunately this feature hasn’t been marketed very well. The number 1 google result for “controlmaster controlpath” (the two options for this feature) returns this GCCWiki page suggesting its use with source control systems. It occurs to me its use would be extremely benefitial with distcc when using ssh as the rsh for distcc. Anyway, I thought I’d check out the GCCWiki some, so from the Home Page, the first thing I decided to click was the Proper C++ visibility support link under the What is new in GCC 4.0 link. VERY awesome optimizations, but it isn’t what blew my mind.

This thing linked an excellent paper by Ulrich Drepper on good DSO design called How to Write Shared Libraries. This paper is great because it details just how programs use shared libraries and how the old a.out system works and ELF as well. It covers what various linker flags do, what some environment variables do to the dynamic linker, dlopen options, and probably everything (or in my case more than everything) one may wish to know. But this is still not what blew my mind.

My C skills aren’t that great. I can get by, but I’m no expert. My C++ is even worse, mostly because I haven’t used it since college and even then it was only 3 semesters, two of which were 10 years ago. I am however becoming an expert enough at C#. I like to think I have pretty good understanding of what is going on with C#, but one feature which I’ve definitely not mastered and never had need to utilize is that of Attributes. What blew my mind was that GCC has extentions for function attributes, very similar to C# attributes. OK OK C# attributes are WAY more extensible, but the concepts are similar.

One of the things I didn’t understand immediately when I started doing OOP using C++ ten years ago was the use of private members (variables or functions). I did understand what meant, what to expose, OK, I guess I understood it, but my general attibute was to just keep everything open (public). If someone wanted to use one of my members, let them. Give freedom and flexibility to someone using a class which I had written. Of course after some time I grew to appreciate following interfaces (base classes, this is c++ right? how about MIDL defined COM interfaces?) and not extending them unless necessary. I changed my tune slowly once I saw the value in it, but reading this DSO paper was extremely enlightening.(mind blowing?)

The function attributes page and the Shared Library Howto describe the visibility attribute. What I find interesting is that C++ private members should all be able to get visibility(“internal”) attributes. That is more interesting to me regarding shared library usage and C++ member protection levels. I’m sure it is nothing I will ever use, at least not in the near future, but it is definitely something new to me. I like new things. I like thinking about new things. I definitely like new light shed on old things, especially when they make me think about things which I wouldn’t otherwise.

Now it is late and I’m only 1/4 of the way through that Shared Library paper. I don’t think I can finish it, I’m too tired. That will probably be my epitaph “always too tired to finish things.”

9 thoughts on “SSH Connection Sharing, C++ Visibility, Share Libraries, and GCC Attributes. OH MY!”

  1. This is a really nifty feature!

    Following advice from the man page, I’m using “ControlPath ~/.ssh_control_%r@%h:%p”, since I log into the same host with different usernames. I’ve added this to the “Host *” section in my ~/.ssh/config, and for each host I want to use it on I add “ConnectionMaster auto” to the relevant host section, so it all Just Works.

  2. You can have ssh automatically set up a master socket for every connection, with the following in your ssh config file:

    host *
    ControlMaster auto
    ControlPath ~/.ssh/master-%r@%h:%p

    For extra security, change ‘auto’ to ‘autoask’ and you will be prompted to confirm when additional connections are accepted.

  3. On windows (using cygwin ssh) a ‘:’ is not legal in a path name. So using this might be better:
    ControlPath ~/.ssh/master-%r@%h-%p (e.g. replace the ‘:’ with a ‘-‘ or something. It probably doesn’t matter unless you are setting ports to something different than 22)

    But, BTW, I can’t seem to get this to work on cygwin with SSH 4_5 — it is failing with the master connection saying mm_receive_fd: no message header and closing. Nothing evident on debug — heading to forums now.

  4. I confirm the Cygwin problem. I’m seeing the same mm_receive_fd under Cygwin running OpenSSH 4.6p1 on the control master session.

    On the slave session, the ssh attempt instantly spits out:

    ssh_msg_recv: read: header
    control_client: msg_recv

    I see no resolutions for this on google pertaining to any of these messages or primary fragments.

  5. Spoke too soon. A bit more digging came up with a definitive “impossible to fix”.

    Damien Miller:

    OpenSSH can’t do anything to resolve this, it is a limitation of the
    Cygwin platform libraries. If Cygwin is able to make fd passing work on
    Windows, then OpenSSH will automatically work.

    I’ll close this bug, because there is nothing we can do here.

Comments are closed.