Reusing existing OpenSSH v4 connections

Posted by Steve on Thu 10 Nov 2005 at 11:18

Tags:

I've recently learnt of an interesting new features of OpenSSH v4 which allows you to reuse open connections when connecting to the same host more than once. If you regularly have multiple open connections to a single host this is a big timesaver.

This takes advantage of a new option "ControlMaster". Quoting from the manpage:

ControlMaster

Enables the sharing of multiple sessions over a single network connection. When set to "yes" ssh will listen for connections on a control socket specified using the ControlPath argument.

ControlPath

Specify the path to the control socket used for connection sharing as described in the ControlMaster section above or the string "none" to disable connection sharing. In the path, '%h' will be substituted by the target host name, '%p' the port and '%r' by the remote login username. It is recommended that any ControlPath used for opportunistic connection sharing include all three of these escape sequences.

So what does this mean? It means that you can setup a socket in the path ControlPath, and this socket will be used when you reconnect to the given host.

An example will be clearer.

Assume that you're on the host itchy and you wish to connect multiple times to the host scratchy.

Connect the first time with :

ssh scratchy  -M -S /tmp/%r@%h:%p

Here we've set two options:

-M

This is setting the "ControlMaster" option.

-S /tmp/%r@%h:%p

This is the setting for the ControlPath specifying that we should save the master socket as /tmp/user@hostname:port.

Now that we've setup the master connection we can connect a second time with:

ssh scratchy -S /tmp/%r@%h:%p

This time the connection is immediate. There is no option negotiation, etc, taking place. We can verify this by adding a -v flag:

skx@itchy:~$ ssh -v  scratchy -S /tmp/%r@%h:%p
OpenSSH_4.2p1 Debian-5, OpenSSL 0.9.8a 11 Oct 2005
debug1: Reading configuration data /home/skx/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *

Linux scratchy.my.flat 2.6.8-1-386 #1 Thu Nov 25 04:24:08 UTC 2004 i686 GNU/Linux

The programs included with the Debian GNU/Linux system are free software;
...
...
snip

There we see the connection just occurs almost immediately, with none of the usual OpenSSH negotiation taking place.

Rather than messing around upon the command line we can setup these options within the configuration file .ssh/config, simply add a new stanza reading:

Host *
  ControlPath /tmp/%r@%h:%p

Now we can connect as normal, so long as we make the first connection to any host with -M (for "Master") all subsequent connections will be much faster.

Cool, huh?

If you don't think you can remember to specify the -M flag for the first one then you can also force this by setting your options to:

Host *
  ControlMaster auto
  ControlPath /tmp/%r@%h:%p

(Using autoask instead of auto will force the connection to prompt you whether you wish to setup a socket)

The only mention of this I've seen so far is this blog entry, which Matt Brown linked to recently.

 

 


