Pregunta Determine el proceso usando un puerto, sin sudo


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

Ambos lsof y netstat no me dirá el identificador de proceso a menos que los ejecute utilizando sudo; sin embargo, me dirán que el puerto se está utilizando.

Como un contexto adicional, tengo varias aplicaciones conectadas a través de SSH a un servidor que administro y creando reenvíos de puerto inverso. Una vez que están configurados, mi servidor realiza un procesamiento utilizando el puerto reenviado, y luego la conexión puede ser cancelada. Si puedo asignar puertos específicos (cada aplicación tiene sus propios procesos) a 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.


9
2018-05-08 13:47


origen




Respuestas:


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

He verificado que netstat -an --tcp --program Me muestra los PID de mis procesos.


6
2018-05-08 14:44



Creo que quisiste decir -an. netstat -pant También funciona y es más fácil de recordar. - Eduardo Ivanec
Sí, superfluo "-" entró. Y me gusta la mnemotécnica. - 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 de SSH es uno de esos casos. - pat
Pawel: ahora el OP finalmente se ha concretado con su caso de uso (ver comentario en mi cadena), le insto a que lo intente de nuevo. Lo hice en una caja de CentOS 5 (también netstat 1.42 de net-tools 1.60), y falla como él dice. Me interesaría tu experiencia. - 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 con lsof desde 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: escribes en un comentario que

Los forzados SSH deben comportarse de manera diferente -   a pesar de que el proceso es propiedad de   El mismo usuario, no puedo verlo en la lista.   en absoluto en la salida lsof 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, Luego 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ías mostrarnos algo de tu salida de muestra, preferiblemente no demasiado redactada?


3
2018-05-08 14:45



Parece que los forwards de SSH deben comportarse de manera diferente, aunque el proceso es propiedad del mismo usuario, no puedo verlo en la lista lsof salida a menos que lo ejecute como root / sudo. - pat
No obtengo ningún resultado de lsof en el puerto reenviado cuando se ejecuta como usuario. Si lo ejecuto con sudo, veo una salida muy parecida a la que has agregado a tu 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 avance remoto, no un avance local. ¿Quizás esa es la fuente de la diferencia? ¿O estabas probando con un avance remoto? - pat
Por reenvío remoto, ¿quiere decir "del servidor A I ssh al servidor B, reenviando el puerto xxx del servidor B al servidor A"? Si es así, ¿por qué esperarías recoger algo con netstat / lsof en el servidor A? No se crea una nueva escucha en el servidor A, por lo que no se trata de una asignación de puerto en el servidor A (guardar de manera efímera). - 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