There may already be a better solution for this. I'd like to know. Consider this wish a topic for discussion.
Bzr 2.2 and earlier appear to open a separate connection for every ssh operation on a remote branch. These connections become particularly noticeable when a GUI client like Bazaar Explorer is used, because most people can click icons faster than they can type full commands. For example, just "opening" the working tree of an existing checkout invokes four short-lived ssh sessions. Now get a 'log' and do 'annotate' a few times. You get the idea. Lots of ssh connections hitting the same credentials.
Here's why it matters. IP-specific tools like fail2ban may not be much use against DDoS. So some professional paranoids (like my IT department) also throttle ssh connection requests, regardless of whether they succeed or fail. I just found out that if my department firewall sees more than 20 *total* inbound ssh connection requests in a minute, our firewall locks out *all* ssh connections for ten minutes. What a pain! But I don't control security, and those guys have a job to do which is just as important as mine. I tried to explain to them that this is a *guaranteed* DoS, because all someone has to do to shut down *all* of our ssh traffic is hit us with 20 ssh requests every ten minutes. They gave me a dirty look and I left. :)
This is not theoretical. It saw it happen today on a test box while I was using bzr explorer. I'm going to have to be careful not to annoy those IT guys. It probably could be avoided if every command which can accept a location could also accept an option to use an existing connection if it exists and leave the connection open if it has to open one. Of course, there should be a way to drop all open connections. And the connection should be set on a per-location or per-branch basis, since multiple locations might be in use at once.
Some people might object to the idea of leaving a connection open. But it's no more rude than leaving a ssh login terminal open for hours. And the IT guys would rather kill a few stale connections than figure out how to deal with a flood of short-lived ones which look like something they want to stop. My problem might go away, now that I've pointed out that the ssh throttle is more likely to hurt them than help them. But until they do something smarter, I will be thinking more before clicking.
openssh supports persistent 'master' connections; you could use that
(define a control channel, start the master by hand). I'm not sure how
we'd glue management of such a thing into bzr, which has a short-lived
process model.