Điểm:1

Server

Đảo ngược SSH proxy bằng NGINX. (Tên miền phụ cho bộ chứa Docker chạy SSH)

Oscar Andersson

15:18, 12/02/2023

TDLR: x.a.se:22 và y.a.se:22 nên chấp nhận và dẫn đến máy x và máy y tương ứng. NGINX chỉ điều phối lưu lượng truy cập bằng cách ủy quyền ngược.

Xin chào cộng đồng tuyệt vời, Oscar từ Thụy Điển đây.

thiết lập hiện tại

Tôi có một máy chủ chấp nhận a.se, hãy gọi chủ nhà máy A. Cho nên ssh [email protected] dẫn đến SSH-dịch vụ tại cổng 22 trên máy A. máy A chạy docker containerS: máy B và một số máy khác, hãy tập trung vào một thùng chứa tại một thời điểm.

mong muốn sử dụng

Tôi muốn điều này xảy ra:

Người dùng Bob điều hành máy B không có quyền truy cập vào máy A vì người dùng không đáng tin cậy.
Người dùng Bob kết nối với cơ sở: 22 với SSH và nhận shell tại máy B.

Vấn đề

Tôi không biết làm thế nào để cấu hình này. Tôi nghĩ rằng tôi đang tìm một proxy ngược của SSH. Tất cả các điểm cuối khác của tôi đều được proxy ngược bằng NGINX vì đó là thứ tôi giỏi nhất, vì vậy tôi đang xem xét ngx_stream_proxy_module về cơ bản có thể đảo ngược proxy bất kỳ kết nối TCP nào. Vấn đề là tôi không thể hiểu được làm thế nào proxy luồng NGINX có thể phân biệt giữa a.se, căn cứ và hãy nói n.a.se ở đâu N là bất kỳ chuỗi nào.

Nếu bạn có bất kỳ câu hỏi nào liên quan đến thiết lập của tôi hoặc chính câu hỏi đó, vui lòng thêm nhận xét và tôi sẽ thêm bản chỉnh sửa cho câu hỏi này. Cảm ơn trước, bất kỳ trợ giúp và thông tin chi tiết nào đều được đánh giá cao.

Lưu ý: Máy chủ chạy Debian 11 và tôi có toàn quyền truy cập. Tôi thích Docker làm trình quản lý vùng chứa và NGINX hơn để định tuyến lưu lượng mạng.

Lưu ý: Tôi đã thêm các liên kết đến một số tài nguyên cơ bản nhất, điều này không phải để chọc ghẹo những người trợ giúp tiềm năng, nó cũng giúp ích cho việc giúp những người khác đọc chủ đề này trong tương lai hỏi cùng một câu hỏi như tôi bây giờ.

718

0 + 0

linux

người đóng tàu

Tero Kilkanen

18:47, 12/02/2023

Chuyện đó không thể xảy ra được. SSH không có khái niệm về máy chủ ảo cần thiết để điều này hoạt động. SSH chỉ kết nối với một địa chỉ IP sau khi nó đã phân giải tên miền thành địa chỉ IP.

Hồi đáp

djdomi

19:48, 12/02/2023

nếu bạn không quá lười, hãy cài đặt guacamole qua docker, nó sẽ gần như giống nhau :) Ngoài ra, bạn có thể thử những thứ tương tự sẽ được sử dụng cho smtp https://docs.nginx.com/nginx/admin-guide/mail- proxy/thư-proxy/

Hồi đáp

Oscar Andersson

20:43, 12/02/2023

Xin chào @djdomi, ý bạn là Apache Guacamole? Điều đó sẽ không hiệu quả với tôi, tôi không quan tâm đến máy tính để bàn từ xa, tôi muốn có một trình bao từ xa được mã hóa. Proxy email sẽ không hoạt động vì nó chỉ hỗ trợ POP3, IMAP và SMTP. Cảm ơn.

Hồi đáp

Oscar Andersson

20:45, 12/02/2023

Cảm ơn @TeroKilkanen :) Bạn có thể nghĩ ra cách nào khác không? Có lẽ tôi có thể định tuyến [email protected] đến bộ chứa docker B thông qua một quy tắc trong sshd?

Hồi đáp

djdomi

04:22, 13/02/2023

@OscarAndersson ....... Bạn nên suy nghĩ về phần đề cập, phần luồng giống nhau đối với bất kỳ loại proxy nào bạn muốn sử dụng.

Hồi đáp

Oscar Andersson

11:46, 13/02/2023

