Determina il processo usando una porta, senza sudo


11

Vorrei scoprire quale processo (in particolare, l'id processo) sta utilizzando una determinata porta. L'unico problema è che non voglio usare sudo, né ho effettuato l'accesso come root. I processi per cui voglio che questo funzioni sono gestiti dallo stesso utente per cui voglio trovare l'ID del processo, quindi avrei pensato che fosse semplice.

Entrambi lsofe netstatnon mi diranno l'id del processo a meno che non li esegua usando sudo, ma mi diranno che la porta viene utilizzata.

Come contesto aggiuntivo, ho diverse app che si collegano tutte tramite SSH a un server che gestisco e che inoltro porta inversa. Una volta impostati, il mio server esegue alcune elaborazioni utilizzando la porta inoltrata, quindi la connessione può essere interrotta. Se riesco a mappare porte specifiche (ogni app ha le proprie) sui processi, questo è uno script semplice. Eventuali suggerimenti?

Questo è su una scatola di Ubuntu, comunque - ma suppongo che qualsiasi soluzione sarà standard in molte distribuzioni Linux.

Risposte:


7

L' --programopzione di netstat ti mostra i PID e i nomi dei tuoi processi. Questa opzione è presente e funziona su RHEL 6 in netstat 1.42 su net-tools 1.60.

Ho verificato che netstat -an --tcp --programmi mostra i PID dei miei processi.


1
Penso che volevi dire -an. netstat -pantfunziona anche ed è più facile da ricordare.
Eduardo Ivanec,

Sì, "-" superfluo si insinuò. E mi piace il mnemonico.
Paweł Brodacki,

Temo che questo non funzioni su Ubuntu - in quanto in alcuni casi non mostra il processo senza root - e sembra che un forward SSH sia uno di quei casi.
pat

Pawel: ora l'OP ha finalmente concretizzato il suo caso d'uso (vedi commento nella mia catena), ti esorto a riprovare. L'ho fatto, su un box CentOS 5 (anche netstat 1.42 da net-tools 1.60), e fallisce come dice lui. Sarei interessato alle tue esperienze.
MadHatter,

3

Il suggerimento di Pawel sembra funzionare bene per me, ma in alternativa, ecco il mio ascolto da shell1:

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

ed eccomi a vederlo con lsofda 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)

Modifica : scrivi in ​​un commento che

I forward di SSH devono comportarsi diversamente - anche se il processo è di proprietà dello stesso utente, non riesco a vederlo elencato nell'output lsof a meno che non lo esegua come root / sudo.

ma questo non è così per me. Avendo usato ssh per inoltrare la porta locale 8001, con ssh vpn.example.com -L 8001:rt.int:80, trovo quindi:

[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)

Potresti forse mostrarci alcuni dei tuoi output di esempio, preferibilmente non eccessivamente redatti?


1
Sembra che i forward di SSH debbano comportarsi diversamente - anche se il processo è di proprietà dello stesso utente, non riesco a vederlo elencato lsofnell'output se non lo eseguo come root / sudo.
pat

Non ottengo alcun output di lsof sulla porta inoltrata quando eseguito come utente. Se lo eseguo con sudo, vedo un output molto simile a quello che hai aggiunto alla tua risposta. L'unica differenza notevole è che vedo il numero di porta effettivo invece di vcom-tunnel.
pat

Inoltre, questo è un forward remoto, non un forward locale - forse questa è la fonte della differenza? O stavi testando con un forward remoto?
pat

Per forward remoto intendi "dal server AI ssh al server B, inoltrando la porta xxx dal server B al server A"? In tal caso, perché dovresti aspettarti di raccogliere qualcosa con netstat / lsof sul server A? In questo modo non viene creato alcun nuovo listener sul server A, quindi non viene coinvolta alcuna assegnazione delle porte sul server A (salva in modo temporaneo).
MadHatter,

SSH da A a B, port forward dalla porta X su B alla porta Y su C (che si trova all'interno del firewall di A - quindi la necessità di forward), usando lsof / netstat su B per la porta X.
pat
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.