¿Cómo puedo canalizar comandos a un netcat que permanecerá vivo?

echo command | netcat host port

Esto hace que el comando se envíe al host remoto y que se lean algunos datos. Pero después de unos segundos, la conexión se cierra. El parámetro -w no cambió nada. Estoy usando netcat v1.10 en SuSE 10.1.

Esto funciona con el nccomando en OS X (suponiendo que el comando que desea enviar esté en un archivo):

cat file - | nc host port

(Básicamente, catvolca el contenido del archivo en stdout y luego te espera en stdin).

Por extensión, si desea enviar el comando desde el propio shell, puede hacer esto:

cat <(echo command) - | nc host port

Con ncen Ubuntu:

nc -q -1 host port

Desde la página del manual de Ubuntunc :

 -q seconds
         after EOF on stdin, wait the specified number of seconds and then quit. If seconds is negative, wait forever.

Tenga en cuenta que las ncopciones disponibles varían mucho entre las distribuciones, por lo que esto podría no funcionar en la suya (OpenSUSE).

Lo encontré:

echo command | netcat host port -

Mi compañero de trabajo lo sabía. No veo eso en la documentación en absoluto.

No creo que vayas a manejar esto con netcat o socat. Acabo de hacer muchos ajustes con ambos, y Socat parecía el más prometedor.

Logré configurar socat para conectarme al puerto TCP remoto y escuchar en un socket de dominio unix local (en teoría, por lo que el enlace podría mantenerse todo el tiempo), pero tan pronto como el proceso local se separó del socket unix (otro socat vinculando el socket de Unix a stdin / out) cerró la sesión de socat TCP.

El problema aquí es que cada conexión a través de netcat / socat realiza una nueva conexión de flujo TCP al servidor, y cierra esa sesión de flujo TCP cuando el extremo local se desconecta.

Creo que probablemente tendrá que escribir un software proxy personalizado para esto que abra la conexión TCP al extremo remoto y luego escuche localmente en un socket / pipe / fifo o lo que sea y luego simplemente envíe los datos por la tubería TCP existente y devuelve los resultados.

¿Podría ser que la conexión esté cerrada en el otro extremo del zócalo?

Por defecto, nccierra la conexión después de la finalización, si no le dice explícitamente que se quede escuchando (con la -kopción):

 -k    Forces nc to stay listening for another connection after its current
       connection is completed.  It is an error to use this option without the
       -l option.

Ver man nc.1.

Estoy transmitiendo datos con éxito entre dos máquinas como esta:

• remitente:

  while (true); do 
    echo -n "$RANDOM " | nc <host> <port>
  done
  

• receptor:

  nc -kl <port> 
  

El método de Georges funciona bien desde un shell interactivo, pero no ayudará con los scripts, por ejemplo, cuando llama a su script como nohup ./script &.

Encontré que reemplazar stdin con un dummy fifo ayuda.

 mkfifo dummy
 cat command.txt dummy | nc host port

Como nada escribe en el fifo, después de generar el archivo, se catcuelga indefinidamente.

socatLa shut-noneopción debería ayudar aquí:

Changes the (address dependent) method of shutting down the write part of a connection to not do anything.

Probablemente también deba anular el período de tiempo de espera predeterminado utilizando -t <timeout>, de lo contrario, el socket se cerrará después de 0.5s. Esta opción anula el comportamiento predeterminado, que es:

When one of the streams effectively reaches EOF, the closing phase begins. Socat transfers the EOF condition to the other stream, i.e. tries to shutdown only its write stream, giving it a chance to terminate gracefully. For a defined time socat continues to transfer data in the other direction, but then closes all remaining channels and terminates.

Entonces, un comando como:

echo 'blah' | socat -t 10 stdio tcp:<addr>:<port>,shut-none

mantendrá el socket abierto durante 10 segundos después de enviar el 'bla'.

Su comando finaliza, si el host remoto cierra la conexión (o no es accesible) o el comando antes de que finalice la canalización (mientras netcat aún envía el resto de su cola de entrada).