Posted by sabin (193.171.xx.xx) on Thu 10 Nov 2005 at 11:42
[ View sabin's Scratchpad | View Weblogs ]
sabin@debx:~$ ssh -v
OpenSSH_3.8.1p1 Debian-8.sarge.4, OpenSSL 0.9.7e 25 Oct 2004

how would I upgrade this stuff using apt? is actually possible with special sources? any hints on that?
greets!

./sabin -s

[ Parent | Reply to this comment ]

Posted by Steve (82.41.xx.xx) on Thu 10 Nov 2005 at 11:47
[ View Steve's Scratchpad | View Weblogs ]

If you're using unstable (sid), or testing (etch), then you'll have version 4 already.

If you're running Debian's stable release, sarge, then you'll either have to wait or install a backported version. So far http://backports.org appears to still be focussing upon Woody backports.

You might have some success using the packages available from http://www.apt-get.org, however for such an important, and security-sensitive, package I'd be wary of trusting a semi-random source on the internet....

Steve
--

[ Parent | Reply to this comment ]

Posted by sabin (193.171.xx.xx) on Thu 10 Nov 2005 at 11:55
[ View sabin's Scratchpad | View Weblogs ]
oh I see.. so I think I'm gonna stick to my version of sarge since it's more important to keep this box secure!

thanks for your hints Steve!

./sabin -s

[ Parent | Reply to this comment ]

Posted by Anonymous (217.11.xx.xx) on Fri 11 Nov 2005 at 08:57
Or he could also maintain mixed system.

[ Parent | Reply to this comment ]

Posted by spiney (128.131.xx.xx) on Thu 10 Nov 2005 at 12:09

Not browsing the man page of new software versions really lets one miss a couple of very interesting features. And this website helped me finding such features more than once, so it's time to say: Thanks a lot, great work! --
Debian GNU/Linux on an IBM Thinkpad T43p

[ Parent | Reply to this comment ]

Posted by outreal (82.239.xx.xx) on Thu 10 Nov 2005 at 13:50
Very useful tip ! It really speeds things up !

The only drawback I found is that, for example, you open a first ssh connection in a console, and then a second ssh connection to the same host in another console, then if you close the FIRST connection (exit or ^D), it won't come back to your console until you close the second one.

[ Parent | Reply to this comment ]

Posted by Steve (82.41.xx.xx) on Thu 10 Nov 2005 at 14:10
[ View Steve's Scratchpad | View Weblogs ]

True, because it is keeping the channel open.

To solve this you can setup the first SSH command to run in a "detatched" manner, but that does require special effort.

Try running this as the "first" connection:

ssh -MNf user@host.name.com uptime

This will open the connection, running the command "uptime" remotely, then go into the background.

Now you can reconnect multiple times and use that previously "Nf"'d session.

Steve

[ Parent | Reply to this comment ]

Posted by Anonymous (186.125.xx.xx) on Mon 6 Sep 2010 at 03:57
Hi, i executed -MNf and when exit'ing, the connection didnt close. How do i close it now? Thanks!

[ Parent | Reply to this comment ]

Posted by jeld (24.39.xx.xx) on Thu 10 Nov 2005 at 15:19
This is a neat trick, but what is the actual advantage? connection setup/breakdown is not a big deal compared to a console session or a file over SSH. Now I would have to deal with all the issues of "Do I already have a master connection to this host or do I need to make one?", "Where the hell did I put that socket for this host?" etc. These are minor issues and probably easily managable, but why have them in the first place? So, by using this master/slave mode I get the following:

1. No TCP connection setup/breakdown overhead (a grand total of 5 packets per conn.)
2. No extra connections at the kernel level and no extra sshd processes spawned on the server side (on my server an sshd takes 7.3K of virtual memory 2.4K out of those in real RAM)
3. Less CPU load due to a single encryption engine serving the shared connection (not sure if this is actually true and I never seen SSH take any noticeable amount of CPU anyway)

So the question is: Why?

You are off the edge of the map, mate. Here there be monsters!

[ Parent | Reply to this comment ]

Posted by spiney (128.131.xx.xx) on Thu 10 Nov 2005 at 17:35

Setting up the connection takes a bit more than the TCP 3-way handshake, exchanging host and session keys etc. And when using the config settings as writen in the article you don't have to think beforehand whether there's a master channel or not or where the socket is.

But granted, it's not like ssh just became my favorite tool after this article (it was that before), but it's still a nice feature. Only drawback is that the master channel doesn't get transfered to the last open connection or something... --
Debian GNU/Linux on an IBM Thinkpad T43p

[ Parent | Reply to this comment ]

Posted by jeld (24.39.xx.xx) on Thu 10 Nov 2005 at 18:39
Seems like you are right about the connection confusion, I somehow missed the bit where you can set master to "auto"

You are off the edge of the map, mate. Here there be monsters!

[ Parent | Reply to this comment ]

Posted by Anonymous (81.57.xx.xx) on Fri 11 Nov 2005 at 12:32
It also make the establishment of a new connection much faster.
No more delay waiting for you're shell on a distant host ;)

[ Parent | Reply to this comment ]

Posted by Anonymous (68.173.xx.xx) on Fri 11 Nov 2005 at 13:37
Why is that? You still need a separate shell, only the encrypted tunnel gets reused. And even if there was some screen-like capability that would reuse existing shell, anyway, time needed to start a new shell is negligible.

[ Parent | Reply to this comment ]

Posted by Anonymous (201.31.xx.xx) on Thu 24 Nov 2005 at 16:53
If you use CVS on Alioth, which can be quite broken and make you wait up to 10 minutes for a connection (but works normally after that), you will see the advantages immediately.

[ Parent | Reply to this comment ]

Posted by Anonymous (194.47.xx.xx) on Thu 10 Nov 2005 at 18:07
You mean, exactly like IPsec already does? Gosh. All we have left before SSH can completely replace IPsec is, uhm, let’s see… encryption of UDP, web of trust (X509 certs or equivalent), TOS, and probably some more stuff. SSH - the Internet encryption system for Internet of the future! Everything over TCP, port 22! Woohoo!

[ Parent | Reply to this comment ]

Posted by grimoire (140.247.xx.xx) on Thu 17 Nov 2005 at 03:25
I don't think that IPSec and SSH are designed to do the same things. SSH can do some things that IPSec can do, but it's a lot simpler and better suited to some tasks.

On the other hand, I just replaced all my IPSec implementations with OpenVPN because I was fed up with niggling vendor implementation differences, so perhaps I'm biased against IPSec :)

[ Parent | Reply to this comment ]

Posted by Anonymous (82.39.xx.xx) on Thu 22 Feb 2007 at 15:44
I think Anonymous was being facetious.

[ Parent | Reply to this comment ]

Posted by jeld (24.39.xx.xx) on Thu 10 Nov 2005 at 18:45
I just tried to add the lines for ControlMaster and ControlPath to my ssh config
1. auto setting for ControlMaster doesn't seem to work and setting this to yes causes a conflict.
2. Variables in ControlPath do not get expanded, so one would need to set an individual socket path to every host you might want to connect to.

You are off the edge of the map, mate. Here there be monsters!

[ Parent | Reply to this comment ]

Posted by Steve (82.41.xx.xx) on Thu 10 Nov 2005 at 18:58
[ View Steve's Scratchpad | View Weblogs ]

What diagnostics do you see when running with "-v -v"?

It should work if you're using the version 4.x of OpenSSH ... and certainly does for me ... but it is hard to see why it would fail.

Steve

[ Parent | Reply to this comment ]

Posted by jeld (24.39.xx.xx) on Thu 10 Nov 2005 at 20:05
Looks like the problem is in the version, I was trying this on Ubuntu Breezy, which runs SSH 4.1p1 as opposed to 4.2p1 in Debian

You are off the edge of the map, mate. Here there be monsters!

[ Parent | Reply to this comment ]

Posted by Anonymous (69.76.xx.xx) on Thu 10 Nov 2005 at 20:20
I don't think I would ever connect twice to the same host, aside from perhaps on the rare occasion when I transfer a file with scp--I assume this works automatically for scp as well (ith the proper configuration settings)? I thik it's much faster (and more convenient) to simply use screen on a single connection than having multiple connections running.

[ Parent | Reply to this comment ]

Posted by dkg (216.254.xx.xx) on Fri 11 Nov 2005 at 16:13
[ View dkg's Scratchpad | View Weblogs ]
There are some situations where you often need to set up multiple connections to the same host. Brian Hatch's ssh bouncing is one really useful example. He uses ssh's ProxyCommand option to securely access machines within a firewalled LAN by sshing to the gateway machine and pushing another connection through that pipe.

In the event that you are connecting to multiple machines within such a firewalled LAN, being able to multiplex your initial hop into the gateway is a big win in terms of speed and convenience.

[ Parent | Reply to this comment ]

Posted by dkg (216.254.xx.xx) on Fri 11 Nov 2005 at 01:17
[ View dkg's Scratchpad | View Weblogs ]
Thanks for popularizing this, Steve! It's been mentioned a couple times on the openssh development list, but i'm sure that exposure here will bring it to a much wider audience.

One thing to note, though: using /tmp for the location of your ControlPath is probably a bad idea, at the very least because it opens you to a potential denial of service from other users on the host running the ssh client, who can simply create the file /tmp/skx@scratchy:22 before you do, which blocks you from using ssh for that host (with an error something like: ControlSocket /tmp/skx@scratchy:22 already exists)

To be clear, i don't think this is a security risk beyond being unable to use the ssh client. On a debian etch/sid system i tested here (with openssh 4.2p1-5), it appears that ssh is smart enough to not clobber anything through a symlink. But anyway, using something like the following stanza in ~/.ssh/config would be better:

Host *
ControlMaster auto
ControlPath ~/.ssh/controls/%r@%h:%p
(and of course, you'll need to do something like:
mkdir -p ~/.ssh/controls
chmod 0700 ~/.ssh/controls
before you get started with this)

[ Parent | Reply to this comment ]

Posted by yarikoptic (67.82.xx.xx) on Fri 25 Nov 2005 at 05:45
and since I keep .ssh/config under CVS ( as well as other ~/.blarc files ) I just created directory ~/.ssh/controls, created a dummy file ~/.ssh/controls/dummy (so CVS creates controls on update) and added it to CVS. Now on any other machine I just
cd .ssh; cvs update
and I'm ready to go with my fresh config :-)

[ Parent | Reply to this comment ]

Posted by Anonymous (62.235.xx.xx) on Sun 15 Jan 2006 at 11:44
Hi all,

Nice catch ;-)

It works fine to me too with following config file:
Host *
ControlMaster auto
ControlPath ~/.ssh/controls/%r@%h:%p

Unfortunately when I replace auto by ask, the master connection is ok but next one failed:
$ ssh -vv hpal-ip6
OpenSSH_4.2p1 Debian-5, OpenSSL 0.9.8a 11 Oct 2005
debug1: Reading configuration data /home/jso/.ssh/config
debug1: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to hpal-ip6 [2001:db8:5:6::78] port 22.
debug1: Connection established.
debug1: identity file /home/jso/.ssh/identity type -1
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug2: key_type_from_name: unknown key type '-----END'
debug1: identity file /home/jso/.ssh/id_rsa type 1
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug2: key_type_from_name: unknown key type '-----END'
debug1: identity file /home/jso/.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.2p1 Debian-5
debug1: match: OpenSSH_4.2p1 Debian-5 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.2p1 Debian-5
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,di ffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour25 6,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes12 8-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour25 6,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes12 8-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac -sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac -sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,di ffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour25 6,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes12 8-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour25 6,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes12 8-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac -sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac -sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_init: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_init: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 129/256
debug2: bits set: 507/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'hpal-ip6' is known and matches the RSA host key.
debug1: Found key in /home/jso/.ssh/known_hosts:4
debug2: bits set: 506/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/jso/.ssh/identity ((nil))
debug2: key: /home/jso/.ssh/id_rsa (0x80913c8)
debug2: key: /home/jso/.ssh/id_dsa (0x80913e0)
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /home/jso/.ssh/identity
debug1: Offering public key: /home/jso/.ssh/id_rsa
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 149
debug2: input_userauth_pk_ok: fp fa:80:e0:18:1e:f9:9a:91:c7:6b:ee:f8:a5:21:cd:db
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
debug1: setting up multiplex master socket
ControlSocket /home/jso/.ssh/controls/jso@hpal-ip6:22 already exists

I read well man ssh_config which said:
ControlMaster
[...]
tion rather than initiating new ones. Setting this to ``ask''
will cause ssh to listen for control connections, but require
confirmation using the SSH_ASKPASS program before they are
accepted (see ssh-add(1) for details). If the ControlPath can
not be opened, ssh will continue without connecting to a master
instance.

X11 and ssh-agent(1) forwarding is supported over these multi-
plexed connections, however the display and agent fowarded will
be the one belonging to the master connection i.e. it is not pos-
sible to forward multiple displays or agents.
[...]

I also tried to start ssh-agent :
$ ssh-agent bash
$ ssh-add

but it didn't help?

Any idea?

TIA,
Joel

[ Parent | Reply to this comment ]

Posted by dkg (216.254.xx.xx) on Sun 15 Jan 2006 at 16:49
[ View dkg's Scratchpad | View Weblogs ]
Yep. i think you want the 'autoask' option, rather than 'ask' (or 'auto' instead of 'yes'). It looks like your second connection is actually negotiating a whole new SSH session, rather than reusing the control socket. It's failing because the control socket already exists. There can't be two ControlMasters controlling the exact same socket, so one of them needs to just use the socket, instead of controlling it.

If you default to autoask, then the first connection will negotiate with the remote server and set up a socket. That becomes the ControlMaster. Subsequent connections won't try to be the ControlMaster because they see the socket exists already. They won't even try to negotiate a connection, they'll just talk to the socket. At that point, the 'ask' comes in: your ControlMaster sees the new communication on the socket, and prompts you (via $SSH_ASKPASS) to accept or reject the connection.

from man ssh_config, in the section about ControlMaster:

Two additional options allow for opportunistic multiplexing: try to use a master connection but fall back to creating a new one if one does not already exist. These options are: ``auto'' and ``autoask''. The latter requires confirmation like the ``ask'' option.
If this is still not working for you, you should test $SSH_ASKPASS independently from a shell, like this:
if [ -n "$SSH_ASKPASS" ]; then 
    $SSH_ASKPASS 'test question'
else
    ssh-askpass 'test question'
fi
If you don't get a pop-up prompt with the text "test question", ask won't work for you. try installing one of
  • ssh-askpass
  • ssh-askpass-fullscreen
  • ssh-askpass-gnome
  • gtk-led-askpass

[ Parent | Reply to this comment ]

Posted by Anonymous (57.67.xx.xx) on Mon 16 Jan 2006 at 15:56
ok 'auto' works fine: ssh -v a_remote_host shows me well that it reuse master socket.

OTH 'autoask' behave like ask, i.e. "Connection to master denied" but this time in the screen of my master ssh I got fllowing message:

"ssh_askpass: exec(/opt/openssh/4.2p1/libexec/ssh-askpass): No such file or directory"

I so missed prgm ssh-askpass ;-(

mmm, I install so ssh-askpass dpkg but failed because "Can't open display" and obvioulsy, my box is a parisc-linux without graphical interface, so I couldn't start gui. Does it exist a tui which can replace ssh-askpass?

Thanks for adivse and help,
Joel

[ Parent | Reply to this comment ]

Posted by dkg (216.254.xx.xx) on Mon 16 Jan 2006 at 18:50
[ View dkg's Scratchpad | View Weblogs ]
obvioulsy, my box is a parisc-linux without graphical interface, so I couldn't start gui.
that wasn't so obvious to me, actually. It certainly complicates things.
Does it exist a tui which can replace ssh-askpass?
The basic problem is: the Master connection is the one doing the prompting with 'ask'. When you make your second connection attempt (on a different virtual terminal, i suppose?), the master has to prompt you somehow. If you have separate virtual terminals, i don't know how the first connection would be able to get your attention cleanly without some sort of serious disruption.

AFAIK, ssh-askpass (or any of its variants) only work in an X11 environment, because they rely on X11 for the kind of out-of-band prompting we're talking about. are you really working at this machine directly from the console with no X? if you are working on it remotely (i.e. logged in over the network from a machine running a GUI) it's possible that you could use a forwarded X11 connection to allow for the prompting.

If you do find a text-mode way to use ssh-askpass (or something similar), please post here! i'd love to see it.

[ Parent | Reply to this comment ]

Posted by Anonymous (57.67.xx.xx) on Tue 17 Jan 2006 at 10:02
well apologies, I realy have to learn more on writing english, though; replaceing the idea in the right sense, it would give better something like ;-):
"my box being a parisc-linux without gfx, obvioulsy I couldn't start local gui"

...
"If you have separate virtual terminals,..."

Well I don't have any detailed idea of the pb but what do you think about screen?

Ok, if by chance I found some helpfull stuff, I will advise you and kind debian-administration ;-)

Thanks for attention,
Joel

[ Parent | Reply to this comment ]

Posted by Anonymous (131.169.xx.xx) on Fri 11 Nov 2005 at 12:52
It works perfect! Thanks for the tip. I was wondering how can I apply this to scp?
I tried something like:

scp -o ControlPath=/tmp/%r@%h:%p <local_file> <remoth_host>:<remoth_path>

but it does not work... Any ideas?

[ Parent | Reply to this comment ]

Posted by Steve (82.41.xx.xx) on Fri 11 Nov 2005 at 13:07
[ View Steve's Scratchpad | View Weblogs ]

Works for me:

skx@itchy:~$ scp -v  -o ControlPath=/tmp/%r@%h:%p /tmp/*.mp3  skx@itchy:
Executing: program /usr/bin/ssh host itchy, user skx, command scp -v -t .
OpenSSH_4.2p1 Debian-5, OpenSSL 0.9.8a 11 Oct 2005
debug1: Reading configuration data /home/skx/.ssh/config
debug1: Applying options for www.steve.org.uk
debug1: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
Sending file modes: C0600 91 whisky_in_the_jar.mp3.m3u
whisky_in_the_jar.mp3                     100%   91     0.1KB/s   00:00    

What output do you get when you add a "-v" to the copy?

Steve

[ Parent | Reply to this comment ]

Posted by Anonymous (131.169.xx.xx) on Fri 11 Nov 2005 at 13:40
Indeed, it is working. I guess I have done something wrong the first time. Thanks for the reply.

[ Parent | Reply to this comment ]

Posted by Anonymous (217.149.xx.xx) on Fri 11 Nov 2005 at 17:33
Probably some of you have noticed, that when you shutdown your master session it hangs until you close all associated client sessions. The script below (coupled with a rm -f ${HOME}/.ssh/mux-* in your .xinitrc or something) spawns the master session in a background screen after which a client session is started. The netto result is that the master sessions are closed whenever you shutdown your box and your ssh sessions will behave like you're not even using multiplexing :)

alita [~]$ cat ./bin/ssh_master.sh
#!/bin/sh

if [ ${#} -lt 2 ]; then
echo "Usage: $(basename ${0}) REMOTE [CMD]"
exit 1
fi

REMOTE="${1}" ; shift
[ ${#} -ge 1 ] && CMD="${@}"

MUX="${HOME}/.ssh/mux-*@${REMOTE}:22"
if [ ! -S ${MUX} ]; then
echo "Spawning master session, please wait"
screen -dmS "${REMOTE}_ssh_master" ssh -t ${REMOTE}
while :; do
[ -S ${MUX} ] && break
sleep 1
done
fi
ssh -t ${REMOTE} ${CMD}

One requirement tho, is that you're using pubkey authentication with passphrase caching. The following configuration snippets may also be handy:

~/.ssh/config
Host *
ControlMaster auto
ControlPath ~/.ssh/mux-%r@%h:%p

and

~/.bashrc
SSH=/path/to/ssh_master.sh
alias somehost='${SSH} somehost sudo bash'


Yeah, the sudo bash part is nasty, but it saves me a lot of typing :)

[ Parent | Reply to this comment ]

Posted by Anonymous (173.8.xx.xx) on Fri 20 Aug 2010 at 23:36
ssh -M -Nf user@host spawns the process to use as the master asks for the password and then goes into the background.

[ Parent | Reply to this comment ]

Posted by Miciah (24.252.xx.xx) on Sat 12 Nov 2005 at 19:15
This is very nifty with the tab-completion for SCP in BASH and ZSH.

[ Parent | Reply to this comment ]

Posted by Anonymous (82.32.xx.xx) on Sun 13 Nov 2005 at 12:51
If you have ControlMaster set to auto or autoask, then if you make use of traffic shaping you may run into problems if you use scp or sftp. If the master socket was created by an sftp socket then all your data will be transmitted with 'maximise throughput' set--including any subsequently launched shell sessions (which, if they set up the TCP socket, normally use 'minimise delay').

Is there a way to make the settings of ControlMaster and ControlPath only apply for ssh commands, and not sftp/scp?

[ Parent | Reply to this comment ]

Posted by lfousse (81.56.xx.xx) on Sun 13 Nov 2005 at 17:04
I've found the feature fun to play with because new shell sessions are opened really fast. But then I've encountered #335528 and this is the end of connection reuse for me.

[ Parent | Reply to this comment ]

Posted by Anonymous (201.31.xx.xx) on Thu 24 Nov 2005 at 17:01
It is probably worth mentioning that one should never use /tmp for the control path sockets.

Place those on a 700 directory somewhere else, like /home/<your_user>/.ssh/socket, it is much safer.

[ Parent | Reply to this comment ]

Posted by gibies (121.242.xx.xx) on Mon 12 Jul 2010 at 14:04
I came through a requirement to access multiple files from a remote server. The following script is a part of my script in NCAR Command Language, which I am using for analysing those data files. The script is using sftp. The sftp system command is residing inside a loop in this script and it is prompting for a password during every iteration of the loop.

Is there a way to put sftp outside the loop. That is to avoid the password varification for each file to be transferred. I mean, it is better if possible to varify password only once.


print("Enter the starting year as an integer value:")
y1 = stringtointeger(systemfunc("read var; echo $var"))
;print("y1="+y1)
year1 = sprinti("%2.2i",y1)
print("starting month="+year1)

print("Enter the ending year as an integer value:")
yn = stringtointeger(systemfunc("read var; echo $var"))
;print("yn="+yn)
yeare = sprinti("%2.2i",yn)
print("ending month="+yeare)

print("Enter the season starting month as an integer value:")
m1 = stringtointeger(systemfunc("read var; echo $var"))
;print("m1="+m1)
mms = sprinti("%2.2i",m1)
print("starting month="+mms)

print("Enter the season ending month as an integer value:")
mn = stringtointeger(systemfunc("read var; echo $var"))
print("mn="+mn)
mme = sprinti("%2.2i",mn)
print("ending month="+mme)

print("Enter the userID : ")
usr = systemfunc("read var; echo $var")
print("Enter the IP address : ")
ip = systemfunc("read var; echo $var")
print("Enter the path : ")
path = systemfunc("read var; echo $var")

nyrs = yn-y1+1
nsea = mn-m1+1
nmos = nyrs*nsea
fnames= new ( nmos , "string")

imo = -1
do y = y1,yn ; generate file names
yyyy = sprinti("%4.4i",y)
do m = m1,mn
mm = sprinti("%2.2i",m)
print("mm="+mm)
imo = imo+1
fnames(imo) ="time_mean."+ yyyy + mm + ".nc"
end do
end do
print(" ")
print(fnames)
print(" ")

nfils = dimsizes(fnames)


filftp = usr+"@"+ip+":"+path

do imo=0,nfils-1
if (.not.isfilepresent(fnames(imo))) then
SFTP = "sftp "+filftp+fnames(imo) ; create system command
print("SFTP: "+SFTP)
system(SFTP) ; execute the command
end if
end do

[ Parent | Reply to this comment ]

Posted by Anonymous (68.111.xx.xx) on Sat 18 Aug 2012 at 08:59
It is just me or is the following seen by others too?
ssh -M -S /tmp/tmpsocket host1 # keeping it alive for the coming slave
ssh -S /tmp/tmpsocket host2 # connection goes to host1!


If ssh's destination is predetermined once the mux socket is specified, it probably shouldn't be asking for the host at all for slave connections.
Something like
ssh -S /tmp/tmpsocket # no host
alone does not work.

- Antriksh Pany

[ Parent | Reply to this comment ]

Posted by Steve (212.110.xx.xx) on Sat 18 Aug 2012 at 09:00
[ View Steve's Scratchpad | View Weblogs ]

Yeah, you're not alone in seeing that. The hostname shouldn't be necessary in the case of a socket - but ssh refuses to run without one.

Steve

[ Parent | Reply to this comment ]

Sign In

Username:

Password:

[Register|Advanced]

 

Flattr

 

Current Poll

What do you use for configuration management?








( 263 votes ~ 1 comments )