| View previous topic :: View next topic |
| Author |
Message |
nihilo
Apprentice
Joined: 05 Nov 2002
Posts: 168
Location: berkeley, ca, usa
|
 Posted: Fri Apr 18, 2008 11:51 pm Post subject: HOWTO: improve SSH connection time by reusing connections |
 |
|
I didn't see anything in the forums about SSH connection sharing, which I find to be incredibly useful for anything that makes lots of SSH connections to the same host, so I wrote up a quick howto.
For more details, see the expanded version on my website: Improving SSH (OpenSSH) connection speed with shared connections
Improving SSH (OpenSSH) connection speed with shared connections
Version 4 of OpenSSH introduced a great but little-known feature that enables you to share connections to a remote host, so that if you open multiple connections to that host, all connections after the first connecton reuse the first connection. Why would you want to do that? Because subsequent connections will connect much faster.
For example, connecting to a server of mine across the country takes 0.9 seconds or so the first time (and every time without connection sharing); connecting to that same host reusing a connection takes about .13 seconds — that‘s about 7 times faster! If you are using some tool that makes lots of connections to the same host one after the other, the time savings can be drastic.
Configuration
Add the following to your ~/.ssh/config file, creating it if it doesn’t exist:
| Code: | Host *
ControlPath ~/.ssh/master-%r@%h:%p
ControlMaster auto |
This configures OpenSSH for opportunistic sharing: it will reuse existing connections when possible, and create a new master connection when necessary.
Verify that it’s working by connecting to some host, and verifying that the socket file is created. If you want to compare times, you might try something like time ssh example.com exit with and without a master connection already open. You should see a big difference.
Using different configuration options for different connections
Since all connections to the given host share the same TCP connection, they all reuse whatever SSH options the first connection used. This means that if you try to connect to a remote host using different options that you used initially, OpenSSH will quitely ignore the options you specify in subsequent connections. If you initially connect without enabling X11 forwarding (i.e., without using the -X flag) and want to later open a connection to that host with X11-forwarding enabled, doing ssh -X example.com will not work; it will quitely reuse the existing connection and won’t even warn you that X11 forwarding is not enabled. The same is true for the display setting and probably other options as well.
In order to use different configuration options for the connection, you must open a new connection and not reuse the existing master connection. This is accomplished by making a connection with ControlPath set to none. The -S flag is a convenience for setting the ControlPath on a per-process basis, so including -S none in your command results in a new connection being opened. In order to make a new connection with X11 forwarding enabled, for example, you would use:
| Code: | | ssh -S none -X example.com |
If you do this sort of thing frequently, you might want to something like alias sshnew="ssh -S none" to your ~/.bashrc file, and then you can just do
| Code: | | sshnew -X example.com |
Stale socket files
When the master connection successfully exits — i.e., when you logout from the master connection — OpenSSH will delete the appropriate socket file. However, if the process gets killed without having a chance to properly shut down, it won’t remove the socket file. The next time you try to connect to that host, you won’t be able to, and you’ll see an error message like:
| Code: | Control socket connect(/home/calvin/.ssh/master-calvin@example.net:1234): Connection refused
ControlSocket /home/calvin/.ssh/master-calvin@example.net:1234 already exists |
You’ll have to manually delete the socket file that it is complaining about, and then you’ll be able to connect again, and it will establish a new one if it’s a master connection.
Exiting master connection hangs if there are still slaves
If you mistakenly exit from the master connection you’ve opened while you still have slave connections open, the master process will just hang there until all the slave connections exit.
A simple workaround is to create the master connection somewhere it won’t be used, using screen or a virtual terminal or terminals in a workspace you don’t use.
EDIT 2008-04-23
Doublecheck that your ~/.ssh directory has the correct permissions, and make sure you use a directory like ~/.ssh that only you have access to. ~/.ssh should have the following permissions:
| Code: | calvin@turing ~ $ ls -ld ~/.ssh
drwx------ 2 calvin calvin 4096 2008-04-23 01:30 /home/calvin/.ssh/ |
If it doesn't, make it so:
For some discussion of security considerations, see my post further down this page.
Last edited by nihilo on Wed Apr 23, 2008 11:10 pm; edited 2 times in total |
|
| Back to top |
|
 |
luispa
Guru
Joined: 17 Mar 2006
Posts: 359
Location: España
|
| Posted: Wed Apr 23, 2008 6:15 pm Post subject: |
|
|
Thanks nihilo, very interesting.
Have you analised the security implications and how to solve them? (maybe they are already solved). I mean, imaging a different userB trying to use the socket file of userA.
Thx
Luis |
|
| Back to top |
|
|
nihilo
Apprentice
Joined: 05 Nov 2002
Posts: 168
Location: berkeley, ca, usa
|
| Posted: Wed Apr 23, 2008 7:23 pm Post subject: |
|
|
| luispa wrote: | | Have you analised the security implications and how to solve them? (maybe they are already solved). I mean, imaging a different userB trying to use the socket file of userA. |
Thanks for the comment. IANASE (I am not a security expert), but it seems safe. I just ran a few experiments to doublecheck what would happen if you didn't save it in ~/.ssh as suggested (which should always have 700 permissions and thus not be readable by anybody else). If you save the socket file in /tmp, for example, and another user tries to connect using that socket, OpenSSH fails with a "permission denied" error. It seems to check if the user is the same and fail if not, with one exception.
The exception is that root can make a connection using the socket file, regardless of where it is or what permissions it has (i.e., even if it's in ~/.ssh). This isn't really important though, because root can do absolutely anything anyway. Even if she couldn't reuse the socket file, she could install a keylogger or a corrupted ssh binary or anything else. There is no protection from root, so this doesn't make it less secure.
One problem with saving it to /tmp or another world-readable location though is related to the stale socket problem. If your ControlPath were set to save the socket in /tmp, and some other malicious user had touched a file at that location, you would get the error you get when there's a stale socket file, so you wouldn't be able to connect. However, you could still connect by doing something like ssh -o "ControlMaster auto" -o "ControlPath /tmp/different-socket-location_master-username@example.com:22" username@example.com. So this is a minor hassle.
To summarize, I don't see a problem as long as you save the socket file in a directory that only the user has access to. While I'm not aware of any problems when saving to somewhere like /tmp (apart from the inconvenience of someone saving a file there and forcing you to change the ControlPath), you should still definitely save it to a 700 directory, like .ssh. The security problems to worry about are the ones that haven't been discovered yet, and there are far fewer of those for a 700 directory than a 777 directory.
Perhaps some other people with a security background could chime in. I'm sure the OpenSSH the OpenSSH guys have thought about it a lot, but a quick google search didn't turn up anything.
I will edit above though to emphasize that the file should go in ~/.ssh and that it should have the standard 700 permissions.
thanks ... |
|
| Back to top |
|
|
luispa
Guru
Joined: 17 Mar 2006
Posts: 359
Location: España
|
| Posted: Thu Apr 24, 2008 6:20 am Post subject: |
|
|
nihilo,
Thanks a lot for the research and now with the Security addon it's a very interesting article. I'm a massive user of ssh and allways worried about security, I'll give it a try and if I find something interesting will post here again.
Thanks again,
Luis |
|
| Back to top |
|
|
nihilo
Apprentice
Joined: 05 Nov 2002
Posts: 168
Location: berkeley, ca, usa
|
| Posted: Fri Apr 25, 2008 5:51 am Post subject: |
|
|
| I'm a huge SSH fan, too. It gets my vote for greatest software EVAR! |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Documentation, Tips & Tricks
