Déterminer le processus à l'aide d'un port, sans sudo

Je voudrais savoir quel processus (en particulier, l'ID de processus) utilise un port donné. Le seul hic, c'est que je ne veux pas utiliser sudo, ni connecté en tant que root. Les processus pour lesquels je veux que cela fonctionne sont exécutés par le même utilisateur que celui pour lequel je veux trouver l'ID du processus - j'aurais donc pensé que c'était simple.

Les deux lsofet netstatne me diront pas l'ID du processus à moins que je ne les exécute en utilisant sudo - ils me diront cependant que le port est utilisé.

Comme un contexte supplémentaire - j'ai diverses applications qui se connectent toutes via SSH à un serveur que je gère et qui créent des ports inverses. Une fois ceux-ci configurés, mon serveur effectue un traitement à l'aide du port redirigé, puis la connexion peut être interrompue. Si je peux mapper des ports spécifiques (chaque application a les leurs) aux processus, il s'agit d'un simple script. Aucune suggestion?

C'est sur une boîte Ubuntu, en passant - mais je suppose que toute solution sera standard dans la plupart des distributions Linux.

— tapoter
source

Réponses:

L' --programoption de netstat vous montre les PID et les noms de vos propres processus. Cette option est présente et fonctionne sur RHEL 6 dans netstat 1.42 sur net-tools 1.60.

J'ai vérifié que cela netstat -an --tcp --programme montre les PID de mes processus.

— Paweł Brodacki
source

Je pense que tu voulais dire -an. netstat -pantfonctionne également et il est plus facile à retenir.

— Eduardo Ivanec

Oui, le "-" superflu s'est glissé. Et j'aime le mnémonique.

— Paweł Brodacki

Je crains que cela ne fonctionne pas sur Ubuntu - dans la mesure où il ne montre pas le processus dans certains cas sans root - et il semble qu'un transfert SSH soit l'un de ces cas.

— tape

Pawel: maintenant l'OP a enfin concrétisé son cas d'utilisation (voir commentaire dans ma chaîne), je vous conseille vivement de le réessayer. Je l'ai fait, sur une boîte CentOS 5 (également netstat 1.42 de net-tools 1.60), et il échoue comme il le dit. Je serais intéressé par vos expériences.

— MadHatter

La suggestion de Pawel semble bien fonctionner pour moi, mais comme alternative, voici que j'écoute depuis shell1:

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

et voici moi le voir avec lsofde 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)

Edit : vous écrivez dans un commentaire

Les transferts SSH doivent se comporter différemment - même si le processus appartient au même utilisateur, je ne le vois pas du tout dans la sortie lsof à moins de l'exécuter en tant que root / sudo.

mais ce n'est pas le cas pour moi. Ayant utilisé ssh pour transmettre le port local 8001, avec ssh vpn.example.com -L 8001:rt.int:80, je trouve alors:

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

Pourriez-vous peut-être nous montrer une partie de votre exemple de sortie, de préférence pas trop lourdement caviardé?

— Chapelier Fou
source

Il semble que les transferts SSH doivent se comporter différemment - même si le processus appartient au même utilisateur, je ne le vois pas du tout dans la lsofsortie, sauf si je l'exécute en tant que root / sudo.

— tapotez

Je n'obtiens aucune sortie lsof sur le port redirigé lorsqu'il est exécuté en tant qu'utilisateur. Si je l'exécute avec sudo, je vois une sortie similaire à ce que vous avez ajouté à votre réponse. La seule différence notable est que je vois le numéro de port réel au lieu de vcom-tunnel.

— pat

De plus, il s'agit d'un renvoi à distance, pas d'un renvoi local - c'est peut-être la source de la différence? Ou testiez-vous avec un renvoi à distance?

— pat

Par transfert à distance, voulez-vous dire "du serveur AI ssh au serveur B, rediriger le port xxx du serveur B vers le serveur A"? Si oui, pourquoi vous attendriez-vous à récupérer quelque chose avec netstat / lsof sur le serveur A? Aucun nouvel écouteur sur le serveur A n'est créé par cela, donc aucune affectation de port sur le serveur A n'est impliquée (sauvegarde éphémère).

— MadHatter

SSH de A à B, port vers l'avant du port X sur B vers le port Y sur C (qui est à l'intérieur du pare-feu de A - d'où la nécessité de la transmission), en utilisant lsof / netstat sur B pour le port X.

— pat