Guys, This is simply to request that you add an option to the server configuration to block the ControlMaster multiplexing. If there is a way to do that already, I can't find it, so please let me know and accept my apologies. Here's why: We just had a serious many-machine compromise which began with a single weak password on an unprivileged account on a machine I don't control, and spread in 24 hours to many machines which are my responsibility, courtesy of this "feature". Here's how it works: Blackhat cracks user tim's password on box 1 by brute force or propagation. Blackhat logs in as tim on box 1 and adds the controlmaster in tim's .ssh/config file. Tim logs on to box 2. Blackhat gets a free ride to box 2, without any need to break any security measure on box 2. We, like most educational institutions, can't afford to upgrade all the hardware we have to a level where all root kit vulnerabilities are patched, so our weaker machines lost root integrity, and with it the shadow file. This happened very quickly - in large part because of a very convenient unstoppable vector provided by openssh. Please note that there is currently no way for an admin on box 2 to actively prevent this compromise. We can only depend on the vigilance of users - which is to say we're wide open. I can probably figure out how to do a nasty band-aid solution in the source code, but if this is happening to us, it's happening everywhere. PLEASE HELP.
Disabling controlmaster won't help as much as you think; there are dozens of ways an attacker with a local account compromise can achieve the same result (search for "ptrace ssh command injection" for some interesting ones). You can globally disable session multiplexing from the client side by adding "ControlPath none" to /etc/ssh/ssh_config. This obviously won't help if your users (or an attacker) uploads their own binaries hacked to ignore it, and won't defeat command injections, key theft, etc.
Damien, Your argument seems to be "there are lots of tricky exploits out there, so there's no need to fix the even easier one we built in to ssh" The search you suggest will also bring many thousands of examples of people diligently patching command injection vulnerabilities. Even if both keys in a pair are stolen you can't use them without the passphrase - and cracking even weak passwords from a 2048 bit rsa key takes 100 times longer per attempt than a regular MD5 shadow password - that is if you just stole the keys from someone who's password you don't already know. You might want to check out the blackhat sites. This ssh exploit has become very popular because it's as easy as typing 2 lines and waiting. You can be sure that this problem will rapidly become worse. There is also a basic good coding paradigm that has been broken: Don't add a feature that you can't turn off - or it's no longer a feature, it's a property. Turning it off globally on the client is useless - no admin controls all the clients which he must grant access to. Guys, confidence in the openssh code is at stake here. Our campus has already been stung badly enough that it is researching other alternatives. You probably want to fix this before CERT puts it out in a bulletin and you're stuck pulling an all-nighter.
Have discovered that setting MAX_SESSIONS to 1 in session.c has the desired effect, so now I'm not quite so paranoid. I see that some other people have asked to have that number moved to the sshd_config, so I would also ask to have that done. Maybe a more elegant solution would be a good idea as well? Also, is there any other functionality that I lose by doing this? Agents, x-forwarding and all that good stuff seems to be fine. JP
OpenSSH 5.1 will have a MaxSessions control in sshd_config, so you can control this at runtime.
Mass update RESOLVED->CLOSED after release of openssh-5.1