7

When I run

FOO=$(ssh -L 40000:localhost:40000 root@1.2.3.4 cat /foo)

I get the contents of /foo, but then it disconnects.

What I'd like to do is somehow get the content of /foo and keep the connection open so that port 40000 is still forwarded to the same server. Is this possible?

You might ask, why not just issue two ssh connections like this

FOO=$(ssh root@1.2.3.4 cat /foo)
ssh -L 40000:localhost:40000 root@1.2.3.4 -f -N

In my situation, the reason I can't do this is because the ip (1.2.3.4) is a load balancer that forwards the connection to a number of random backends. Each time I ssh to 1.2.3.4 I get a different machine, and the contents of /foo are different for every machine. Moreover, the data I send over the forwarded port (40000) depends on the contents of /foo. If I grab the contents of /foo on machine A and then sent data over port 40000 to machine B, things don't work.

8

What you are describing is known as SSH multiplexing.

I use that setup in a devops setting for caching my connections to any VMs.

In that way I reuse the same connection for up to 30 minutes/cache the connection without renegotiating the entire SSH connection (and authenticating the user) in each new command.

It gives me an huge boost in speed when sending (multiple) commands in a row to a VM/server.

The setup is done on the client side, and for a cache of 30 minutes, the setup can be done in /etc/ssh/ssh_config as:

ControlPath ~/.ssh/cm-%r@%h:%p
  ControlMaster auto
  ControlPersist 30m

The MaxSessions parameter, also in ssh_config also defines how many multiplexed connections simultaneous connections are allowed; the default value is 10. If you need more simultaneous cached connections you might want to change it.

For instance, for a maximum of 20 cached connections:

MaxSessions 20

For more information, see OpenSSH/Cookbook/Multiplexing

An advantage of SSH multiplexing is that the overhead of creating new TCP connections is eliminated.
...
The second and later connections will reuse the established TCP connection >over and over and not need to create a new TCP connection for each new SSH connection.

Also see Using SSH Multiplexing

SSH multiplexing is the ability to carry multiple SSH sessions over a single TCP connection

Without multiplexing, every time that command is executed your SSH client must establish a new TCP connection and a new SSH session with the remote host. With multiplexing, you can configure SSH to establish a single TCP connection that is kept alive for a specific period of time, and SSH sessions are established over that connection. This can result in speed increases that can add up when repeatedly running commands against remote SSH hosts.

Lastly, as the multiplexing keeps the TCP connection open between the client and the server, you will have the guarantee that you are talking with the same machine in the load balancer as long as the cache is open/active.

1

There are multiple ways to do it, one you can try is

 ssh -fT -L 40000:localhost:40000 root@1.2.3.4 'sleep 60'
 FOO=$(ssh root@localhost -p 40000 cat /foo)

rest you can continue ...

Here -f is to put it into background and -T is to disable tty allocation. Using sleep command to keep session active for 60s and to allow exit itself, you can modify it or make it up by other ways.

A simple one, for example, keep the session alive until it sees a file /tmp/a.txt , as once you are done with your work, create a file , while loop will see it and run the cleanup rm /tmp/a.txt and exits the session.

ssh -fT -L 40000:localhost:40000 root@1.2.3.4 'while [[ ! -f /tmp/a.txt ]] ; do sleep 2 ; done ; rm /tmp/a.txt'
FOO=$(ssh root@localhost -p 40000 cat /foo)
do you work..
ssh root@localhost -p 40000 touch /tmp/a.txt

You can use any other conditions which suits you better to keep it alive.

-3

I use sshpass

install it with your package manager on your local machine

then run

sshpass -p 'YOUR_SSH_PASSWORD' USER@1.1.1.1 'YOUR-COMMAND' 
  • 2
    That won't help in any way. sshpass just types the password for you, it doesn't help in multiplexing the same connection or keeping the connection open. (Also, FWIW, it's better to pass the password through the environment with sshpass -e, as the command line is commonly visible to all users on the system.) – ilkkachu Sep 4 '18 at 18:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.