@djdomi bạn có thể giải thích được không? Tôi vẫn chưa hiểu lắm. Mô-đun luồng và cài đặt proxy mô-đun email có thể hoán đổi cho nhau không?

Hồi đáp

Điểm:1

Server

Tero Kilkanen

06:51, 13/02/2023

Người ta có thể kết nối với vùng chứa bằng cách sử dụng máy chủ A làm máy chủ nhảy. Tuy nhiên, điều này yêu cầu tài khoản người dùng trên máy chủ A cho mục đích này.

Người ta có thể giới hạn tài khoản máy chủ nhảy để không có quyền truy cập vào chính máy chủ.

Giới hạn có thể được thực hiện trong máy chủ A sshd_config.

Đối sánh người dùng bob
    X11Số chuyển tiếp
    Cho phép Chuyển tiếpTcp
    ForceCommand ssh bob@<container>

Sau khi thiết lập điều này, người ta có thể:

ssh [email protected]
Cung cấp mật khẩu hệ thống máy chủ
SSH daemon sẽ buộc thực thi lệnh SSH tới vùng chứa
Cung cấp mật khẩu vùng chứa

Người ta cũng có thể tạo một cặp khóa trên Máy chủ trong bồng bềnh tài khoản sẽ được sử dụng để xác thực vùng chứa. Sau đó, mật khẩu thứ hai sẽ không cần thiết.

0 + 0

Oscar Andersson

11:57, 13/02/2023

Cảm ơn Tero! Đây chính xác là những gì tôi đang tìm kiếm. Tôi sẽ thực hiện các thay đổi trong `sshd_config`. Ý nghĩa bảo mật của điều này là gì, `ForceCommand` được chạy trên máy khách hay trên dịch vụ SSH? Người dùng có thể bỏ qua điều này? Tất nhiên tôi sẽ thực hiện các biện pháp an ninh để ngay cả khi điều đó xảy ra thì cũng không có thiệt hại nào. Cặp khóa này trên máy chủ sẽ hoạt động như thế nào? Tôi hoàn toàn không hiểu làm thế nào nó sẽ xác thực trên vùng chứa. Cảm ơn. :)

Hồi đáp

Tero Kilkanen

15:43, 13/02/2023

`ForceCommand` được chạy trên máy chủ SSH và daemon SSH ngăn người dùng chạy bất kỳ lệnh nào khác.

Hồi đáp

Oscar Andersson

18:12, 13/02/2023

Bạn là một vị thần Phần Lan Tero! Lời cảm ơn tuyệt vời từ phía bên kia của hồ lớn. Bạn nghĩ sao về vấn đề khi user thoát docker container thì sẽ bị throw trở lại host đúng không? Tôi có thể sửa nó bằng `ForceCommand sh -c "sudo docker exec -ti user-container0 /bin/bash"; exit` để phiên SSH tự động thoát khi người dùng rời khỏi trình bao (`/bin/bash`) trong vùng chứa?

Hồi đáp

Tero Kilkanen

18:23, 13/02/2023

Nếu bạn sử dụng lệnh `ssh` ở trên, nó sẽ kết nối với trình nền SSH của bộ chứa Docker. Khi người dùng đóng trình bao do daemon SSH khởi chạy, nó sẽ đóng kết nối và máy chủ SSH cũng sẽ đóng kết nối. Tôi không biết cách hoạt động của quyền truy cập thông qua lệnh `docker`.

Hồi đáp

Oscar Andersson

22:01, 13/02/2023

Ooooh thực sự, tuyệt vời! Tôi đã không nhận ra điều đó, tôi nghĩ lệnh của bạn chỉ là một trình giữ chỗ. Vì vậy, ngây thơ của tôi, cảm ơn rất nhiều!

Hồi đáp

Phan Văn Trường

Câu hỏi này là trong các ngôn ngữ khác:

EN: Reverse proxy SSH using NGINX. (Subdomains to Docker containers running SSH)

TH: ย้อนกลับพร็อกซี SSH โดยใช้ NGINX (โดเมนย่อยไปยังคอนเทนเนอร์ Docker ที่ใช้ SSH)

RO: Proxy invers SSH folosind NGINX. (Subdomenii pentru containerele Docker care rulează SSH)

RU: Обратный прокси-сервер SSH с использованием NGINX. (Поддомены для контейнеров Docker с SSH)

VI: Đảo ngược SSH proxy bằng NGINX. (Tên miền phụ cho bộ chứa Docker chạy SSH)

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.