Determinar processo usando uma porta, sem sudo

Gostaria de descobrir qual processo (em particular, a identificação do processo) está usando uma determinada porta. O único problema é que eu não quero usar o sudo, nem estou logado como root. Os processos para os quais eu quero trabalhar são executados pelo mesmo usuário em que desejo encontrar a identificação do processo - então eu pensaria que isso era simples.

Ambos lsofe netstatnão me dirão o ID do processo, a menos que eu os execute usando o sudo - eles me dirão que a porta está sendo usada.

Como um contexto extra - tenho vários aplicativos todos conectados via SSH a um servidor que eu gerencio e criando portas reversas. Depois de configurados, meu servidor faz algum processamento usando a porta encaminhada e, em seguida, a conexão pode ser interrompida. Se eu puder mapear portas específicas (cada aplicativo tem sua própria) para processos, esse é um script simples. Alguma sugestão?

A propósito, isso está em uma caixa do Ubuntu - mas acho que qualquer solução será padrão na maioria das distribuições Linux.

— tapinha
fonte

Respostas:

A --programopção netstat mostra PIDs e nomes de seus próprios processos. Esta opção está presente e funcionando no RHEL 6 na netstat 1.42 das net-tools 1.60.

Eu verifiquei que netstat -an --tcp --programme mostra os PIDs dos meus processos.

— Paweł Brodacki
fonte

Eu acho que você quis dizer -an. netstat -panttambém funciona e é mais fácil de lembrar.

— Eduardo Ivanec

Sim, supérfluo "-" apareceu. E eu gosto do mnemônico.

— Paweł Brodacki

Receio que isso não funcione no Ubuntu - pois não mostra o processo em alguns casos sem raiz - e parece que um encaminhamento de SSH é um desses casos.

— pat

Pawel: agora que o OP finalmente se tornou concreto com seu caso de uso (veja o comentário na minha cadeia), peço que tente novamente. Eu fiz, em uma caixa do CentOS 5 (também netstat 1.42 do net-tools 1.60), e ele falha como ele diz. Eu estaria interessado em suas experiências.

— MadHatter 17/05

A sugestão de Pawel parece funcionar bem para mim, mas como alternativa, aqui estou eu ouvindo do shell1:

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

e aqui está eu vendo-o com o lsofshell2:

[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 : você escreve em um comentário que

Os encaminhamentos do SSH devem se comportar de maneira diferente - mesmo que o processo seja de propriedade do mesmo usuário, não consigo vê-lo listado no lsof output, a menos que eu o execute como root / sudo.

mas isso não é assim para mim. Depois de usar o ssh para encaminhar a porta local 8001, com ssh vpn.example.com -L 8001:rt.int:80, encontro:

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

Você poderia nos mostrar parte de sua amostra, de preferência não muito redigida?

— Chapeleiro Louco
fonte

Parece que os encaminhamentos do SSH devem se comportar de maneira diferente - mesmo que o processo seja de propriedade do mesmo usuário, não consigo vê-lo listado na lsofsaída, a menos que eu o execute como root / sudo.

— pat

Não recebo nenhuma saída de lsof na porta encaminhada quando executado como usuário. Se eu executá-lo com o sudo, vejo uma saída muito parecida com o que você adicionou à sua resposta. A única diferença notável é que vejo o número da porta real em vez do túnel vcom.

— pat

Além disso, este é um encaminhamento remoto, não um encaminhamento local - talvez essa seja a fonte da diferença? Ou você estava testando com um encaminhamento remoto?

— pat

Por encaminhamento remoto, você quer dizer "do servidor AI ssh para o servidor B, encaminhando a porta xxx do servidor B para o servidor A"? Se sim, por que você esperaria obter algo com o netstat / lsof no servidor A? Nenhum novo ouvinte no servidor A é criado por isso, portanto, nenhuma atribuição de porta no servidor A está envolvida (salvo efêmera).

— 1519 MadHatter

SSH de A para B, a porta para a frente a partir da porta X no B para o canal Y por C (que está dentro do firewall de A -, consequentemente, a necessidade para a frente), usando lsof / netstat em B para a porta X.

— pat