If I run the command

$ ssh othermachine ncat localhost 10000

that opens an ssh session to "othermachine" and pipes it into an ncat process. (There's something else listening on "othermachine" port 10000).

Now if I disconnect the ssh session (with Ctrl+C) the ncat process on "othermachine" keeps running. How do I prevent that? I want ncat to die if its parent ssh exits.


Technically when you ssh to "othermachine" you're remotely running ncat localhost 10000 on "othermachine". There is no piping going on here.

As to something else "listening" I do not believe there is anything. Rather you're running ncat localhost 10000 attempting to connect to something that's listening on port 10000 and there isn't anything there.


$ ncat localhost 10000
Ncat: Connection refused.

If you tell ncat to listen then it will stay open.

$ ncat localhost -l 10000

Putting this together your command works as is, with the addition of the -l switch.

$ ssh othermachine ncat localhost -l 10000

ncat continues to run?

After performing a Ctrl+C ncat localhost -l 10000 too continues to run on the remote server for me as well.

To stop this behavior you could wrap the call to "othermachine" inside of a shell, such as sh.


$ ssh othermachine -t 'sh -c "ncat localhost -l 10000"'
...stays up...

Now in another shell if I login to "othermachine" and confirm it's running:

$ pgrep -l ncat
8479 ncat

If I Ctrl+C the original ssh connection ncat stops running as well.

$ ssh othermachine -t 'sh -c "ncat localhost -l 10000"'
Ctrl + C
Shared connection to othermachine closed.

Confirming it's gone:

$ pgrep -l ncat

Why does this work?

The key piece in this setup is the -t switch. This forces the connection to setup a pseudo-tty (ptty) terminal as part of the connection.

excerpt from ssh man page

 -t     Force pseudo-tty allocation.  This can be used to execute arbitrary
        screen-based programs on a remote machine, which can be very useful,
        e.g. when implementing menu services.  Multiple -t options force tty 
        allocation, even if ssh has no local tty.

This ptty allows us to send the Ctrl+C through to ncat which is then terminated, resulting in the closing of the ssh connection entirely.


  • By "something else listening" I mean that there is a different program already running on 'othermachine' and listening on port 10000, so this answer is not relevant. – JanKanis Jan 30 '14 at 20:24

Taking a quick look at man ssh

If command is specified, it is executed on the remote host instead of a login shell.

This could be the cause why it keep running after a SIGTERM/SIGKILL. If you want to force a shell login you will need to do something like:

ssh othermachine -t 'bash -l -c "ncat localhost 10000"'
  • I did a quick test with iperf(ssh othermachine -t 'bash -l -c "iperf -s "') and it worked. Without calling explicitly bash, it will keep running ;) – user34720 Dec 12 '13 at 12:54

nwildner's answer works, but the only thing I'm worried about is that the -t switch assigns a pseudo-tty, and that could perhaps result in terminal escape sequences not passing through cleanly? In the case of forwarding with ncat, a better solution for my case is to use

ssh othermachine -W localhost:10000

which is ssh's native way to forward the connection.

  • I do prefer the remote host execution instead forcing a login shell too ;) – user34720 Dec 12 '13 at 15:38

Another answer to this question is to use nc instead of ncat. It generally has the same functionality. If ncat's stdin is closed, ncat does not close its end of the tcp connection, while nc does.

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.