SSH port forwarding without session

I am trying to forward my port 8085 which is a live camera stream port for a mini http server, to a remote server.

My command which I am using is as so:

ssh -R $rport:dc-bb7925e7:$camport -p 25 server@192.168.178.20

As this command is right now, it does forward the port and I can see the live stream on the remote server by going to localhost:8085, BUT the problem is that on the client, there is a TTY session open which prevents all further scripts from running.

So I tried using ssh in the background with:

ssh -Nf -R $rport:dc-bb7925e7:$camport -p 25 server@192.168.178.20

This does not work as it seems as if the connection is closed. The port forwarding is being used in a script where the script assesses an if/then/else condition and then executes to forward. Forwarding this port is not suposed to halt all other scripts. It should simply forward the port and then move on, while keeping it open.

What am I doing wrong or are there any other flags that can be used?

RootWannaBe

Posted 2014-10-17T20:09:10.813

Reputation: 91

The flags you are using should work. The -N makes the ssh non-interactive by not running any command on the remote host and the -f causes the ssh command to run in the background which should allow your script to continue running. I have tested on my local machine and they work as expected. Are you sure there is no other error when running hte script? – Aner – 2014-10-17T21:55:25.557

Answers

Rather than backgrounding an active TTY, you can just let SSH take care of things by itself.

My suggestion is this:

ssh -fNT -R $rport:dc-bb7925e7:$camport -p 25 server@192.168.178.20

The first three options are:

  -f    Requests ssh to go to background just before command execution.
  -N    Do not execute a remote command.
  -T    Disable pseudo-tty allocation.

The -f option is the one that actually backgrounds things, but -N and -T will save resources which you don't need to allocate for an SSH session whose sole purpose is to carry your tunnel.

Also note that some of these options can be added to a custom profile in your ~/.ssh/config file, in case you feel it would be preferable to put more of your static configuration into static configuration files rather than scripts. The RemoteForward config file option is equivalent to the -R command line option.

See also:

ghoti

Posted 2014-10-17T20:09:10.813

Reputation: 641

the -fNT does not work. Have no idea why, but what happens is that once executed, the camera no longer streams to its original port and the remote server can also not view at the forwarded port. – RootWannaBe – 2014-10-18T16:08:04.593

1I just found out that for whatever reason, using the flags above is actually closing the connection. I used a killall ssh command which responded with "No Processes Found" – RootWannaBe – 2014-10-18T16:24:17.553

I have tested all versions of the above three flags -fNT. When using -f the process forking to the background stops this port forwarding. -NT make no difference at all. When this command is used in a script it is important that all other scripts are able to continue to run as normal, but if this command locks the computer in a TTY session on the remote, then no other script afterwards is able to run. I get this in the debug: debug1: Remote connections from LOCALHOST:8089 forwarded to local address dc-bb7925e7:8085 debug1: Requesting no-more-sessions@openssh.com debug1: forking to background – RootWannaBe – 2014-10-19T07:18:56.823

Nobodys got anything huh???? – RootWannaBe – 2014-10-20T04:18:16.727

The -fNT options do work in general, I use them every day. I don't know enough about your particular setup to be able to explain why your tunnels might be getting closed after the ssh process backgrounds itself. The debug output you describe does not appear to be an error. If you want to update your question with the detailed results of your experiment, it would help us come up with better answers.

– ghoti – 2014-10-20T16:42:00.363

Oh I am not arguing that it does not work. Looking at the Syslog and at the debug, it makes no sense why the connection is closed, if it even is. I also see no indicator that it is closed, only that there is no PID so nothing open. It makes difference if I use a different user either. Even if I use root, it closes. It has something to do with the -f option. Any ideas where else to look to solve this? – RootWannaBe – 2014-10-22T02:53:16.200

You could perhaps add your debug output to your question (not in a comment). Maybe ssh isn't even establishing the session? Too many possible things that could be broken, not enough detail to diagnose.

– ghoti – 2014-10-22T14:29:51.333

2I had to add -o ControlPersist=yes to prevent the connection from being closed. This is due to my having ControlMaster=auto in my ~/.ssh/config – Jon Nalley – 2018-09-10T21:33:07.340

I used f without N and made ssh run sleep 1000000, or sleep infinity in gnu. That way the connection stays open without hangups like cat would do. Jon Nalley might be on to something – Ray Foss – 2018-11-09T21:56:52.340

This works even on a mac

ssh -o ControlPersist=yes -fNT -L 3306:127.0.0.1:3306 example.com

You can use & with that and it won't freeze in background, but it will background automatically after login anyways, so don't use &.

-f puts it in the background after login -N disables auto running the remote user shell -T disables the local psudo-tty

-o ControlPersist=yes prevents the connection from being closed when combines with ControlMaster=auto, which happens to be in some user's/install/distros ~/.ssh/config

This would be a way to chain multiple SSH connections and forwards with a one liner or a bash script.

Ray Foss

Posted 2014-10-17T20:09:10.813

Reputation: 884

-N isn't background, it's no remote command. You want something like:

ssh -R $rport:dc-bb7925e7:$camport -p 25 server@192.168.178.20&

Note the trailing ampersand, which will background the command.

You'll likely want to write some logic to go back and close the SSH session when you're done.

ernie

Posted 2014-10-17T20:09:10.813

Reputation: 5 938

2I had already tried the &. It does not forward anything – RootWannaBe – 2014-10-18T16:12:42.147

I think you'll find that the "logic to go back and close the SSH session" is described here.

– Graham – 2018-10-27T01:54:49.180