Xác định quá trình sử dụng một cổng, không có sudo

Tôi muốn tìm hiểu quá trình nào (cụ thể là id quá trình) đang sử dụng một cổng nhất định. Một lưu ý là, tôi không muốn sử dụng sudo, tôi cũng không đăng nhập với quyền root. Các quy trình tôi muốn làm việc này được điều hành bởi cùng một người dùng mà tôi muốn tìm id quy trình - vì vậy tôi đã nghĩ rằng điều này là đơn giản.

Cả hai lsofvà netstatsẽ không cho tôi biết id quá trình trừ khi tôi chạy chúng bằng sudo - họ sẽ cho tôi biết rằng cổng đang được sử dụng.

Như một số bối cảnh bổ sung - Tôi có nhiều ứng dụng khác nhau, tất cả kết nối qua SSH với máy chủ mà tôi quản lý và tạo cổng chuyển tiếp ngược lại. Khi chúng được thiết lập, máy chủ của tôi sẽ thực hiện một số xử lý bằng cổng được chuyển tiếp và sau đó kết nối có thể bị hủy. Nếu tôi có thể ánh xạ các cổng cụ thể (mỗi ứng dụng có riêng) cho các quy trình, thì đây là một tập lệnh đơn giản. Bất kỳ đề xuất?

Nhân tiện, đây là trên một hộp Ubuntu - nhưng tôi đoán bất kỳ giải pháp nào cũng sẽ là tiêu chuẩn trên hầu hết các bản phân phối Linux.

— vỗ
nguồn

Câu trả lời:

Các --programtùy chọn để chương trình netstat bạn PID và tên của các quá trình của riêng bạn. Tùy chọn này có mặt và hoạt động trên RHEL 6 trong netstat 1.42 trong số các công cụ mạng 1.60.

Tôi đã xác minh điều đó netstat -an --tcp --programcho tôi thấy các quy trình xử lý của tôi.

— Brodacki
nguồn

Tôi nghĩ bạn có ý đó -an. netstat -pantcũng hoạt động và nó dễ nhớ hơn.

— Eduardo Ivanec

Vâng, không cần thiết "-" len lỏi vào. Và tôi thích những thứ ghi nhớ.

— Paweł Brodacki

Tôi e rằng điều này không hoạt động trên Ubuntu - ở chỗ nó không hiển thị quy trình trong một số trường hợp không có root - và có vẻ như SSH chuyển tiếp là một trong những trường hợp đó.

— vỗ

Pawel: bây giờ OP cuối cùng đã có được cụ thể với trường hợp sử dụng của anh ấy (xem bình luận trong chuỗi của tôi), tôi khuyên bạn nên thử lại. Tôi đã làm, trên một hộp CentOS 5 (cũng là netstat 1.42 từ các công cụ mạng 1.60), và nó đã thất bại như anh ta nói. Tôi sẽ quan tâm đến kinh nghiệm của bạn.

— MadHatter

Đề xuất của Pawel dường như hoạt động tốt với tôi, nhưng như một cách thay thế, đây là tôi lắng nghe từ shell1:

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

và đây là tôi nhìn thấy nó lsoftừ 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)

Chỉnh sửa : bạn viết trong một bình luận rằng

Chuyển tiếp SSH phải hoạt động khác đi - mặc dù quy trình được sở hữu bởi cùng một người dùng, tôi không thể thấy nó được liệt kê ở tất cả trong đầu ra lsof trừ khi tôi chạy nó dưới dạng root / sudo.

nhưng điều này không phải với tôi Đã sử dụng ssh để chuyển tiếp cổng địa phương 8001, với ssh vpn.example.com -L 8001:rt.int:80, sau đó tôi tìm thấy:

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

Có lẽ bạn có thể chỉ cho chúng tôi một số sản lượng mẫu của bạn, tốt nhất là không được xử lý quá nhiều?

— MadHatter
nguồn

Có vẻ như SSH chuyển tiếp phải hành xử khác đi - mặc dù quy trình được sở hữu bởi cùng một người dùng, tôi không thể thấy nó được liệt kê ở tất cả lsofđầu ra trừ khi tôi chạy nó dưới dạng root / sudo.

— vỗ

Tôi không nhận được đầu ra lsof nào trên cổng chuyển tiếp khi chạy với tư cách người dùng. Nếu tôi chạy nó với sudo, thì tôi thấy đầu ra giống như những gì bạn đã thêm vào câu trả lời của bạn. Chỉ có sự khác biệt đáng chú ý là tôi thấy số cổng thực tế thay vì đường hầm vcom.

— vỗ

Ngoài ra, đây là một chuyển tiếp từ xa, không phải là một chuyển tiếp địa phương - có lẽ đó là nguồn gốc của sự khác biệt? Hay bạn đang thử nghiệm với một chuyển tiếp từ xa?

— vỗ

Bằng cách chuyển tiếp từ xa, bạn có nghĩa là "từ máy chủ AI ssh đến máy chủ B, chuyển tiếp cổng xxx từ máy chủ B trở lại máy chủ A"? Nếu vậy, tại sao bạn lại mong đợi nhận bất cứ thứ gì với netstat / lsof trên máy chủ A? Không có trình nghe mới nào trên máy chủ A được tạo bởi điều này, vì vậy không có sự phân công cổng nào trên máy chủ A được tham gia (lưu lại một cách phù du).

— MadHatter

SSH từ A đến B, chuyển tiếp từ cổng X trên B sang cổng Y trên C (nằm trong tường lửa của A - do đó cần chuyển tiếp), sử dụng lsof / netstat trên B cho cổng X.

— vỗ