I have observed many unexpected behaviour when trying to start netcat in listen mode remotely.
1. When following command is used :

ssh [email protected] 'nc -l -k 80 &'

I observed that the first tcp connection to this listener from any client fails. When trying to establish connection, the listener issues a FIN packet and closes the connection. But when trying to connect once more, connection gets established. I noted some problem with the file descriptors and when I used -d option while starting the netcat :

ssh [email protected] 'nc -d -l -k 80 &'

, this problem gets solved. But I couldn't understand what exactly causes this issue. My question is why does netcat behave differently when executed remotely using ssh.

  1. Another problem I noted is the verbal mode doesn't work.

    ssh [email protected] 'nc -l -v -k 80 &'

This doesn't even start netcat when -v is used.

1 Answer 1


Instead of ending the command with &, supply the -f flag to ssh. Netcat is dying of SIGPIPE when it writes output and sshd is gone. Alternatively, if you don't want to send output back over ssh, you can also redirect netcat's output to a file before putting it in the background ... > /tmp/nc.log &.

  • But I noted that only the first connection has problem. The second time when I try to connect through TCP it establishes the connection. I found this behaviour a little weird.
    – rizwan
    Aug 19, 2015 at 16:32
  • Maybe you are behind an interception ("transparent") proxy and some middlebox is terminating your TCP connection, or something else is listening on port 80? But your nc process is dying. An easier way to reproduce the problem is to run nc -l -k 8888 |& true. You'll see that as soon as nc attempts to write to the pipe, it dies. Then run nc -v -l -k 8888 |& true and it will die immediately because the debugging chatter will go to the pipe and cause a SIGPIPE. Aug 20, 2015 at 10:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .