How to start two processes piggie-backed? So the first finishes when the second finishes?

Question

I'm running a script with ssh commands to a server behind a jump-host. Each time I want to run a command on my server in the secure network, I need to ssh into the jump-host (bastion) server and run nc and then ssh in with the actual command I want to run through the netcat channel. Then I need to stop the original nc.

I'd like a 'smart ampersand' that lets me run both processes at the same time, and then shuts down the nc ssh process when my piggie-backed process is completed.

Here is what I'm doing currently.

ssh -g -L 23:localhost:22 -f -N user@jumphost &
ssh user2@localhost -P 23 "ssh user@destination server \"ls -al\""
kill -0 $!

The problem with this is that it is not atomic. If there is an error in the script, then it doesn't complete and I don't kill the original nc process at the end.

My question is: How to start two processes piggie-backed? So the first finishes when the second finishes?

Answer 1

This is not answering you question, but this answer on SU is solving your problem, I guess:

Using ProxyCommand in your ~/.ssh/config should do everything for you:

Host server
  HostName server.tld
  User {server user}
Host proxy
  ProxyCommand ssh server -W %h:%p
  User {proxy user}

Then you can access your server simply by using ssh server

Answer 2

If I interpret your command correctly, would it not be the same as this?

ssh -t user@jumphost ssh user@destination ...

All your -L seems to be doing is a port forward to the SSH server of the jumphost - but you're already connecting to that so why the additional tunnel?

In this scenario the jumphost would also be the SSH client for the 2nd connection. If you can't trust the jump host to be the client (i.e. if you want the jump host to see only encrypted data), you'd have to -L 23:destination:22 instead of localhost, no?

Answer 3

A workaround using wait:

With wait you could use a PID to wait for: wait $PID, but we will simply use the argument for running our second command. Note that all output must be ignored for not being passed as argument to the wait command (thus leaving us with an argumentless use of wait as in command & wait)

process1 & wait $( process2 &> /dev/null )

logically process1 will have to wait for process2 to finish as wait is waiting for process2 to finish in order to get the variable interpreted.

---

EDIT: This may also be nested:

sleep 1 & wait $( sleep 2 & wait $( sleep 3 & wait $( sleep 4 ) ) )

will sleep for 4 seconds.