Determine el proceso utilizando un puerto, sin sudo

Me gustaría saber qué proceso (en particular, la identificación del proceso) está utilizando un puerto determinado. El único inconveniente es que no quiero usar sudo, ni estoy conectado como root. Los procesos para los que quiero que esto funcione son ejecutados por el mismo usuario para el que quiero encontrar la identificación del proceso, por lo que habría pensado que esto era simple.

Ambos lsofy netstatno me dirán la identificación del proceso a menos que los ejecute usando sudo; sin embargo, me dirán que el puerto se está utilizando.

Como contexto adicional: tengo varias aplicaciones que se conectan a través de SSH a un servidor que administro y que crean reenvío de puerto inverso. Una vez que están configurados, mi servidor procesa un poco utilizando el puerto reenviado, y luego se puede cortar la conexión. Si puedo asignar puertos específicos (cada aplicación tiene su propio) a los procesos, este es un script simple. ¿Alguna sugerencia?

Esto está en una caja de Ubuntu, por cierto, pero supongo que cualquier solución será estándar en la mayoría de las distribuciones de Linux.

— palmadita
fuente

Respuestas:

La --programopción de netstat muestra PID y nombres de sus propios procesos. Esta opción está presente y funciona en RHEL 6 en netstat 1.42 de net-tools 1.60.

Verifiqué que netstat -an --tcp --programme muestra los PID de mis procesos.

— Paweł Brodacki
fuente

Creo que quisiste decir -an. netstat -pantTambién funciona y es más fácil de recordar.

— Eduardo Ivanec

Sí, el "-" superfluo entró sigilosamente. Y me gusta el mnemotécnico.

— Paweł Brodacki

Me temo que esto no funciona en Ubuntu, ya que no muestra el proceso en algunos casos sin root, y parece que un reenvío SSH es uno de esos casos.

— Pat

Pawel: ahora el OP finalmente se ha concretado con su caso de uso (vea el comentario en mi cadena), le insto a que lo intente nuevamente. Lo hice, en una caja CentOS 5 (también netstat 1.42 de net-tools 1.60), y falla como él dice. Estaría interesado en tus experiencias.

— MadHatter

La sugerencia de Pawel parece funcionar bien para mí, pero como alternativa, aquí estoy escuchando desde shell1:

[madhatta@risby ~]$ nc -l  localhost 3456

y aquí estoy yo viéndolo lsofdesde shell2:

[madhatta@risby tmp]$ lsof -i tcp:3456
COMMAND   PID     USER   FD   TYPE   DEVICE SIZE/OFF NODE NAME
nc      18109 madhatta    3u  IPv4 69205153      0t0  TCP localhost.localdomain:vat (LISTEN)

Editar : escribe en un comentario que

Los reenvíos SSH deben comportarse de manera diferente: aunque el proceso es propiedad del mismo usuario, no puedo verlo en absoluto en lsof output a menos que lo ejecute como root / sudo.

Pero esto no es así para mí. Habiendo usado ssh para reenviar el puerto local 8001, con ssh vpn.example.com -L 8001:rt.int:80, entonces encuentro:

[madhatta@risby ~]$ lsof -n -i tcp:8001
COMMAND  PID     USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
ssh     5375 madhatta    8u  IPv6 381234      0t0  TCP [::1]:vcom-tunnel (LISTEN)
ssh     5375 madhatta    9u  IPv4 381235      0t0  TCP 127.0.0.1:vcom-tunnel (LISTEN)

¿Podría quizás mostrarnos parte de su salida de muestra, preferiblemente no demasiado redactada?

— MadHatter
fuente

Parece que los reenvíos SSH deben comportarse de manera diferente; aunque el proceso es propiedad del mismo usuario, no puedo verlo en absoluto en la lsofsalida a menos que lo ejecute como root / sudo.

— Pat

No obtengo ninguna salida de lsof en el puerto reenviado cuando se ejecuta como usuario. Si lo ejecuto con sudo, entonces veo resultados muy similares a los que ha agregado a su respuesta. La única diferencia notable es que veo el número de puerto real en lugar de vcom-tunnel.

— Pat

Además, este es un reenvío remoto, no un reenvío local, ¿tal vez esa es la fuente de la diferencia? ¿O estabas probando con un mando a distancia?

— Pat

Por reenvío remoto, ¿quiere decir "del servidor AI ssh al servidor B, reenviando el puerto xxx del servidor B de regreso al servidor A"? Si es así, ¿por qué esperaría recoger algo con netstat / lsof en el servidor A? Esto no crea un nuevo oyente en el servidor A, por lo que no se involucra ninguna asignación de puerto en el servidor A (guarde efímeramente).

— MadHatter

SSH de A a B, puerto hacia adelante desde el puerto X en B hasta el puerto Y en C (que está dentro del firewall de A, de ahí la necesidad de reenviar), usando lsof / netstat en B para el puerto X.

— pat